Script Woes - When to "wait"

"Wait" has always been the most frustrating thing for me because it doesn't seem clear when to use it. In all honestly my intuition is to never wait, unless I actually want to spend some time doing nothing, but that doesn't appear to work. However, I have no idea when to do it.

Here is an example. In my current set up, when the game starts, the title screen and music are to be accompanied by a menu, like most RPGs. I am doing that like this:



The goal here is to blacken the screen, then have it come up with all of the relevant things intact. What actually happens is that a new game is started, I can see the character for about half a second, and then I can see the palette change and then the fade out, which then fades in to the background. Very messy!

I've actually also got another issue, somewhat related. Slices that are drawn to the screen don't seem to be remembered on load. That's no problem, I can just load them again!



This is set, in custom, to my load game script. "Show overlay" works everywhere else: on a new game and every time I enter a new map (which changes day/night.) Finally, my "menu 13" above has "Load Game" which triggers special menu "Load" - which is the way to get this load game plotscript to run.

But it doesn't seem to work! And yet... the script must be running, since palette 0 is loaded correctly, rather than using palette 2 of the title screen.

I'm going to keep messing with it, because I'm sure it's something simple on my end, but if anyone can point me in the right direction that would be awesome.

To my knowledge, wait will, by itself, wait for a single tick unless you specify how many ticks to wait for. I may be wrong, but I don't see why you need the wait that you're using after fade screen out unless you want to wait for an extended period of time, in which case you'd have to specify just how many ticks you want the script to wait.

Though considering I haven't been scripting for some time now (focusing on writing character dialogue) I could be quite mistaken in this.

---

Being from the third world, I reserve the right to speak in the third person.

Using Editor version wip 20170527 gfx_sdl+fb music_sdl

"wait" by itself does nothing (usually). You are waiting for zero ticks with that command.

The fade screen commands don't usually play well with other things, and to get them to work properly, you need to include a non-zero wait between them.

(edit) on further inspection, BMR is correct

---

Mega Tact v1.1
Super Penguin Chef
Wizard Blocks

Actually, that would make a lot of sense. Thing is, I'm going off of the dictionary:



[edit] Ah okay, you've found it. Still, I tried without waits and then I just started sprinkling them everywhere... pretty much to no effect.

Should I just make one that is actually a second or so?

Hmm, I may not be doing this correctly, but I think something like:



might work. Again, my scripting is rusty, so this might not be correct.

---

Being from the third world, I reserve the right to speak in the third person.

Using Editor version wip 20170527 gfx_sdl+fb music_sdl

From the Penguin Chef script:



I'm not sure if the 5 makes a difference versus 1, but this achieves the effect I wanted; namely, making the backdrop and text box appear after the fade out but before the fade in.

Good luck!

---

Mega Tact v1.1
Super Penguin Chef
Wizard Blocks

So, first I tried BMR's method, minus the "wait for menu" which waits until a menu is closed, but we want access to this menu. Also, it needs a handle, and I don't believe 13 is a handle (but maybe I'm stuck on slices.)

Somehow it exacerbated the problem! Instead I saw it show the beginning of the game for quite a while, then when the palette changed later it was slow (and kind of cool looking...)

So, Mogri's method. It worked flawlessly somehow.



But why, I wonder? The ordering was really that important, huh?

Waits are pretty intuitive... except when they get mixed up with fades-- and that is really the fault of the fades, not the fault of the waits.

An important thing to remember about fades is that unlike other palette manipulation commands, they happen instantaneously, and unlike other commands that take some time to complete, fades effectively freeze time, and happen all on a single tick, even though they seem to take many ticks.



This is incorrect. The default value when you say "wait" without specifying a number of ticks is "wait(1)"

I am pretty sure you can get your script to do exactly what you want with no fades whatsoever. I also suspect you have some unwanted delays in your script because I think you actually end up with two fades out and two fades in.

Here is what happens when there is no new game script at all:

* the screen fades out.
* the game starts
* the game runs for 1 ticks
* the game automatically fades in

The fact that you have fades in your new game script does not prevent those automatic fades from happening.

Also, the reason that the game runs for one tick (2 ticks in old versions, I think) is exactly because I wanted it to be possible for new game scripts to set things up before the fade in without having to do the fade in manually.

Try doing just this, and let me know what happens:



If this does not work, then it has something to do with the "load palette" command. Let me know what happens.

To clarify what James meant, especially by "instantaneous": fade screen in/out and update palette are completely different from other commands that change stuff on screen, like placing slices. They happen immediately, redrawing the existing contents of the screen, which is the previous frame, but with a new palette. In the cast of screen fades, the previous frame is redrawn over and over with slightly different palettes, while the entire rest of the engine except audio is paused. That means that


will fade the screen in without the textbox visible, because the screen hasn't been redrawn yet. In general you need to put a wait before a fade in or fade out to cause the screen to be redrawn, if you've changed something visual like a textbox:

Works fine, and your explanations make a lot of sense.

Thanks guys, I think this might help fix some other problems I've had.