[crossfire] server commit for map2 support.

[Mark Wedel]

Alex Schultz wrote:
> Mark Wedel wrote:
> 
>> <snip>
>>
>> 2) the map2 has support for 10 layers.  However, compared to the old 3 layer 
>> method where it tried to find something to fill each of those 3 layers, 
>> different layers are well defined to hold specific data (objects, monsters, 
>> etc).  So you will probably never see all 10 layers filled with something at the 
>> same time.  But you can pretty easily see 5 or 6 layers filled (stand on floor 
>> with a sign, drop 3 objects, and have someone cast a spell over you :)
>>
>>  One of the main reasons for doing this is that one of the problems with the 
>> old client is objects shifting layers - this caused more a problem with big 
>> images and whether they should or should not be erased.
>>  
>>
> I'm a bit concerned about this. I'm not sure that simply adding more 
> layers is the real fix to the objects shifting layers, simply a 
> workaround. I'm not completely sure what the proper fix would be though, 
> however perhaps a proper fix would be arbitrary layering, not limited 
> except by how many a server is configured to send and limits on some 
> variables. A possible implementation of "arbitrary layering" would be by 
> sending the layer as <majorlayer><minorlayer> where each is an <either 4 
> or 8, not sure> bit signed value. The server would allocate by 
> majorlayer starting at 0, to insert below majorlayer 0, it goes into the 
> negatives, above into the positives, and for in between two already 
> allocated layers, it starts using the minorlayer values like a decimal 
> place.
> Please note, I don't endorse my particular proposal of "arbitrary 
> layering", but that some form of "arbitrary layering" would be the 
> proper fix to the above problem.

  The change I made should greatly reduce, and perhaps, eliminate the layer 
shifting problem.

  The main (only) places where big images show up right now are buildings (and 
some landscape, like mountains) and monsters.  There are not any big objects 
that the player picks up, nor any big flying objects (eg, spells, rocks, bullets).

  I believe even with the old code, there was never a problem with the 
building/mountains (no pick) objects, because those would always be sent as the 
object right above the floor, and you wouldn't get a case of a new object 
between it and the floor showing up.

  The problem was really the monsters.  In the old code, if we have a big open 
area of sand, layer 1 would all be sand.  The monster would be on layer 2.

  However, if that monster now steps on a space with something else on it 
(sword, staircase, etc), it would move up to layer 3, with the sword being level 
2.  When it steps off, it goes back to level 2.

  This won't happen any more.  living objects are defined to be on level 6 and 
7.  So the only thing that would cause it to change layers is if it steps on top 
of something with another living object (which can't currently happen under 
normal circumstances).

  There is also some need of having hard layers.  for example, if available, you 
always want to send the floor.  And the building for the matter, as well as 
monster or player.  you just can't send the top 4/8/20 objects and necessarily 
call it done.

  So if we are going to check for specific layers that we always want to send, I 
think it makes to store them based on that stacking.