[CF-Devel] multistage map

Sat Aug 9 01:54:53 CDT 2003

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Samedi 09 Août 2003 08:19, Mark Wedel a écrit :
>

      tchize wrote:

     >

      > -----BEGIN PGP SIGNED MESSAGE-----

     >

      >

     >

      >>  But you're sure to get other issues, eg, in your example, the player on

     >

      >>the roof wants to fire down on the player on the ground (bow, spell,

     >

      >>whatever).

     >

      >

     >

      > That's a problem indeed. For now, rules apply to maps in a separate way.

     >

      > I need to prepare a list of what world interaction should cross the stage

     >

      > boundaries (typically a burning hands is horizontal, no stages crossing,

     >

      > but a magic missile shoud be able to target a monster down stairs.

     >

     >

        As I think about this more, the more of a can of worms this seems to be.

     >

     >

        Arguably, most spells should be aimed down, just like you could aim

     >

      arrows down.

     >

     >

        But suppose you have a case where you have a courtyard surround by walls,

     >

      with players (and monsters) being able to stand on top of the walls.

     >

     >

        If I fire an arrow (or other object), am I aiming at a target on the far

     >

      wall, or something in the courtyard?  And how does one control that? 

     >

      Having objects on the lower layer automatically go up when they reach an

     >

      obstacle would likely cause all sorts of problems.

     >

Someone argued me this:
"why coud you aim at player below, while player below can't see you? It's 
dangerous, better not allow aim down for fair play"

>

      > Visually speaking, it's more clever than no object = transparent

     >

      > When the code when to collect the 3 visible faces for the top map, it

     >

      > use, as starting point, the bottom, middle, top info from map below at

     >

      > same position (i forgot to tell in implementation, each stage map must be

     >

      > same size). I there was a top but no middle (typically a floor and only

     >

      > one object), the top reach the middle level (a tree in top map must draw

     >

      > itself above a monster in bottom map). Then the classical code is used to

     >

      > calculate the faces, so only difference is we don't start faces

     >

      > calculation with NULL objects in top middle and bottom, but with info

     >

      > from below map.

     >

      >

     >

      > Still need to do some fixing, since a middle object found in upper map

     >

      > should also draw itself over the middle object of bottom map.

     >

     >

        How do you deal with floors?  If there is a floor on the top map, you

     >

      _must_ ignore all the objects on the maps below it.  From the description

     >

      above, it sounds like you could have a case where middle layer is floor,

     >

      monster, and top layer is floor empty, and it'd take the monster from the

     >

      middle layer (since there is currently no used middle layer on the top

     >

      floor).  That is just plain wrong.

     >

The info from map below is just used as a starting point. I use the  classical 
code after to calculate what is visible. And in classical code, when you find 
a floor object, behaviour is "forget everything about faces, start again from 
this floor"
So if there is a floor in the upper map, nothing, at this tile, is drawn from 
below map. Simply floor is bottom and if there is nothing on floor, we only 
send one face to client, like in classical map when there is only floor at a 
tile.

>

        Also, you probably need some form of reverse precedent, eg, lower map

     >

      knows that there is a map above that depends on it.

     >

That's already done, in some part, since when a P_NEED_UPDATE is handled at 
the bottom level, when calculations is done, it ask the above map to 
recalculate the concerned square too. That's how it is possible to see player 
below moving.
To prevent misunderstandings, if did the 'stacking draws of maps' in map.c in 
function update_position, not in the map1command

>

        That is simply because the way map updates are done - If something

     >

      changes on the lower map, you must also inform the upper map of that change

     >

      in case it is using spaces from that lower map.

     >

yes

>

        Otherwise, you get the case where the upper map is basically holding bad

     >

      data - the look of the upper map isn't updated, because apparantly nothing

     >

      has changed on that space, but the data itself isn't accurate, because it

     >

      may be saying that the 'middle' stack looks like X, based on information it

     >

      had before from the loer map.

     >

And i did alos implement something less obvious but which laid to strange 
behaviour in my first attemps:
Don't swap map below while the upper map is still in memory....

>

     >

     >

      _______________________________________________

     >

      crossfire-devel mailing list

     >

      crossfire-devel at lists.real-time.com

     >

      https://mailman.real-time.com/mailman/listinfo/crossfire-devel

     -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/NJrDHHGOa1Q2wXwRAoewAJ9Dg1a4loj+FpEDvQ8O0opwnBptogCgrNT8
/T/xwNmGlEJ63FeLPQxWxko=
=ZKcw
-----END PGP SIGNATURE-----

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel