Menu
▾
▴
#1826 BG: completely lower the moongate before Iolo speaks
When you start a new BG game in the first scene, avatar steps out of the moongate, moongates lowers itself and Iolo speaks.
In the original the moongate is completely gone before Iolo speaks. In Exult the moongate is still partially shown and is frozen in animation while Iolo speaks.
Also the moongate sound will play throughout Iolo's dialogue with you. The sound ends only after you finish speaking with Iolo.
Sprites and scripts seem to need just another tick to complete.
This bug can also be seen in the Wall of Lights cutscene.
Create a new SI game.
Teleport to Spinebreaker.
When Anti-Shamino speaks, you can see the last frame of the "teleport here" sprite on Mad Iolo.
thanks, maybe I can find the culprit with this information.
It's out of my league. I think it needs an extra delay or a "wait for animation to finish" in ucsched.cc
void Usecode_script::handle_event(..)
I'm starting to see the problem, and it has to do with the way we handle 'ticks' differently than the original. At the start of BG, there are two scripts executing simultaneously: one for the moongate and one for the Avatar. We use 200ms for each time tick, but it's often, randomly, a little more, like 203-211. The avatar's script has a 'wait for 10 ticks' before the call to start the conversation, and so we schedule that for 10x200 ms. The moongate's script should have been done by then, but those extra few ms for each tick puts it behind.
I'm adding additional debugging output under one of the 'trace' flags to analyze this. I'm still not sure of the best way to fix it though. One thought is to have the 'wait n ticks' command not delay for nx200, but instead to schedule itself for each tick n times. That way it will also get the extra few ms and (probably) be in sync with other scripts. A better solution would be to have everything synchronized better, but that might be riskier as far as breaking things.
One thing which may be the cause is that we always schedule delays based on the current time (SDL_GetTicks + delay) instead of the time at the start of the current game tick. We also tend to use "nonstandard" delays for a lot of things which should probably use gwin->get_std_delay().
Of course fixing these would likely bump into another if the priority queue used to run actions does not preserve the order of the equivalent items already in it.One thing which may be the cause is that we always schedule delays based on the current time of the time at the start of the current tick.
I may have just fixed this, but will wait to see if my change breaks anything else. Previously, the execute_usecode_array intrinsic was scheduling the script one ms, but I believe the original scheduled it on the next tick. Changing that seems to fix the opening sequence in BG.