thaumcraft-5
thaumcraft-5 copied to clipboard
Duplicated golem provision requests
It seems that the way provision requests are handled currently, a provide seal can "claim" a job but the seals that create provision requests aren't aware of this because claiming a job only consists of removing the request from the list. This results in inefficiency - or possibly worse problems, depending on the player's setup - as, say, a Use seal that places blocks in the world can result in several golems grabbing the requested item rather than only the single golem that's necessary to fulfill the task. (It can potentially be even worse should multiple Provide seals be in use for whatever reason.)
You can of course go about fixing it however makes the most sense to you, but since this touches on the API, I would suggest that either 1) provision requests be given a flag for claimed status and that the provide seal set that flag rather than outright removing PRs from the list of requests (but of course they would still be removed once the provide task is complete or fails), or 2) a separate list of claimed (but unfulfilled) PRs be kept and that the check which currently tries to prevent duplicate provision requests be expanded to check that list as well.
As a side note, this inability to truly claim provision requests can be even more problematic for addon authors who want to implement a custom seal that fulfills provision requests in some manner that involves more than simply grabbing an item from an inventory since there can be consequences worse than just wasting time as an item is shuffled around needlessly.
I thought of another way to do this that might be better. (Again, this suggestion ties in to the API so I get more specific on implementation than I might otherwise.) Have a new method which the provide seal calls when it's picking up a provision to see if the provision is still wanted. A seal that requests provisioning would implement, say, ISealProvisioned, and that interface would contain this method and return true if the request is still valid (so in the case of the Use seal example above, it would return false if the position it's attached to isn't an air block any more or a golem is already on the way).
While this method could be checked as part of the seal tick before task creation (to get a golem to come over to the provide seal's inventory), more importantly, it would need to be checked on task "completion" (when the golem is there to pick the item up) since conditions can (and in my tests with the Use seal, do) change between those points; the golem wouldn't pick the item up if the request isn't still needed.