Improve resource, pipe and chest logic#16
Conversation
When checking a drill for remaining resources, check for resources matching any of that drill's compatible types.
Re-scan for depleted miners when fluid miner setting is newly enabled. Improve debug prints for resource types.
* Calculate max_radius based on all prototypes in the game, rather than checking every single entity when it is built to see if it has a larger radius. * Add filter to on_deconstruction_cancelled event.
* Calculate max_radius based on all prototypes in the game, rather than checking every single entity when it is built to see if it has a larger radius. * Add filter to on_deconstruction_cancelled event.
Change pipe placement to utilize the direction-specific connection coordinates contained in the prototype data, rather than assuming symmetrical rotation.
* Removed unneeded validity checks for a fluidbox we know exists. * Only build pipes if this miner has more than one connection. (If a row depletes uniformly from the very end, no pipes are ever needed.)
* Fixed a logic error when checking if another miner is still using a chest. * Simplified the search code to find entities targeting the chest. * Fixed a crash if an inserter is nearby the chest but not targeting the chest.
* For burner miners, checks for inserters targeting the miner and deconstructs them too. Note: Only case not covered is if an inserter is *taking* fuel from this miner in a daisy chain, in which case you might not want it to be deconstructed at all.
* Added logic so that pipes are only built to connections in use. (This will fail if connected to a very rectangular entity or if there are more than one pipe connection on one side of the miner.) * Added logic to not deconstruct a burner miner that is a source for an inserter moving fuel around.
|
Pretty sure this PR is complete. Can't think of anything else to add, unless you want to put the new inserter logic under a new setting. Appreciate if @nicolas-lang can test my changes. |
| end | ||
|
|
||
| function autodeconstruct.init_globals() | ||
| -- Find largest-range miner in the game |
There was a problem hiding this comment.
There might be a risk that a drill that is larger gets added after initialization and so gets missed, perhaps that can be solved by updating the global when the game gets loaded
There was a problem hiding this comment.
That will be caught in on_configuration_changed, when the prototype list is searched again. It fires whenever any mod is added, removed, or updated.
| local _, err = pcall(autodeconstruct.on_cancelled_deconstruction, event) | ||
| if err then msg_all({"autodeconstruct-err-specific", "on_cancelled_deconstruction", err}) end | ||
| end, | ||
| {{filter="type", type="mining-drill"}} |
|
Thank you, much appreciated! |
| end | ||
|
|
||
| -- Connection position index is different from entity.direction | ||
| local conn_index = 1 -- north |
There was a problem hiding this comment.
defines.direction is an int type
since there seems to be no define for conn_direction I would simplify this using math to something like math.floor(drillData.direction/2)+1 and add a short comment reference to the direction defines prototype page
There was a problem hiding this comment.
Hmm I did that at first, wasn't sure I liked assuming that those constants never change and that it always is even. But I guess it is impossible to rotate any miner 45 degrees.
There was a problem hiding this comment.
your current code would still break in a 45° rotation, similar to mine, it would just break slightly different, and in such a situation I usually prefer the solution with less code lines
There was a problem hiding this comment.
Mine would default to North. With divide by 2 in the index, it would crash on a fractional index unless round() is used to get to closest cardinal direction. Ah you already caught that.
There was a problem hiding this comment.
100% agree that's why I am suggesting math.floor which is similar to round. This way mine would assume the "nearest" rotation - This would probably still break "in-game" like your "default north" does. But we both agree since drills can not rotate 45° it is not an issue. --> Similar result: use the shorter code.
- Return the integer no greater than or no less than the given value
3 participants
neighbours(thanks Factorio discord!)