Factorio Forums

Issue: Remove(RMB) furnace to crash ----
Some explanation:
Custom furnace is made especialy to exploit fluid engine limitations. From top there is regular pipe connector in group with underground connector from upper right. From bottom there are two isolated underground connectors. My goal was to create setup where there are no blocked undergrounds (so teleport is not rejected because of entity being connected to blocked fs), but i wanted furnace to be teleported out of this setup where it would mix fluid and so teleport should be reverted but fluid systems would be already mixed so even rejected teleport would perform mixing. Connectors are specialy ordered so that removing entity itself should be enough to do fluid mixing. Intended scenario: bottom two furnace connectors disconnecting first, allowing outer bottom pipe-to-grounds to connect (blocked), then removing upper right furnace connector doing block exchange(as in sneaked gif in 74614) from bottom underground pair to upper underground pair and then rejected teleport would connect upper pipe with upper right underground doing mixing(exactly like in 74116). Something went wrong and instead game crashed.

*cough* "deferred block fix"(viewtopic.php?p=450912#p450912) *cough*

New drinking game, "Dangerous Fluids":
Take a shot each time boskid makes a fluid-based bug report.
Please, everyone, do NOT drive after playing this game. It's preferred that you crash on the floor, instead.

Thanks for reporting this. I have some underground pipe connections in my new buildings (necessitated by the bug fix a few versions ago that broke the hacked solution), and haven't run into this yet, but will now know to try to avoid it.

I think that this should, generally, work. But there is that weird thing with making the connection to that random place. I know it was happening in another report too and I fixed the whole thing before investigating this detail. But it seems to be important and I think that if I fix that, then the whole thing could work.

My preferred solution though is not having underground connections on assemblers at all. The space for problems there is limitless. And I don't think that it brings much into the game.

Adamo wrote: ↑

Mon Aug 19, 2019 10:27 pm

I have some underground pipe connections in my new buildings...

Can you tell me more about what you use it for?
If you can tell me honestly please - do you use it because it fits into the overall design of your mod and makes it better, or you use it because it is there?

Dominik wrote: ↑

Fri Aug 23, 2019 12:50 pm

Can you tell me more about what you use it for?
If you can tell me honestly please - do you use it because it fits into the overall design of your mod and makes it better, or you use it because it is there?

It fits strongly with the design of the mods. But the best answer is "both", because I've been interested in designing mods to use things that aren't already available; after all, isn't that the point? You can see one case in my published "cinefaction" mod, where there is an assembling-machine called the Still which does oil-processing using a burner energy_source, and the graphic has a small footprint, so one input uses the underground entrance. It's an interesting alternative to the vanilla machines, which is the goal of the cinefaction mod. That's a simple case. But in an as-yet-unpublished mod I have what I think is a very cool building called the Chemical Reactor that looks sort of set into the ground with a spinning mixer that comes out of the structure. The fluids fall into it using several underground connections. That mod also programmatically separates chemistry recipes from the entire data.raw.recipe (this becomes fun with big chemistry mods like drug lab) into various categories that correspond to the handful of buildings provided by the mod, each with balanced benefits and deficits. The aesthetic and sizing (note the difference in how one fits beacons based on the length of the underground connection) plays into that mod in a strong way, adding to its character. The visual effect is very cool. Just to make my case clear, I would be sad if we stopped allowing this.

Those are the most notable use cases. I've noticed no instability, and I've been using them heavily on persistent, large multiplayer servers, under sometimes laggy and fully-beaconed conditions.

Adamo, thanks for your response Yes, I respect that it is useful. I am trying to see the options.
Bugs like this one are very unlikely to encounter accidently and I think that if the assemblers are modded in a reasonable way, it should work fine. On the other hand some modders try to push things to the extreme and then bugs can happen.

Boskid I see what you did here, that is very wicked. Basically batching more operations so that you create and exploit the pipe block in one move and I can't counter it. Yeah I don't think I can beat that

At this point we are considering the cutoff and just fixing any mixing that is found defensively. I will give some more thought to those deferred operations and see if it could, in the end, save some work.

Dominik wrote: ↑

Mon Aug 26, 2019 9:53 am

Hi Dominik,
Thanks for the response. Just responding to say that I like to test the extremes of how these features work, too, especially because I like to see if I can break them so I know what not to do. I'm just volunteering to help test this or that. I can write up entities quickly. Let me know how I can be useful.

Adamo wrote: ↑

Mon Aug 26, 2019 10:27 am

Dominik wrote: ↑

Mon Aug 26, 2019 9:53 am

Hi Dominik,
Thanks for the response. Just responding to say that I like to test the extremes of how these features work, too, especially because I like to see if I can break them so I know what not to do. I'm just volunteering to help test this or that. I can write up entities quickly. Let me know how I can be useful.

Thanks for your offer We have couple modders here for such things. But please report bugs that you run into.

Boskid, what exactly are you doing in the first gif?
If I mine the furnace, then it crashes. Reason is some bad connection logic - it first destroys the energy source and the left pipe tries to connect to the one on the right when it should not. That is fixable.
When I teleport the thing away, it actually works correctly, ending up with the bottom connection blocked. Which surprises me
But how do you do what is in the top gif?

This one was "live record" when building everything by hand. Not loaded from save. Different build order of external undergrounds give different results of crashes, hangups or diagonal blocked undergrounds. I will try to reproduce it again

-- edit:

I hope this is enough to reproduce this diagonal. Since it was not crashing i was able to record replay of it: When building, it connected to upper assembler. On first replay it connected to first assembler. On second replay it almost hang but there was vertical "blocked" marker going straight down from lower left underground. On third replay block was to some random block inside upper assembler. Good part is that it is not crashing so should be "enough" reproducible to catch the bug

-- edit:
Above file is "replay". However when loading, weird things may happen, like this (why there are 5 empty alerts?):

I am now working on the crash part but I am sure with this it will be reproducible. Many thanks!
That diagonal looks like the search kinda goes forever or something? I have no idea how but I have no idea how any of those weird direction connections could exist.

Here i have more of this "wicked" cases: Issues:

1. Remove furnace "C" -> crash (PipeToGround::updateFluidBoxPointer)
   log

   Code: Select all

   c:\cygwin64\tmp\factorio-build-3kglwi\src\entity\pipetoground.cpp (222): PipeToGround::updateFluidBoxPointer
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidbox.cpp (560): FluidBox::FluidBox
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidmanager.cpp (96): FluidManager::changeFluidSystem
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidmanager.cpp (135): FluidManager::assignFluidSystemRecursive
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidmanager.cpp (535): FluidManager::removeConnection
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidbox.cpp (815): FluidBox::setupUndergroundConnection
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidbox.cpp (1073): FluidBox::onDestroy
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidboxmanager.cpp (589): FluidBoxManager::onDestroy
   c:\cygwin64\tmp\factorio-build-3kglwi\src\entity\craftingmachine.cpp (491): CraftingMachine::onDestroy

   Code: Select all

     26.330 Error PipeToGround.cpp:222: this->fluidBox == oldAddress was not true

2. Remove furnace "D" -> crash (FluidBox::setupUndergroundConnection)
   log

   Code: Select all

   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidbox.cpp (768): FluidBox::setupUndergroundConnection
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidbox.cpp (1073): FluidBox::onDestroy
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidboxmanager.cpp (589): FluidBoxManager::onDestroy
   c:\cygwin64\tmp\factorio-build-3kglwi\src\entity\craftingmachine.cpp (491): CraftingMachine::onDestroy
   c:\cygwin64\tmp\factorio-build-3kglwi\src\entity\entity.cpp (302): Entity::forceDestroy
   c:\cygwin64\tmp\factorio-build-3kglwi\src\manualstorage.cpp (215): ManualStorage::handleMinedEntity

   Code: Select all

     14.431 Error CrashHandler.cpp:468: Access Violation: Read at address 0000000000000018

3. Remove furnace "G" or "H" -> crash (FluidBox::PipeConnection::disconnect)
   log

   Code: Select all

   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidbox.cpp (438): FluidBox::PipeConnection::disconnect
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidbox.cpp (813): FluidBox::setupUndergroundConnection
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidbox.cpp (1630): FluidBox::updateBlockedUndergroundConnections
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidsystem.cpp (438): FluidSystem::updateBlockedUndergroundConnections
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidsystem.cpp (312): FluidSystem::updateFluidIDAndFilters
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidmanager.cpp (286): FluidManager::moveOut
   c:\cygwin64\tmp\factorio-build-3kglwi\src\fluid\fluidboxmanager.cpp (589): FluidBoxManager::onDestroy
   c:\cygwin64\tmp\factorio-build-3kglwi\src\entity\craftingmachine.cpp (491): CraftingMachine::onDestroy

   Code: Select all

   16.984 Error CrashHandler.cpp:468: Access Violation: Write at address 0000000000000009

4. Teleport furnace "C", "D", "G" or "H" 9 tiles to right. Rejected teleport then fluid mixing
5. Furnaces "A", "B", "E" and "F" when doing 1/pippete, 2/remove, 3/ build from hand, will show "cannot connect systems with different fluids", but furnaces "I", "J", "K" and "L" are not affected - they will be built even if there is blocked underground under them

-- edit:
More weird cases (contains all furnaces and setup from above, there is new contraption near right edge with furnaces from "1" to "6"): Issues:

1. Remove furnace "1", then check consistency -> "this->blockedConnectionCount == blockedConnectionCounter was not true"
2. Removing furnace "2" creates fluid mixing and there is partial blocked underground between two compatible FS-es
3. Removing furnace "3" crashes -> "Write at address 0000000000000009"
4. Rotate furnace "5" or "6" then check consistency -> "Compatible connection is disconnected"

-- edit:
By building 3 regular pipes directly above furnace "1" (or any other up to "6") and then doing furnace rotate twice, there is fluid mixing without alert of fluid mixing

[0.17.67] using 74746-combo-furnace-testing-more.zip:
- pippete+remove+create of furnaces "C", "D", "G", "H" creates fluid mixing
- rotating furnaces "5" or "6" gives "compatible connection is disconnected"
- 3 pipes above furnace "1".."6" (any) and rotate twice gives fluid mixing

no crashes other than consistency when checked

Thank you for all that work and test cases! Work is going slowly now that there is wow classic interfering.
I have fixed the crashes, added the runtime fixing of mixing, now fixed the consistency issue, and all the cases are ok now. So I hope that we can put this episode of our lives behind us (I know we won't.)