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?
Dear forum users! In compliance with the new European GDPR regulations, we'd just like to inform you that if you have an account, your email address is stored in our database. We do not share your information with third parties, and your email address and password are encrypted for security reasons.
New to the forum? Say hello in this topic! Also make sure to read the rules.
New to the forum? Say hello in this topic! Also make sure to read the 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: 25
- Gurt
- Lead Programmer
- Posts: 1884
- Joined: Sun Feb 28, 2016 3:22 pm
- Title: Lead programmer
- Started SFD: Made it!
- Location: Sweden
- Gender:
- Age: 34
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