Loops aren't threaded but functions are???

I'm not entirely clear from your posts what is actually happening vs. what you expect to happen. It's much easier to share project files so they can be run directly and adjusted if necessary.

It's normal that if FuncA calls FuncB, then FuncB will complete and return before FuncA does. The exception to this is if you add 'Wait'. It's very similar to using setTimeout in Javascript, and running the rest of the function in the callback to that method. This means that the function returns early with the default return value, all other events run to completion, and then at some point later on the timeout happens and the rest of the code runs. By this point it's too late to return a value from the function: it's already finished. Therefore the return value will be ignored.

This is, again, normal behavior in computing: as it stands Construct functions are synchronous, but anything involving 'Wait' essentially makes the events asynchronous. In general calling an asynchronous function from a synchronous one will mix up the execution order, as the synchronous function will not wait for the asynchronous one to complete. This is not specific to Construct and is typical of programming in general.

It's common that people run in to a problem and then they immediately blame Construct. I would discourage you from doing this - not only is it somewhat tiring, it's also not the best way to investigate and diagnose a problem and will probably just send you on a wild goose chase which will only increase your frustration. A better approach is to basically take a debugging approach. For example you could add console logs frequently through the events, with messages like "Starting funcA", "Finishing funcA", "Step1", "Step2" etc. Then you can easily see in the console the specific order that everything ran in. This then helps figure out where things are diverging from what you expect, and helps you hone in on why. Chances are it's working as designed (but remember events are a pretty different paradigm to traditional programming languages, so in some cases the intended design may not be identical to other typical languages). Even if you become convinced it's a bug, you then have a project ideally set up to either share on the forum to ask about why it's working that way, or post to the bug tracker as a project demonstrating what you believe to be a bug.

On the other hand, if you just keep making random changes to an event sheet, and always want to blame something other than the logic of your events, then yeah, you'll probably have a hard time making progress!

It's common that people run in to a problem and then they immediately blame Construct. I would discourage you from doing this - not only is it somewhat tiring, it's also not the best way to investigate and diagnose a problem and will probably just send you on a wild goose chase which will only increase your frustration. A better approach is to basically take a debugging approach. For example you could add console logs frequently through the events, with messages like "Starting funcA", "Finishing funcA", "Step1", "Step2" etc. Then you can easily see in the console the specific order that everything ran in. This then helps figure out where things are diverging from what you expect, and helps you hone in on why. Chances are it's working as designed (but remember events are a pretty different paradigm to traditional programming languages, so in some cases the intended design may not be identical to other typical languages). Even if you become convinced it's a bug, you then have a project ideally set up to either share on the forum to ask about why it's working that way, or post to the bug tracker as a project demonstrating what you believe to be a bug.

Where the hell did this bitch slap come from?

If you read my posts, nowhere did I blame Construct. I did ask if this was a bug which is not an indication of blame. When I was told the reason, I blamed JS.

The way I discovered this WAS through a debugging approach whereby I inserted a breakpoint at the start of the event sheet and watched as it sent back a return value from a function without completing the function. In my coding experience I have NEVER seen a language that has anything I can insert in the middle of a function that tells it to both complete AND break out of the function at the same time, which is what Wait 0 is doing. While I do see the potential benefit of doing that in rare circumstances, it's not something I've encountered ever before and therefore is not something I would habitually look for as a coding error which is why it took me hours to finally track down. Furthermore, IMHO, the fact that Wait 0 and Wait 0.01 do two VASTLY different things (if what I'm seeing is correct) is also absurd.

And if you keep reading my posts, you'll also see that I did create a test project, which I shared and which demonstrated why the Wait 0 in a function is nothing short of illogical. By simply turning it on or off, I can completely change the order in which functions are completed.

On the other hand, if you just keep making random changes to an event sheet, and always want to blame something other than the logic of your events, then yeah, you'll probably have a hard time making progress!

What? Where the hell did you get that I was making random changes? My logic? Is that some petty insult? You're accusing me of being stupid and illogical in my approach to solving this? Well, I know how to respond to that. I can take me and my stupid illogical wallet back across the pond.

*grabs popcorn*

I don't understand why you'd use this weird setup with return value. Why not just do

FunctionA

FunctionB

FunctionC

...

And maybe use signals/wait for signals if needed?

*grabs popcorn*

I don't understand why you'd use this weird setup with return value. Why not just do

FunctionA

FunctionB

FunctionC

...

And maybe use signals/wait for signals if needed?

The reason I inserted waits into my functions was because I was doing a bunch of functions. The purpose of the waits were to temporarily stop loops and whiles (which I've also learned can't be done without making an infinite loop) to update a progress bar or some such. And that is something that was suggested to me in a previous thread as a way of pausing a loop to show progress. So I stupidly assumed that if Wait 0.1 worked then Wait 0 should work the same way only faster.

That return value was inserted as a result of debugging because was trying to force it to wait for the previous functions to complete before executing the code below it, which it was having none of because a single Wait 0, buried 4 functions deep, was causing it to return that 1 regardless of whether everything else had been completed or not.

Yea, signals would have worked, I was trying to be expedient.

The purpose of the waits were to temporarily stop loops and whiles (...) to update a progress bar or some such.

I'm not sure I understand the idea here, but, if this whole engineering is to update a progress bar step-by-step, you should consider using a timer.

Cheers!

Doesn't seem to happen here, Fengist...

Check this file.

You don't need any "wait" for the functions to be executed in the correct order.

Without seeing your file is hard to tell the problem, but something must be messing up your logic...

Cheers!

Change your code. Add just a Wait 0 here:

* On function 'doLotsOfStuff'
-> System: Wait 0 seconds
-> Text: Append " Starting to execute doLotsOfStuff" & newline
----+ System: Repeat 10 times
-----> Text: Append " Doing " & LoopIndex +1 & " stuff" & newline

----+ (no conditions)
-----> Text: Append " Finished executing doLotsOfStuff" & newline