otland
addTask(callback, ...) lua function
Pull Request Prelude
- [x] I have followed proper The Forgotten Server code styling.
- [x] I have read and understood the contribution guidelines before making this PR.
- [x] I am aware that this PR may be closed if the above-mentioned criteria are not fulfilled.
Changes Proposed
implements addTask lua c function so we can access the engine g_dispatcher.addTask function like addEvent and g_scheduler.addEvent.
Can you describe an example scenario where having this functionality would be useful?
Can you describe an example scenario where having this functionality would be useful?
If you want the function(task) to be executed in the next frame(dispatcher cycle) asap without any delay.
Can you describe an example scenario where having this functionality would be useful?
If you want the function(task) to be executed in the next frame(dispatcher cycle) asap without any delay.
Sure, but in which example scenario would you want to do that?
the dispatcher executes tasks in another thread is it correct?
Yes, dispatcher and scheduler are using their own threads, but tasks are only executed in dispatcher thread.
I think i may drop this pr and then change addEvent to use g_dispatcher.addTask when the delay is 0.
I think i may drop this pr and then change addEvent to use g_dispatcher.addTask when the delay is 0.
Seems like a much better idea to me
So we should add addTask or internally when someone call addEvent with 0 interval parameter it should add the task to dispatcher?
I still think we should add this addTask function. Why? Its problematic to change this ancient addEvent function parameters, since its has been a given for ages the minimum delay is 100 ms and its also problematic to under the hood make addEvent to add the task to dispatcher instead of scheduler because for the API sake the user script should be able to call addEvent and in the next line call stopEvent and its not possible or easier to implement that cancellable tasks in dispatcher + hacks in addEvent to support tihs. So the only two options for me are: add this addTask function or remove the 100 ms minimum delay from addEvent which will work basically as adding the task to the dispatcher when delay is 0 but will keep the stopEvent function working.
Remove the minimum delay?
Wasn't there a reason this was implemented though?
Remove the minimum delay?
Wasn't there a reason this was implemented though?
Probably a protection for performance reasons.
@nekiro @DanielChabrowski @MillhioreBT @ranisalt I'm willing to finally finish this. We should decide, add this api or remove the minimum delay from addEvent or add something like addEventEx whithout the minimum delay.
@nekiro @DanielChabrowski @MillhioreBT @ranisalt I'm willing to finally finish this. We should decide, add this api or remove the minimum delay from addEvent or add something like addEventEx whithout the minimum delay.
I like addTask and am using it in some of my scripts. If addEventEx works all the same, I have no complaints about it, I'll take it.
@nekiro @DanielChabrowski @MillhioreBT @ranisalt I'm willing to finally finish this. We should decide, add this api or remove the minimum delay from addEvent or add something like addEventEx whithout the minimum delay.
I like
addTaskand am using it in some of my scripts. IfaddEventExworks all the same, I have no complaints about it, I'll take it.
addEventEx would accept below 100 ms delay as parameter so it can work like addTask (with more overhead thanks to the timer system) if the delay is 0 and you will be able to cancel it if you call stopEvent before the task is added to the dispatcher.