Jblade, on 07 February 2015 - 01:35 PM, said:
I just uploaded a map called htest.map to the AMC repository - I spawned a liztroop in and it indeed moved no problem but my enemy just raises up and then struggles to move out of the sector.
The reason the enemy didn't take into account TROR boundaries is that it never issues
fall. Unfortunately, this is pretty much the only place that updates actor[].ceilingz and actor[].floorz in a proper fashion for a given sprite. These members are intended as cached versions of the upper and lower bounds for vertical movement. If you search for these members in the EDuke32 source code, you'll find a lot of places where they are set to the sector's ceiling or floor z -- without regard to slope, and now, TROR. My earlier fix (
r3666) modified the updating of these members for the COMMANDER and DRONE to consider movement through TROR bunches as well.
[1] However, carrying out the same kind of tweak for all other enemies (when moving vertically) in
r4975 entailed unwanted behavior: enemies would start moving through blocking sprite constructions (reported by Micky C on IRC, reached me via TX in a PM).
[1]And for
upward-moving enemies, but without storing actor[].ceilingz. Actually, that's kind of weird now I think about it. This idea behind that was probably to allow Enforcers jump across bunches. But it seems that the actor's sector number may fail to be updated, then. Needs to be reviewed.
The reason is the above-mentioned proper actor[] .ceilingz and .floorz update, namely using the engine function
getzrange. For actors, this is pretty much only called via
fall.
The solution I have settled at is to have CON coders issue
getzrange themselves whenevery they see fit. In r5016, I added a CON file
thisactor_getzrange.con that reimplements EDuke32's hardcoded way of doing that: the initial z position is the actor's one minus 256, and the actor's cstat is temporarily cleared to 0 (to prevent hitting itself). This is only one part of the source's A_GetZLimits(); the other part disables fake floor shadows on hitting a certain class of face sprite below and effects the "sliding" above enemies (
regardless of how far away the sprite is above it, actually!). That part was not reproduced.
So, thisactor_getzrange.con is intended to be copied into your mod,
includeing it once somewhere and calling "
state thisactor_getzrange" where you would issue
fall for a falling actor. Note that getzrange() needs to check all sprites in the collected set of sectors for collision -- watch out for quadratic run time. You may also want to call it less frequently than every game tic as a microoptimization, for example every fourth one and only when the actor moves vertically.