I surrender at the idea we won't never see thread implementation in SFD and this brought me to reconsider to split long running functions (containing long loops or recursion) in one cycle per game update.
But the raw implementation could be complex in some cases, even if we don't want to rewrite the whole script logic we need however to save all the variable state within the loop and then skip all the functions declaration step for loading the previously saved variables.
In C# all this is eased by the use of "IEnumerable" functions together with the "yield return" that will make the function "remember" where the execution was stopped and what was inside the variables, but the yield one can't be used in the Script API therefore I assume it could generate harmfull code.
Also using the "task" class could bring at the same result but I don't think it doesn't uses threads.
There will ever be custom made coroutines in the SFDGameScriptInterface or there will always be needed to manually implement some kind of async functions?
This forum is locked and will eventually go offline. If you have feedback to share you can find us in our Discord channel "MythoLogic Interactive" https://discord.gg/nECKnbT7gk
Forum rules
Forum rules
Coroutines in Script API
Forum rules
By using the forum you agree to the following rules.
By using the forum you agree to the following rules.
- JakSparro98
- Superfighter

- Posts: 530
- Joined: Fri Jul 15, 2016 7:56 pm
- Started SFD: PreAlpha 1.0.5
- Location: Rome, Italy
- Gender:
- Age: 27
- Gurt
- Lead Programmer

- Posts: 1887
- Joined: Sun Feb 28, 2016 3:22 pm
- Title: Lead programmer
- Started SFD: Made it!
- Location: Sweden
- Gender:
- Age: 36
Threading (using threads or tasks) will not be supported in SFD as it will cause racing conditions and runtime errors if any manipulation or reading on the state of the game is performed from a thread. The ScriptAPI just isn't build around threads 
However, adding some sort of support around return yield is possible to implement to be able to "pause" execution in the ScriptAPI or perform longer more complex operations over several frames. This is currently not prioritized but something I would like to put in the ScriptAPI in the future.
Here's a suggestion of how it could look if it was implemented (based on certain restrictions around the yield keyword in C# and how the ScriptAPI is designed):
And if you want you could do this:
However, adding some sort of support around return yield is possible to implement to be able to "pause" execution in the ScriptAPI or perform longer more complex operations over several frames. This is currently not prioritized but something I would like to put in the ScriptAPI in the future.
Here's a suggestion of how it could look if it was implemented (based on certain restrictions around the yield keyword in C# and how the ScriptAPI is designed):
► Show Spoiler
► Show Spoiler
3 x
Gurt