[http://sourceforge.net/p/ufoai/bugs/2370 Item 2370] imported from sourceforge.net tracker on 2013-01-28 19:30:37

tested in rr28680
1. load the estate map.
2. place the actor in the position as per image 1.
3. set the route as described in the screen shot. notice that it takes 10 TU cost to perform the movement.
4. activate the route plan. notice the unit moved directly to the location and it cost 2 TU. image 2

this issue is occurring on both stair cases and occurs with both moving up and down the stair cases, you will need to play around with it to find all the permutations of 'banister jumping'


===== Comments Ported from Sourceforge =====

====== markhawrylak (2010-02-23 07:24:31) ======

actor movement different to displayed path
====== markhawrylak (2010-02-25 02:13:46) ======

I recompiled the estate map and the issue was resolved as described above.
this means that ALL maps need to be recompiled.
can you please indicate which revision that caused the maps to require re-compiling?
Can you please indicate which revision that caused the maps to require re-compiling? was it 28659?
====== markhawrylak (2010-02-28 07:31:35) ======

tested in r28703 with estate map recompile - Failed.
The original raised issue is occurring.
however I can move up the grand stairs.
can someone please re-open this defect
====== markhawrylak (2010-02-28 07:58:21) ======

tested in r28655 with estate map recompile - the issue is occurring for both confirm and non confirm mode.

====== markhawrylak (2010-02-28 08:44:34) ======

tested in r28000. the issue is occurring in this version too. I will not explore into the past any more unless requested
====== markhawrylak (2010-02-28 10:46:32) ======

I tested in r28702 and the issue was resolved, so r28703 introduced the issue again.

====== markhawrylak (2010-03-03 22:16:01) ======

attached is another example in the office map.
the route is different to the actual walk taken
====== markhawrylak (2010-03-03 22:16:48) ======

[map] office route different to actual movements taken
====== markhawrylak (2010-03-04 21:49:56) ======

another example of this defect
https://sourceforge.net/tracker/?func=detail&aid=2963437&group_id=157793&atid=805242

====== aduke1 (2010-03-07 19:59:41) ======

I can reproduce it here (for estate).
All I figured out so far is that Grid_MoveNext returns different dv values in CL_ActorTraceMove (9, correct) and G_ClientMove (17, wrong). No clue why yet.
====== markhawrylak (2010-03-12 02:07:24) ======

this was produced in r28905 - attached ufo75.jpg of the map excavation
I set the route in the ampitheatre as in image 1
then I move unit. I took the screen shot mid walk to show how the unit actually walks through another unit because the movement is different to the route plan
====== markhawrylak (2010-03-12 02:07:49) ======

map excavation, walking through a unit
====== aduke1 (2010-03-12 22:53:12) ======

Phew, that was a tough one ! But after several nights of debugging, I finally figured it out :)
Here is what happens in a nutshell:
Standing at the starting point of the 'bad move' on estate.map, le->pos is correctly set to 130,131,0 in the CL_* code.
But in the G_* code, ent->pos is 130,131,*1*. That is, the actor thinks he is in mid air. Walking from there (down) to 130,132,1 is easy and takes just 2 TUs.

This is because of line 441 ing g_move.c, G_ClientMove(). Removing that line fixes the bug. However, that line was added on purpose (in r28209). So we have to figure out what the intention was and find a different solution or we would re-introduce some other bug.

tlh2000, do you listen ?

====== tlh2000 (2010-03-13 08:20:15) ======

i will have a look at that line
====== tlh2000 (2010-03-13 08:22:51) ======

that means that the origin is just wrong - that is a critical bug, as the origin is also used for traces. that might be the cause for too high traces. i will first add a debug function that is drawing all the server side traces in a map with start and end point - maybe we can catch the wrong origin with this.
====== tlh2000 (2010-03-13 11:18:28) ======

the trace debug feature is there now - use g_drawtraces - now back to the origin
====== tlh2000 (2010-03-13 14:06:43) ======

just a guess (haven't verified yet), but maybe the client is putting the origin on the ground (because it has to align models and so on - and the game centers the origin to the mins/maxs?
====== aduke1 (2010-03-13 21:13:22) ======

The usual problem. Different parts of the code seem to have different ideas about what origin and pos are meant to be.
In game.DLL, the origin of an actor is calculated as half a cell height. That is about breast height. The pathfinding code needs pos to be the position of the feet of the actor.
When the actor stands on the upper part of a stairway, his breast is already in the upper level while his feet are still in the old level.
Line 441 then forces pos to the same level as the breast height, driving pathfinding nuts.

The main question is: What did you want to achieve with your change in r28209 ?

====== stedevil (2010-03-14 00:15:20) ======

I'm going to take a wild guess and say the constant server crash bugs that is a side track to this issue

https://sourceforge.net/tracker/?func=detail&atid=805242&aid=2962458&group_id=157793

is related to this "confusement about height" in the code.
====== tlh2000 (2010-03-15 20:59:50) ======

that's a really good question duke. the commit comment could have been a little bit longer. i can't remember anymore. but isn't there a function "that is doing the same thing ... but correct?" (tm) ;)

i'm sure that fixed a bug - otherwise i wouldn't have done that. imo there is "just" a missing grid_fall call for this. but i think we already have functions for that, maybe the VecToPos function call is just wrong?
====== tlh2000 (2010-03-15 21:00:55) ======

and here is the link for the revision that caused this (?) - https://sourceforge.net/apps/trac/ufoai/changeset/28209
====== tlh2000 (2010-03-15 21:04:25) ======

i can't find any related revision close to r28209 that might have to lead to this patch. maybe we should just revert it and see whether this fixes this bug - if so - commit the revert. looking at the code i don't see the reason why this should be needed. whatever has driven me there....?!
====== tlh2000 (2010-03-15 21:17:37) ======

duke reverted this in r29019
====== aduke1 (2010-03-15 21:29:39) ======

I decided to revert because *if* your change fixed a bug, it will resurface. Then we can find a better solution.

@Mark:
I'm pretty sure the fix covers all the instances you posted. But feel free to test a couple of them just to be sure ;)
====== sf-robot (2010-03-30 02:21:09) ======

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).