Page 1 of 1

New "Thread"

Posted: Tue Jun 27, 2017 10:45 pm
by kirill240
Hey guys.
Very long time I wrote DM. When the player died, I created a timer, so he was resurrected after a certain period of time. It's pretty convenient.
1) And now I have a question, how do I better organize several threads, through timers or use the Thread class?
2) There is one more problem related to IDialogue. When the dialog is not closed, the ElapsedTime property in any case is 0. What should I do?
3) Can I use the async await statements in the code?

Re: New "Thread"

Posted: Wed Jun 28, 2017 12:25 pm
by JakSparro98
kirill240 wrote:
Tue Jun 27, 2017 10:45 pm
Hey guys.
Very long time I wrote DM. When the player died, I created a timer, so he was resurrected after a certain period of time. It's pretty convenient.
1) And now I have a question, how do I better organize several threads, through timers or use the Thread class?
2) There is one more problem related to IDialogue. When the dialog is not closed, the ElapsedTime property in any case is 0. What should I do?
3) Can I use the async await statements in the code?
1) We cannot use the Thread class but in future there will be coroutines to avoid some performance related problems.
2) I didn't played so much with the IDialogue but it seems that 0 is for make the text stay the right amount of time to let the player read, based on how many words or letters are showed, I think, so keep that value unchanged.
3) As I said above, this won't happen, but there is a planned solution here.

Re: New "Thread"

Posted: Wed Jun 28, 2017 7:57 pm
by Gurt
JakSparro98 wrote:
Wed Jun 28, 2017 12:25 pm
kirill240 wrote:
Tue Jun 27, 2017 10:45 pm
Hey guys.
Very long time I wrote DM. When the player died, I created a timer, so he was resurrected after a certain period of time. It's pretty convenient.
1) And now I have a question, how do I better organize several threads, through timers or use the Thread class?
2) There is one more problem related to IDialogue. When the dialog is not closed, the ElapsedTime property in any case is 0. What should I do?
3) Can I use the async await statements in the code?
1) We cannot use the Thread class but in future there will be coroutines to avoid some performance related problems.
2) I didn't played so much with the IDialogue but it seems that 0 is for make the text stay the right amount of time to let the player read, based on how many words or letters are showed, I think, so keep that value unchanged.
3) As I said above, this won't appen, but there is a planned solution here.
Gurt wrote:Threading (using threads or tasks) will not be supported in SFD
Just to clarify: We do not have anything planned to support threading in the script API.

Re: New "Thread"

Posted: Thu Jun 29, 2017 12:07 am
by JakSparro98
Gurt wrote: Just to clarify: We do not have anything planned to support threading in the script API.
Indeed, not threading but async loops, I thought something like coroutines would be implemented, maybe the topic I quoted was just a possible suggestion and nothing planned, I misunderstood it for all the time...

Re: New "Thread"

Posted: Thu Jun 29, 2017 11:01 am
by kirill240
I tried backgroundworker and it works

Re: New "Thread"

Posted: Thu Jun 29, 2017 12:04 pm
by JakSparro98
kirill240 wrote:
Thu Jun 29, 2017 11:01 am
I tried backgroundworker and it works
How can it be possible? because all the namespaces available do not allow us to use background operations and so to open threads, can you explain better?

Re: New "Thread"

Posted: Thu Jun 29, 2017 12:13 pm
by kirill240
JakSparro98 wrote:
Thu Jun 29, 2017 12:04 pm
kirill240 wrote:
Thu Jun 29, 2017 11:01 am
I tried backgroundworker and it works
How can it be possible? because all the namespaces available do not allow us to use background operations and so to open threads, can you explain better?
system.componentmodel.backgroundworker worker = new system.componentmodel.backgroundworker();
//Other code
With "Task" and others is the same story

Re: New "Thread"

Posted: Wed Aug 16, 2017 1:32 pm
by Motto73
Oh, wow, something that lets us create "threads". I tried doing them via System.Threading.Thread, but it obviously gave permission error, as did System.Io things. I hope that we some day get a real way using i/o and some standardized ways of tasking, whatever is the plan now.

Maybe we can use pointers and unsafe code to read and write files while we dont have any other supported ways... dunno, gotta check if its possible.

Re: New "Thread"

Posted: Wed Aug 16, 2017 2:12 pm
by JakSparro98
Motto73 wrote:
Wed Aug 16, 2017 1:32 pm
Oh, wow, something that lets us create "threads". I tried doing them via System.Threading.Thread, but it obviously gave permission error, as did System.Io things. I hope that we some day get a real way using i/o and some standardized ways of tasking, whatever is the plan now.

Maybe we can use pointers and unsafe code to read and write files while we dont have any other supported ways... dunno, gotta check if its possible.
I'm very interested using paralelism but threading in SFD scripts it's not worth the pain because you cannot access objects behind a thread, well, you can but you have to synchronize the new thread with the main thread and I still didn't figured out how.

Someone could say "why we need to synchronize the new thread if we can use it even immediately?" imagine this: in the main thread, when the scene finishes loading it is "disassembled" to reload all the scene again, if the thread accidentally wants to access an object when the scene is disposed you will get a NullReferenceException because, of course, it isn't loaded yet but the script cannot handle exception through threads and as a result the whole process hangs.

Currently I've implemented some kind of coroutines with the IEnumerator class (based of concurrency and not parallelism), still cannot get the perfect balance between performance and code reactivity, in case we cannot use threads we just need to know that Gurt managed to put game and AI code all in one thread, maybe using a similar solution.

Re: New "Thread"

Posted: Thu Aug 17, 2017 11:44 am
by Motto73
JakSparro98 wrote:
Wed Aug 16, 2017 2:12 pm
...

Currently I've implemented some kind of coroutines with the IEnumerator class (based of concurrency and not parallelism), still cannot get the perfect balance between performance and code reactivity, in case we cannot use threads we just need to know that Gurt managed to put game and AI code all in one thread, maybe using a similar solution.
O yea, it would be good if the AI could be executed in its own thread. Maybe it could be used with some attribute in a method that uses AI? Maybe like, Ai class should be its own thread, acting like an user and inputting stuff?

Re: New "Thread"

Posted: Thu Aug 17, 2017 1:41 pm
by JakSparro98
Motto73 wrote:
Thu Aug 17, 2017 11:44 am
O yea, it would be good if the AI could be executed in its own thread. Maybe it could be used with some attribute in a method that uses AI? Maybe like, Ai class should be its own thread, acting like an user and inputting stuff?
Like in Unity 3d the APIs are not thread-safe, but this doesn't mean you cannot perform actions that doesn't require object references, you can even process a whole path for an entity requiring pathfinding in a separate thread, but all the information needed have to be passed at the moment the thread start cause they won't access, for instance, to an object position through GetWorldPosition(), even if you stored the object reference before the new thread started (since, as I already said, It's like the object never existed)