"On ready" seems not to work anymore, though I swear it was working in q5.7. I can no longer stop quest from proceeding while waiting for timers, "get inputs", and "wait" links to be concluded. What's going on?

I scripted a bunch of wait last night, seems to be working just fine. Not sure what's going on.
Someone in the loop?

It has not been changed, though I have not tried it recently. However, it only works for script commands, such as show menu, not functions such as ShowMenu. More here:
http://docs.textadventures.co.uk/quest/blocks_and_scripts.html

I posted a function a while back, WhenReady, which does the same thing but also waits for the ShowMenu function.

It doesn't work with timers, because there isn't a clear indication that timers can finish; it's perfectly legitimate for a timer to repeat as long as the game keeps going, and you wouldn't want on ready to wait forever for it.

Ok, as for timers and "get inputs", on ready never worked on them. I misspoke about them.

As for timers, there needs to be a way to wait on them -- how else can you make Quest pause for a few seconds, say? The only workaround I could come up with is to use sound blanks that must finish, but they have their own limitations (such as interrupting soundloops that precede them, and messing up timers that follow them).

As for wait links in my game, on ready used to keep scripts at the same level as the wait script from proceeding (in Q5.7), but now it doesn't. Don't know why. I came up with a workaround, but now that's one less option that I have.

For timers, SetTimeout might be what you want.

With regards to wait, I just tried this and it worked okay, not showing message 4 until after message 2.

msg ("message 1")
wait {
  msg ("message 2")
}
msg ("message 3")
on ready {
  msg ("message 4")
}

@ThePixie:
The problem with SetTimeout is that it's non-blocking, which is why I use sound blanks now.

With regards to wait, thank you for testing it out. I guess it's something on my end.

I’m thinking this is why Alex threw the towel in. He wanted to start anew with Questkit then realised the work involved and couldn’t stomach it. But there was obviously a reason why he wanted to stop developing Quest - perhaps because it’s become bloatware with Elastoplast over Elastoplast.

Ok, now I think I understand how on ready works! The problem I had with my wait links was that I had on ready ONLY in those same sections of scripting. You have to place on ready in every section AFTER that (where code will run) that you want to wait. In my case, it was my turn scripts that was interfering with my wait links. So, as a drastic measure, I have placed on ready scripts at the beginning of every one of my turn scripts! Everything seems to work now (fingers crossed).

Does that sound sensible/feasible, placing on ready at the start of every turn script? Or is that overkill?

Silver said:
I’m thinking this is why Alex threw the towel in.

Yeah... To my knowledge, there's no way to get Quest to run without Windows (under WINE on Linux (or on a Mac, if that's a thing)); Questkit needed all new code written (and it was for coders -- no GUI); Quest 6 also required a total rewrite; and QuestJS... I say, "[EXPLETIVE DELETED] QuestJS."

I tried to get QuestJS operational (with a little help from my friends, especially mrangel and Pixie). It drove me more insane than I normally am.

Dcoder said:
Does that sound sensible/feasible, placing on ready at the start of every turn script? Or is that overkill?

I don't know...

I don't understand what you mean.

Oh, wait! I see now! Yes; that sounds sensible to me.

Much gratitude to you such an incredible sum for sharing! I will form a post soon about continuing with your direction.Expertise comptable Guadeloupe

Much gratitude to you such an incredible sum for sharing! I will form a post. . .

Spam spam spam spam...

Spammity spam!

Wonderful spam!!!