Hi,

is there a (simple) way to create sequential Scripts, so the 2nd script is triggered only when the 1st script has finished?

My problem especially for sequences of events in a row (for example several textblocks with, several wait inputs...) is, that Quest processes all the scripts simultaneous. So a "block" or "list" of scripts in the UI is not processed like a computer program with one command/line after the other, rather all commands are begun at the same time.
This is fine for some tasks, but bad for others.

I also have found no way in the UI to add another "block" of scripts that follows the previous, meaning that is only started when the previous block of scripts is done.

Is there a way to tell Quest to process Script one and "add successive script(s)" after it?

Or can it maybe be done with any syntax/logic like...
---
StartScriptA
(here parallel script commands as usual "aaa")
EndScriptA

StartScriptB
(here parallel script commands as usual "bbb")
EndScriptB
---

So the result would be that Quest processes first "aaa" in Step 1 and afterwards processes "bbb".

If I understand what you're saying (and this solution might not work for what you want) when I have a few scripts that I want to separate out I create rooms for those scripts to operate in. I can then add either a timer or a command that simply moves the player object to the next room to trigger the next script.

You can make Quest behave more like Twine by using rooms accessed only by scripts and commands. These aren't rooms accessible in any other way. They're just objects for running scripts in.

And I don't bother with the press any key script. I just set up a command that will check where the player is (hence making it useless elsewhere) and tell the command to move the player object somewhere. Then display it with the text processor. So I disable the parser with:

request (Hide, "Command")

If I recall correctly then put my own next button in with the text processor reflecting the command I set up:

{command:whatever:click next to continue}

use (add) Functions:

(see this thread too: viewtopic.php?f=10&t=5018&p=34407#p34401 )

a Function holds scripts: think of a Function as a basket~grouping (or if you're familiar with some basic programming: Functions = Batches = Macros), which can hold just a single script or many scripts.

Also, another great benefit of using Functions, you can loop them (individual Functions) on themselves, while also continuing your chain of scripting too:

(in code, sorry, but it's fast~easy for me to do it this way, lol)

<function name="character_creation_function">
  age_function
</function>

<function name="age_function"><![CDATA[
  msg ("What is your name?")
  get input {
    if (IsInt (result) and ToInt (result) > 0) {
      player.age_integer = ToInt (result)
      gender_function
    } else {
      age_function
    }
  }
</function>

<function name="gender_function">
  show menu ("What is your gender?, split ("male;female", ";"), false) {
    player.gender_string = ToString (result)
  }
</function>

In the GUI~Editor: Add Function and to 'goto' different Functions, you add in the 'call function ~ call upon function' Script, and just type in the Function's name into the text box, that you want to goto, you can ignore adding in parameters, as this is a bit more advanced, unless you already understand their usage, then go ahead and do so as you might need to.

unfortunately, I am still a bit confused about the 'order of operations' with scripting, so the way that works best is this:

Function1
on ready { // you'll have to code this in, as I'm not sure if and or where it is in the GUI~Editor
-> Function2
-> on ready {
->-> Function3
->-> on ready {
->->-> Function4
->-> }
-> }
}

unfortunately, if you got script layers within the Functions, it's more difficult to get it to work:

Function1A
-> Script1A
-> wait { // or 'get input' or 'show menu'
->-> Script2A
->-> wait {
->->-> Script3A
->-> }
-> }
on ready {
-> Function2B
->-> Script1B
->-> wait {
->->-> Script2B
->-> }
}

// ERROR
// you're going to have multiple scripts and the 'wait' Scripts running at the same time, which they can't do... thus the ERROR.

thus, the best way is again (still not easy to get it to be set up like this... sighs):

Function1A
-> Script1A
-> wait { // or 'get input' or 'show menu'
->-> Script2A
->-> wait {
->->-> Script3A
->->-> on ready {
->->->-> Function2B
->->->->-> Script1B
->->->->-> wait {
->->->->->-> Script2B
->->->->-> }
->->-> }
->-> }
-> }

in code:

(this will, err I hope should lol, work)

<function name="function_1">
  msg ("1")
  wait {
    msg ("2")
    wait {
      msg ("3")
      wait {
        function_2
      }
    }
  }
</function>

<function name="function_2">
  msg ("4")
  wait {
    msg ("5")
    wait {
      msg ("6")
      wait {
        function_3
      }
    }
  }
</function>

<function name="function_3">
  msg ("7")
  wait {
    msg ("8")
    wait {
      msg ("9")
      wait {
        msg ("10")
      }
    }
  }
</function>

Vollkrasser, it would be helpful if you could post actual code that you have tried, as Quest *does* parse scripts statements sequentially. If you have run into a problem with that, then perhaps it is a simple error or misunderstanding which can be addressed given an example we can get our teeth into.

The example you gave doesn't help because you seem to be assuming all scripts run in parallel, which they don't. (If they did, then you'd need some sort of synchronization objects - like mutexs, critical sections, etc - found in standard multi-threaded programming... which are completely unnecessary in Quest). In fact, scripts only run in response to events anyway.

One thing to keep in mind is that no script commands in Quest will block. Any script command that is to wait for an action from the user (e.g. get a key, run a menu, etc) should be passed a script to be run once the action occurs.

Well, thanks, but so far it seems that there is no way to simply let one script follow after another script, as:

@silver: sending the player object round rooms, would flood my game with rooms, as is rather a work-around than a real solution for successive processing of scripts.

@Hegemon: functions are not a solutions, as scripts in a function are treated in the same way as without function. Youre final example code within the function...

msg ("1")
wait {
msg ("2")
wait {
msg ("3")
wait {

...only works as the "wait"s have the "msg"'s nestled within. this works in functions in the same way as in a script in the UI, so there is no need for a function to do that.
But my initial problem is not solved, as only nestled parts in certain commands like "wait", "if" "then" forces Quest to process the statements sequentially.

@jay: well, if no script command does block, then all lines in a script run sort oft felt nearly at the same time, as i can only force sequential processing with certain commands like "wait", "if-then-else"....This causes problems for me for some tasks.
explanaition: in my classical programming knowledge like...
(player triggers something then this should be executed:)

10 do"a" //do several instructions in a order like display picture A s, text A, wait, then display B...
20 wait for a keystroke
30 do "b" //do several instructions in order
40 wait for a keystroke

the programm is processed line by line, causing to do "b" ONLY if "a" is done and a key is pressed.
This is not the case in a script in Quest without nestling: here we would do a and b "at the same time" meaning unblocked one immediately after the other. Also we would have the colliding wait Error as no 2 waits can run at the same time showing the same problem of unblocked processing.

For simple things nestling in "wait" or so is a solution, but why is there no way to really do one script after the other?

ah... there's this:

'on ready'

Script1
on ready {
-> Script2
-> on ready {
->-> Script3
->}
}

http://docs.textadventures.co.uk/quest/ ... ready.html

but, this too may not work for what you want.

The solution *is* the nesting. The "wait" scripts simply change the UI into the "Press any key" state, and then the script continues on and out. If the script blocked at that point and waited for the key press, the engine would lock up and die. (Try putting an endless loop in a Quest game sometime - or a language like Javascript for that matter. It kills everything, including the player and editor, fairly quickly.) The statements *are* being done sequentially. If I do:

msg("a")
msg("b)
msg("c")

then I will see:
a
b
c

What you're referring to is the fact that the "wait" command doesn't itself block until completed but merely initiates the wait. As I mentioned before, scripts that invoke some action from the user (e.g. wait, show menu, etc) use the model of you passing a callback script to be invoked once the action completes. You are, in effect, sending off the script to do the work and saying "then do this when it's done". This is typical of scripting languages (Javascript as an example). The code is all event driven, with short scripts being invoked by the engine.

I know some say, "I don't want to do it that way, with the callback scripts", but that's the way the engine is designed, and it's not an uncommon design.

Where the comparison to a language like the snippet you showed fails is that in your example, those lines are the *entire program*, and you run it from beginning to end, and that's all there is. In scripting languages like Quest, your short bit of script is being invoke *in response to something*, within the context of an entire user environment. It is an event handler responding to an event (even if it's just "the game is starting" event). You can kick off things like "wait" to have the user enter a key press, but then you have to tell the engine how to inform you when the key press is done because the engine has to keep running. To that extent, it's asynchronous (it doesn't sit and wait), but that's the nature more of how those sorts of UI interactions must be handled.

So your example would become:

do"a" //do several instructions in a order like display picture A s, text A, wait, then display B...
wait for a keystroke, and when it's done then begin
do "b" //do several instructions in order
wait for a keystroke
end

You are deferring the script statements until the time when the wait completes.

Jay, thank you for youre detailed answer. I think I understand and agree the event-driven concept of a script being invoked by the engine which is the real "program" in the classical sense.

But i dont agree that nesting is a solution, as it will cause re-nesting with redundant code within the nests. It cant replace a simple programm command like "goto".

Why cant one script not trigger another one? Why is there an engine/user trigger absolutly necessary?

There are some "hardcoded" scripts in a row possible in quest, see room tab "Scripts":
Before entering the room for the first time (script 1)
Before entering the room (script 2)
After entering the room (script 3)

Unfortunately it is not possible to add such separate script-modules at any other place in the GUI.
The button under a script-module adds a line to the same script and there is no way to really create another script following. The existing button should therefore be renamed to "Add new script line", as only in the case of the first line it really creates a script but not afterwards.

Redundant code typically gets relegated to functions. Perhaps that's what you mean by script invoking other scripts? You can easily add your own functions to hold that common code, and then you can call it wherever you wish.

How do we go about creating a function? I know how to do it with js but not aslx.

Ignore that - it's in the tutorial lol.

http://docs.textadventures.co.uk/quest/ ... _Functions

@Silver:

Functions are just like Verbs, in that you add them, name it (the Function, like you name a Verb too ~ when creating a custom Verb anyways), and then add the Scripts that you want.

To Add Functions, you can at least go to the bar at the top of the screen, and under 'Add', choose add function, but I'm not sure of other locations within the GUI~Editor as I don't think 'Functions' are on~in the left side's 'tree of stuff'.

As for 'calling~goto~activating' any Function that you want, all you got to do is to Add the Script, 'call function' or 'call upon function' (whatever it is called), where ever you're working with that can Add Scripts (such as within a Verb or the 'game' Object's 'start' Script or a Function or a Command or etc things, and choosing to: Add a script -> 'call function', I think it's in the 'output' category, but maybe not, just look through all the Scripts, and it's somewhere there, lol. Then, all you got to do is to write in the name of your Function into the text box for it, you can ignore Adding Parameters for now, we'll get to them later on).

I guess the reason why I'm not familiar with functions yet is that you can trigger generic code with them... But most of my scripts are location specific so I've used commands, verbs or timers instead. Which all do the same thing in that they run a script based on whatever condition. I suppose a function can reduce work if a type of script is repeated, but I've yet to find a situation where ONLY calling a function will work, hence me not using it. Perhaps that moment will arrive so it's useful to know.

yes, Functions are global, so you either have to choose carefully where you use them (make individual Functions for each specific use ~ location), or add in a lot of complex 'checking' Scripts within your Functions to deal with all the situations of everywhere you might use it (same as you do with global Commands).

The only example I can think of is with timers... But then they house their own scripts anyway. You could call a function to start a global timer which itself checks conditions to run other functions. You'd totally need that in a massive sandbox game. But I've yet to see one of them appear despite a lot of posters having those ambitions. I'm still yet to get out of my first room. It's been my template for learning and playing with various ideas though. And a touch of laziness.

I haven't got past character creation... laughs, not even starting to create my first room, haha.

Every time I try to work on making a game, I immediately run into the issue of being woefully unable to code in (do) what I'm trying do in making my game, sighs. I immedaitely realize that I need to learn a lot more coding... every time I try to start making a game... sighs.

It's one of those things - when you need it, you'll know.

My first room has taught me pretty much all I need to know about Quest for my needs. I've still got to implement the CSS so there isn't resolution problems and I'm doing ultra polish, which is what unearthed the container bug I think I found. If I can't reproduce it in a demo game then it's something I've done so back to the manual then polish again.

I had meant to say, from what I saw, your game looked amazing.

Aw, cheers man. It's still in the experimental stage ... I'm not confident enough yet to rip through the plot but it is sort of story boarded in my head.