Add ability to cancel the currently worked on job
Adds the missing feature of cancelling and removing the currently running job, as opposed to simply removing the queued up jobs .
Ramblings about hobbyist game development
Add ability to cancel the currently worked on job
Adds the missing feature of cancelling and removing the currently running job, as opposed to simply removing the queued up jobs .
– make the job list hoverable
– add callback to the job to cancel jobs
– add job removal for non-running jobs
This starts to make the the job list interactive. Comes as advertised in the commit message!
Fix lock-up problem when selecting an object that has a non-empty worklist
This was essentially trying to lock a mutex that was already locked.
Manually calculate the work list button size to ensure there are no rounding issues
Just slightly improves the sizing of the buttons, check them out now:
Show and update the work list of the currently selected object (2)
Just some missing files. Whoops!
Show and update the work list of the currently selected object
This adds a list of buttons on the left hand side of the screen that shows which types of jobs are currently in the queue for the selected object.
Clicking on the icons will remove the job from the queue for upcoming jobs and clicking on the currently active one will interrupt it and also remove it from the queue. All that good interactive stuff is not in there yet though, it’s just showing what is currently happening.
Finally we get to use the icon that can be set for a job!
Improve navigation behaviour of controllable objects
What this rather vague message means is “be more inclusive when determining which object categories are considered blockers”.
Make sure to update the UI structures when adding additional funds manually
Instead of just changing the value manually do it through a function which also marks the UI state as dirty. That’s it.
– make a distinction between failed/successful navigation when executing a job
– give the sink a unique identifier
Without this the jobs could get stuck and would also obviously not proceed to the next one, essentially making an object stuck because of a single failed navigation.
Disable actions the user cannot afford
This one is pretty self-explanatory. Just some polishing work for the job actions. 🙂