DW2: Mad Drongo Animation Malfunction

Savegame

ScummVM SVN 1.1.0 Branch Revision 48357
built on Linux x86_32 2.6.31 by GCC 4.3.4
DW2 is CD/DOS/English (GB) version

Screen capture of bug

Savegame which does NOT exhibit bug

This bug has been replicated by salty-horse.

It exhibits with the attached savegame. An unaffected game is attached for comparison.

It is inferred taht the fault is associated with a specific case of the random / date-time fields in the Tinsel savegame format, but I'm not currently familar enough with these to spot the specific issue.

Further investigation indicates that this bug does not occur if using "New Game" option or Save/Loading from this game state, but only when loading a previously saved game from the launcher or choosing the "Resume Game" option.

This would indicate some game state variable is not being initialised correctly on load, as opposed to new game.

It should be noted that this issue has been reported before as bug 2788154.

However, this bug is not invalid, but troublesome to replicate.

If I recall correctly, this bug occurred in the original engine as well, so this would indicate a script issue.

We've been able to establish that it isn't reproducable from loading directly from the launcher versus loading in-game, so I agree with tdhs that it's likely some script bug. Unfortunately, whilst the savegame will likely be to able to tell me what's wrong, it likely won't be able to tell me *how* it got wrong, so it likely won't be easy to fix.

dreammaster :
Tried to reproduce this in the original engine without success, though this is inconclusive.

High Energy Magic Building is Scene 66. By intercepting _ctx->reelActor in t2PlayReel() in engines/tinsel/play.cpp, I have identified Mad Drongo as 235 (Talking), 236 (Vomiting), 237 (Idle, Blinking) and 238 (Laughing).

In both cases, 235, 237 and 238 are called, but it appears the bug causes 235 and 238 to be visible, rather than hidden when you load a savegame in Scene 66.

Still trying to trace down the exact cause, but hope this helps you.

Thanks to your help, I finally tracked down the source of the problem. It's one of those Doh! moments - looking at syncSavedActor after several previous times, it only then dawned on me that the value of 'bHidden' was never actually getting saved in the savegame, which is why the several reels could be false.. it would actually take the bHidden values from whatever previously stored in those fields, either uninitialised data, or whatever was in them the last time a savegame was made.

Luckily, the existin savegame format dedicated a 32-bit LE value for storing the 'bAlive' boolean value, so I've converted it to being stored in a 16-bit LE value, and used the remaining two bytes to store the bHidden value. This will cause minimal impact on the savegame format, and allow existing savegames to still load properly