[CF-Devel] map/image layers

crossfire-devel at archives.real-time.com crossfire-devel at archives.real-time.com
Tue Apr 20 02:23:03 CDT 2004


Nicolas Weeger wrote:
>>
     
       Any thoughts?  Would people see the need for more layers than this 
     
     >>
     
      (at some level, you get diminishin returns, as objects will obscure 
     
     >>
     
      other objects).
     
     >
     
     
     >
     
     
     >
     
      Hum, the proposal sounds nice.
     
     >
     
      I have only one concern, it's that it prevents having monsters under items.
     
     >
     
      This means that you couldn't put an ant under a table (which would be 
     
     >
     
      their logical position, unless they climb the table). I know the code 
     
     >
     
      doesn't support that right now, but it's been talked about - redoing 
     
     >
     
      with 5 layers as you suggest would make it harder to tweak later...
     
     >
     
     
     >
     
      So my turn to suggest, but it may be a bigger change :)
     
     >
     
      New fields 'altitude' and 'height' and 'max size to be under'. Usually 
     
     >
     
      we'll have 'altitude' == 'max size' (case of arrows for instance).
     
     >
     
      A table will be (arbitrary units) 'altitude' = 0, 'max size' = 1, 
     
     >
     
      'height' = 1.2
     
     >
     
      An ant with 'height' = .1 will go under the table. A troll with height = 
     
     >
     
      2 will go over, thus altitude becomes 1.2 (climb on table; would be fun 
     
     >
     
      to have max weight resist table => table crumbles => monster gets hit :pp).
     
     >
     
     
     >
     
      That'll let us also have fun with walls - altitude = 0, max size under = 
     
     >
     
      0, height = 3. A player with max_climb (another new field?) = .5 & 
     
     >
     
      height = 2 couldn't reach the top of the wall & thus couldn't go on the 
     
     >
     
      other side.
     
     >
     
     
     >
     
      Using current 3 layer approach, we'll be able to know what items to 
     
     >
     
      display - the three ones with higher altitude + height
     
     >
     
     
     >
     
      Not sure that'll solve all issues, but well. Just my 2 cents of € :)
     
     
  Well, having a height/altitude for climbing, potential line of sight, flying 
over, etc, all makes sense, and in no way impacts the layer idea I mentioned.

  The problem I have with the height idea as you mention is that it seems it 
could make things fairly indeterminate.

  For example, you have a table of height 36".  You have a dagger of height 2". 
  Under the idea above, the dagger would always go under the table, since it is 
shorter.  In many cases, that probably isn't what you want.  So in that case, at 
best, the height information is only a hint.  And now take the next case - have 
that table on a space, and the player drops a dagger.  Does he drop it on the 
table, or on the ground (under the table).

  I'll admit I have no good solution to that problem - in terms of dropping 
stuff, there is probably no good solution.  However, it seems to me the simpler 
approach is easier to deal.

  Now there is already a field called 'visibility', which is used in same cases. 
  I'd have no issue saying that level 1 has visiblility <30, layer 2 has 31-60, 
layer 3 has 61+, or whatever.

  What needs to be avoided is and object changing the layer it is on based on 
other items on the map.

  This causes signicant problems right now with big images/multi part 
archetypes.  Imagine a 2x2 monster, like:

AB
CD

  there are real problems right now where part A may be on layer 1, and part B 
on layer 2 (due to other objects).  Since only part D is sent, do we say it is 
layer 1, layer 2, or whatever layer part D happens to be?

  In pretty much all cases, this resultings in drawing issues - if you say layer 
2, it may now obscure things that should be on top of it.  If you say layer 1, 
there may now be things on top of it that shouldn't be.  If we can say the 
entire object will always be on layer X, this makes things work out much better.




>
     
     
     >
     
      Nicolas
     
     >
     
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     

_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel
     
     
    


More information about the crossfire mailing list