Better API for interacting with the crafting queue
Posted: Sun Aug 15, 2021 12:44 pm
The current crafting queue API allows you to read the item type, item amount and order of items shown in the crafting queue GUI. But this does not include all the information the crafting system stores.
* Finished intermediate crafts are not shown at all
* There is no way to tell what is an intermediate craft vs final product without using ugly hacks
Here is the code required to read all the information from the crafting queue:
https://github.com/clusterio/clusterio/ ... crafts.lua
Basically, we cancel a craft and read what items we got back, and which items got removed from the crafting queue. This has to repeat until the entire queue is canceled. After that we reconstruct the queue.
This is just silly. There is also no way to preserve the crafting progess for the frontmost item when readding the craft.
https://lua-api.factorio.com/latest/Lua ... ting_queue
https://lua-api.factorio.com/latest/Con ... gQueueItem
https://lua-api.factorio.com/latest/Lua ... n_crafting
The current code works fine, but the reason for this interface request is that we would like to do this frequently in the background, and the current code could lead to lagspikes.
* Finished intermediate crafts are not shown at all
* There is no way to tell what is an intermediate craft vs final product without using ugly hacks
Here is the code required to read all the information from the crafting queue:
https://github.com/clusterio/clusterio/ ... crafts.lua
Basically, we cancel a craft and read what items we got back, and which items got removed from the crafting queue. This has to repeat until the entire queue is canceled. After that we reconstruct the queue.
This is just silly. There is also no way to preserve the crafting progess for the frontmost item when readding the craft.
https://lua-api.factorio.com/latest/Lua ... ting_queue
https://lua-api.factorio.com/latest/Con ... gQueueItem
https://lua-api.factorio.com/latest/Lua ... n_crafting
The current code works fine, but the reason for this interface request is that we would like to do this frequently in the background, and the current code could lead to lagspikes.