This bug was a bit complex.
This change ensures that cacheIn events get called before enterFastArea. In
Ultima 8 only a couple of classes have cacheIn events, so it makes no real
difference. In Crusader, this bug caused extra people in the rebel base because
they got the wrong mission number during enterFastArea (the mission number is
updated in a cacheIn event).
The previous map switch code was re-making the CameraProcess as needed, but
after the cacheIn usecode processes were created - so the new camera went to
the front of the process queue. The first execution of the camera process then
updates the fast area, and enterFastArea processes get added to the front of
the queue again (in front of the cacheIn events). Switch to only updating the
existing camera process where possible instead of creating a new one, so the
execution order does not change.
Force the creation of a new screen buffer for the scaler after leaving the overlay. The whole "old source" code looks a bit unfinished. Anyway, this fix should only kick in for one particular scaler and one particular situation and one particular backend. So I guess it is safe enough...
The engine now measures whether it can perform one screen update within a 60Hz tick. Unfortunately the calls to OSystem::updateScreen() may take very long, depending on the backend and the filter setting. In this case the engine will start to catch up to the current frame. It should still look fine, unless the platform is way too slow for the selected filter setting (with the wrong settings it is not too difficult to achieve OSystem::updateScreen() durations of over 100ms).
The ammo data is stored in shop data 1, and is always the same. Items and
weapons should all be shown in "weapons" mode.
This is still not exact to original - it seems the ammo needs filtering based
on something, probably the unknown data field in stuff.dat.
This easter egg is present in script 805. In this easter egg, Gabriel
draws a doodle of Jane Jensen in the whiteboard, if the player uses the
operate action below the whiteboard's eraser. This easter egg looks for
a file named "buster" to be present, so that it is enabled. We always
report that this file exists, to unlock the easter egg.
Special thanks to sluicebox for his awesome work on discovering this
easter egg: https://www.benshoof.org/blog/gabriel-knight-1-easter-eggs
Inspecting the disassembly more closely and trying to fix the usecode for the
Crusader spider bombs (CRU_SPID::ordinal20), the parameter for this intrinsic
is not "force", but more like "move until blocked", and when it's false the
item should not move at all if there is a block.
The spider bomb usecode tries to move the bomb down every now and then to check
for a fall, but if it meant "force" then the bomb would go into the floor. It
would also never explode because it was always forced into the new position and
never fails.
The return value is whether the move completed.
