Home » MODDING HQ 1.13 » v1.13 Bug Reports » Bugs with "fast forward" system
Bugs with "fast forward" system[message #309081] Tue, 14 August 2012 23:33 Go to next message
Istrebitel

 
Messages:222
Registered:December 2009
Location: Russia, Saint-Petersburg
Greetings.

I noticed that "fast forward" system seems to be buggy. Here are my observations:

- In turn based, order your merc to run somewhere and turn on "fast forward". Your merc will complain he ran out of APs. It turns out, in fast forward mode more AP's are used to move in turn based than without it.
- The problem above may apply to enemy as well, which means using fast forward gives player an unfair advantage (by making AI be unable to shoot after movement, or just by making AI do less actions with its AP pool)
- When its enemy turn and you're fast forwarding and you're thrown a flare at by an enemy elite, flare flies at normal speed. By the time you react you're thrown a flare at, and stop fast forwarding, enemy may have already skipped turns of several soldiers (who would otherwise fire at you since they now see you)
- Bullets fly at normal speed, and game doesnt wait until bullet hits before switching to next soldier/militia in fast forward mode. This allows for AI units to "dodge" shots, for example my militia shoots at soldier, soldier gets interrupt after getting shot (bullet still in travel) and moves behind a building - bullet misses.
- It seems that after AI thrown something, in normal mode it waits for it to land then continues its turn, in fast forward mode it doesnt do anything after throwing (happened to me - enemy saw my merc but my merc didnt saw him, each turn he threw a stun grenade at my merc and didnt shoot him, only at third turn when he ran out of grenades he started shooting).
Re: Bugs with "fast forward" system[message #309185] Fri, 17 August 2012 04:55 Go to previous message
tazpn

 
Messages:99
Registered:December 2007
Location: CA, USA
Thanks for the feedback. This is probably the most significant and meaningful testing I've gotten from someone outside of my own testing.

--

Initially when I first did this I studied several scenarios carefully to ensure same effective behavior including movements and what not by removing as much randomness as possible. I found that setting the time too fast for the machine would sometimes lead to 'truncated' behavior like you are describing. I turned it for my 2 machine to work as correctly I could manage.

It eventually went through a bit of a rewrite when I finally submitted it because of some protection code was causing lockup problems on other peoples machines so that could be one cause.

If you still want to use it you can try to change FAST_FORWARD_PERIOD in ja2_options.ini to a larger number than the current default (2x-4x the current value would probably be helpful). It will be slower when skipping but I would expect this truncated behavior will have a less likelihood of occurring. I would expect perhaps more problems on slower machines though I did do testing on my p4 laptop which is very slow and verified behavior on several maps.

I would say that part of the problem could be that the way the speed up occurs is that I effectively remove limits on the timer so that it runs the loops as fast as possible rather than at a fixed 10 ms interval. I tried not to interfere at all with the actual core gameplay and really only was updating the counter values at faster rates. The issue may be that gameloop not being called every pass due to the previous one not completing quickly enough. Normally in the game 10ms or so would be enough but not now.

Unfortunately, the timers, ai, and UI are horribly intermingled and probably no possible hope of separation.

I have difficulty reconciling your error report with what I expect the code to do but on the other hand I believe the cases you report are legit and its a matter of replicating and producing a fix.

I will try to experiment with some extra blocking to ensure gameloop is executed once per timer increment when ff mode is on as there is some possibility of timers being updated 2-3 times per gameloop call as its currently written. This will ensure any code dependency on the timers changing from one pass to the next instead of just that the timer has expired would be better behaved. Not sure if any code really does that but its possible.


Doing more blocking to guarantee timer/gameloop synchronization will likely cause more stuttering though so it will take some time.


Side question to anyone: Is there any good way of doing reproducible testing in JA2 for regression comparison? I thought maybe the lua scripts or something might be useful. Basically start with a case with known random seed, play it back save beginning and end state. Repeat with new features enabled and compare. I'm guessing no as I've not seen it but doesn't hurt to ask.
Previous Topic: Bug with Goc_man's SCI r5412 SVN revision 1473
Next Topic: Reinforcements Bug
Goto Forum:
  


Current Time: Sat Sep 22 16:14:29 EEST 2018

Total time taken to generate the page: 0.00987 seconds