Runtime order of actions asynchronous or not.. nested actions don't seem to run

This is a weird one but it seems that when I'm constructing if statements with conditions, and using the Call action command, (so i can re-use long actions to set lots of other conditions and values) nested actions don't seem to be getting called.

There's a possibility I'm misunderstanding the runtime order of these actions, or experiencing a logic/typo error on my behalf, but I get the feeling something isn't right.

A simple hypothetical example here.... I have 3 actions A1,A2,A3, and two conditions C1,C2 and one value V1:

A1: "At beginning of scene":

if C1= true
call action A2
end if

if C2 = true
call action A3
if V1 > 4
Display narration text "yay it worked"
end if
end if


A2: "does a lot of stuff but importantly it changes V1"

do stuff
do stuff
do more stuff
set v1 = 5
do stuff
do stuff

Now if C1 and C2 = true, you would expect the narration text to be shown... but it isnt.

It seems that when I call another action, that "child chain" of execution doesn't complete before, the parent action moves on.

Or conditions and values updated in actions called by other actions are not updated in time for the caller to notice the change.


Am I going crazy/ dealing with a typo in my code or stumbling across a known bug?

Any help would be gratefully received.

Actions aren't called nested, they work like a pile and call action throws the action the pile but first the current action is finished. Only way around that is using wait 1ms, so the action will be continued in the next frame.

I've just setup this simple example, and as i expected it doesn't print the text.

In fact when I changed the if V1 > 4, so it says if V1 = 0.... it works

Proving that the value hasn't been updated by action 2 by the time the C2 condtion is checked.

What's going on? I'm using V4.0 beta btw

Really?

I was hoping that wasn't the answer... this limits the action system hugely!

I have large lists of things that need dynamically changing on certain scenes because of different conditions, what is the point of being able to call an action elsewhere, if it wont actually execute until the current action gets all the way to the end??

Surely people have come across this as a massive limitation?

Ive just tested the pausing theory.. and it seems it takes 30 milliseconds to catch that next "cycle" of execution.

if C1= true
call action A2
Pause for 30 milliseconds
end if

if C2 = true
call action A3
if V1 > 4
Display narration text "yay it worked"
end if
end if

Now this means that either the 2nd if statement is now happening on the next "frame" so A2 has completed, or it just takes a while to execute nested actions.

Does one of the VS programmers have a definitive answer, as I don't want to seem rude, but this seems like a pretty big issue for a scripting system, that you have to pause the action to complete the scripts in time?

SimonS is one of Visionaire Studio devs mate.

Only thing I can tell you about the action system is that it reads them 1 line after the other; well something along those lines which is same with lua script.

It should actually update somewhere between 1 & 5ms (it seems to vary, based on some print to log tests I did with the mainLoop handler).

Also based on what you wrote: C1 & C2 are not linked... from what I can see the display text would only be displayed if c2 is true & v1 is more than 4. You ended the c1 query with the end if action part.

By the way I hate doing if queries in the vs editor.


note: you can't do display text with lua but can start & stop actions etc.

I don't like the behaviour myself, but the engine is designed that way and changing it now would render almost every game incompatible...
It was just not built to do nested complex queries, more like "display text" "if char is here" "display text", as simple as simple gets.

Like AFRLme I prefer Lua for many things The action system really needs some overhaul in usability for me...

Thanks for the reply, really appreciate all the hard work that's gone into VS, and can see how this would have horrible knock on effects for those existing games, if it were changed now.

In a way its been a good lesson to learn, its caused me to re-think how i use the actions, and simplify the overall progress handling of my game.

I'm not averse to doing more LUA, (I'm a long term AS3/JS coder by trade) I just cannot seem to get to grips with the VS data structure, even after reading the wiki, I'm left confused. I always feel unable to bug test it and unsure of the structure when referencing the tables (with the leading V being a prime candidate for confusion, and the direct or via scenes/objects access of variables, which seems inconsistent)

Maybe I just need to study it in more detail, and spend less time making my game

Thanks again for the advice, I'm always impressed with this forum and its members ability to give great answers.

In regards to the getObject things: It is recommended that you actually link through the scene, object, action etc itself as opposed to using the short/quick method. I don't tend to use the long method because I'm careful not to duplicate names of objects, conditions & values. You might have some errors/issues if you used the short method & have 2 or more conditions, values or whatever with the exact same name.

I'm not sure why we have to add the "V" part either... I think it's mentioned somewhere on the scripting page though.

Certain things you have to actually use getObject/getLink to update some of the data structure tables, such as the VGameStandardLanguage one for example.

The V part is just something that many seasoned programmers use to distinguish types of constants. Like eMouseLeftDown or something. The V stands for Visionaire I believe Wouldn't have needed that, but if you're used to name everything like in your naming conventions (every class name starts with a T or so) you continue doing that.

I don't see the problem with the action system. some prefer a GUI to define the actions, others prefer to code. So everyone should just use the system (GUI or Lua) which suits him best.

you're right that the called action should be executed immediately and not after the calling action finishes/pauses. It would be easy to change that but as Simon said it would make many games incompatible. A solution would be to keep it that way for existing games and change the call order only for new games. I'll have a look at it.