Skip to content
Snippets Groups Projects

Feature/scheduler

Merged username-removed-1366591 requested to merge feature/Scheduler into dev

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • I've done a bit more thinking about this one, and I'm not comfortable with the use of register to execute the tasks. Register is meant to be used to register callbacks, and shouldn't actually be getting called within our run loop.

    I would prefer to see the addition of Task.execute that gets run every tick and calls execute on any tasks that have execute defined. Inside that execute function would be a check for whatever conditions they want.

    I would also like to see a registerProcess or something to that effect that takes conditions and run as parameters.

    Generally, our current concept of Tasks is a bit unclear, but I also feel there should be a clearer distinction between the use case for something that is checked every tick vs our current use of LiteEvents to provide callbacks.

  • So that means we have some more work to do to get that out of the main loop.

    Yeah the Task.execute can easily be done.

    For the registerProcess do you mean you want an array of processes and a registerProcess function to be able to push to it? Then it will also need an unregisterProcess function and maybe even an extra name or id parameter. It would, however, enable the possibility to add and remove processes programmatically from elsewhere in the code or from the console, so that would be pretty cool. Maybe we also want a runProcess to force them to run regardless of conditions.

    I don't think it's too unclear once you start looking at how it works.

  • Maybe you can describe to me how I would register a process using this new mechanism. It seems like there is an array of processes already provided, and currently you would just edit this task to add new processes?

    I do agree that there seems to be a need for arbitrary user-defined processes, I'd just like to make sure we don't end up duplicating functionality by adding processes which would be better handled using callbacks.

  • Okay here goes:

    I guess the array doesn't need to be empty as long the structure of each object is consistent. We could hardcode processes like I did for the example one there and then still have the possibility to register more through methods.

    Registering a process would basically push an object with {name:, conditions:, run:} into mod.processes. Unregistering would splice it out. Still thinking a forceRunProcess() or something like that could be useful.

  • Ok, that makes sense to me, yeah registerProcess would push the process to the list of processes, and unregisterProcess would remove it, forceRunProcess sounds useful as well. So this tasks' register function could be where all of the hardcoded processes are added.

  • Ok that sounds good. Yeah in that case we would need something to initialize the 'hardcoded' processes through that method. Like an initializeProcesses but I think hardcoding them is simpler unless you want to have that too.

  • We still need to make Tasks register outside of the main loop. Maybe in global.install()?

  • Yeah, I'm afraid I may not have enough understanding to make the call about where register should go, perhaps we just leave it where it is for now, the main part is not to be executing during the register "phase"..

  • This looks great, good clean implementation, I will make the time to run this today, barring any major errors I think it should go straight into dev for people to play around with.

  • Hah thanks! I like to hear that!

  • username-removed-1357377 approved this merge request

    approved this merge request

Please register or sign in to reply
Loading