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

Sometimes the TUs used by a move becomes 1 more than the prediction.

This happens when the actor is crouching, starts the move facing eg south and end the move with a diagonal movement. The last automated action that happens in this case is that the actor turns 45 degrees to face in his original heading, which makes you spend 1 extra TU above the prediction.

This is really bad since, not only may you not want to perform this turn let alone spend TUs on it, but also if you have reserved TUs eg for an aimed sniper shot (18) you can end up "frozen in place" with 17TU left and it's not possible to neither switch to eg snap shot (12TU) nor to turn RF off completely. This makes it impossible to do anything more with that actor for the rest of the turn even if it eg has 17TU left.

Thus essentially we have 2 bugs here, fixing the wrong prediction (preferably by removing that silly unwanted extra turn, or at least making it free of cost) will hide the "frozen" bug, but perhaps being frozen should also be fixed.

svn r28780
===== Comments Ported from Sourceforge =====

====== markhawrylak (2010-03-04 21:56:07) ======

this is a duplicate defect or very similar to the defect
the original is https://sourceforge.net/tracker/?func=detail&aid=2927289&group_id=157793&atid=805242
====== stedevil (2010-03-04 23:12:16) ======

Well, it's similar in that it also affects TU prediction, but it's not about miscalculation from stand/crouch actions on the way (the actor never stands up but crouches all the way in my case, have autostand turned off).

This bug is specifically about the issue that, in some cases, the actor does an extra 45 degree turn at the very end, that was neither ordered nor wanted. 1 TU overspending from prediction is one of the consequences, not the actual issue.

Fixing this bug will however likely make the job easier to fix other prediction errors, since this adds extra confusion figuring out what is wrong elsewhere.
====== tlh2000 (2010-03-05 07:56:57) ======

can you please provide screenshots with step-by-step - i wasn't able to reproduce it here.
====== stedevil (2010-03-12 10:25:44) ======

To reproduce:

1) crouch actor
2) try to move 2 squares diagonally
3) notice how instead of 8 TU (4+4) 9TU is used instead.

So it seems it's not actually the final turn motion that uses up TU (it's just annoying), but the diagonal movement in it self.
Also, if one does 4 diagonal movements in a row the cost becomes +2 (ie 4+4+4+4 = 18 but should be 16). This also enables one to be able to eg move so you have only 10TU left with a a sniper on 12TU reserved for RF (again with the remaining 10TU impossible to use).

The same pattern hold true also for 6 diagonal moves in a row, do the 1 by 1 TU = 6x4 = 24TU. Do them in 1 motion 6x4.5= 27TU.

svn r28860
====== stedevil (2010-03-16 09:34:35) ======


Managed to get a crash from this as well.
Situation: Actor has 8TU left, crouched, tries to move 2 diagonal squares. Autostops after moving 1 square. Shown to have 4TU left, but refuses to move 1 more square on the diagonal. When moving non diagonal the following crash happens

ERROR: LE_DoEndPathMove: Actor movement is out of sync: 123:141:0 should be 124:142:0 (step 1 of 1) (team 1)
********************
Shutdown server: Server crashed.
==== ShutdownGame ====
./ufo(Sys_Backtrace+0x1f)[0x819e6b6]
./ufo(Com_Error+0xf6)[0x8145cfe]
./ufo(LE_DoEndPathMove+0xe1)[0x8094db0]
./ufo[0x8094f50]
./ufo(LE_ExecuteThink+0x58)[0x8094281]
./ufo(LE_Think+0x24)[0x80942a7]
./ufo(CL_Frame+0xd8)[0x807b5dc]
./ufo[0x814766d]
./ufo(Qcommon_Frame+0x7b)[0x8147acf]
./ufo(main+0x5c)[0x819d487]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb734bb56]
./ufo[0x806c011]


svn 29019
====== aduke1 (2010-03-17 00:11:39) ======

I can confirm the '+1 TU' problem AND the 'crash to menu'.

====== aduke1 (2010-03-17 22:19:51) ======

Fixed in r29053 :)
Actually it was a rounding prob. Crouched diagonally needed 4.5 TUs in the game.DLL, but routing calculates 4 !
This was probably the true reason for all those 'Actor movement is out of sync'-situations.

Thx for the good reports :)

====== sf-robot (2010-04-03 02:20:24) ======

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).