[Dominik] Game Crash - FluidBoxManager::onDestroy
-
powerbreak
- Manual Inserter
- Posts: 2
- Joined: Sat Jan 19, 2019 8:49 am
- Contact:
[Dominik] Game Crash - FluidBoxManager::onDestroy
Game crashes when i try to make express transport belts in assembling machine 2
- Attachments
-
- _autosave2.zip
- (10.8 MiB) Downloaded 76 times
-
- factorio-current.log
- (11.54 KiB) Downloaded 78 times
Re: Game Crash
[0.17.40]
Looks like related to [Dominik][0.17.39] crash setting up assembling machine mk2 - need info
Can you provide some details about how this assembler happend to be in corrupted state? What order you placed blueprints relative to research? Can you provide blueprint you used to build this mall?
Workaround fix is to remove assembler ghosts and place assemblers again - issue is related to placing assemblers with recipe(with fluids) that is not yet invented, playing in <=0.17.38 - assembler or assembler ghost is in corrupted state and needs to be removed before rebuilding
-- edit:
From other topic:
Code: Select all
c:\cygwin64\tmp\factorio-build-ipxlbj\src\fluid\fluidboxmanager.cpp (464): FluidBoxManager::onDestroy
c:\cygwin64\tmp\factorio-build-ipxlbj\src\fluid\fluidboxmanager.cpp (498): FluidBoxManager::reset
c:\cygwin64\tmp\factorio-build-ipxlbj\src\entity\assemblingmachine.cpp (740): AssemblingMachine::checkFluidMixingWithRecipe
c:\cygwin64\tmp\factorio-build-ipxlbj\src\entity\assemblingmachine.cpp (426): AssemblingMachine::setupForCrafting
c:\cygwin64\tmp\factorio-build-ipxlbj\src\gameactionhandler.cpp (2190): GameActionHandler::setupAssemblingMachine
c:\cygwin64\tmp\factorio-build-ipxlbj\src\gameactionhandler.cpp (323): GameActionHandler::actionPerformed
c:\cygwin64\tmp\factorio-build-ipxlbj\src\input\inputhandler.cpp (61): InputHandler::flushActions
c:\cygwin64\tmp\factorio-build-ipxlbj\src\gameactionhandler.cpp (366): GameActionHandler::update
c:\cygwin64\tmp\factorio-build-ipxlbj\src\mainloop.cpp (1149): MainLoop::gameUpdateStep
c:\cygwin64\tmp\factorio-build-ipxlbj\src\mainloop.cpp (1022): MainLoop::gameUpdateLoop
c:\cygwin64\tmp\factorio-build-ipxlbj\src\util\workerthread.cpp (42): WorkerThread::loopCan you provide some details about how this assembler happend to be in corrupted state? What order you placed blueprints relative to research? Can you provide blueprint you used to build this mall?
Workaround fix is to remove assembler ghosts and place assemblers again - issue is related to placing assemblers with recipe(with fluids) that is not yet invented, playing in <=0.17.38 - assembler or assembler ghost is in corrupted state and needs to be removed before rebuilding
-- edit:
From other topic:
@Dominik: how it is that provided save is from 0.17.39, opened in 0.17.40 still crashes? Maybe this issue is because blueprint was placed in <=0.17.38 where this bug was still reproducible, but migration script fails to fix assemblers? I can save this map so it converts to 0.17.40 but it still crashes: no help from migrations.Dominik wrote: ↑Thu May 16, 2019 2:47 pmMigration fixes the issue, so it needs to be within one version.ReBootYourMind wrote: ↑Thu May 16, 2019 2:39 pmMaybe if the blueprint was placed in 0.17.38 but the crash happened in 0.17.39?
-
powerbreak
- Manual Inserter
- Posts: 2
- Joined: Sat Jan 19, 2019 8:49 am
- Contact:
Re: Game Crash
Ye i read that post it didn't crash once i removed ghost assembler and then placed it it worked. I dont remember in which patch i placed that blueprint it was quite big and i couldn't make blue belts for a while so i dont remember when i placed bp. So i placed bp before research patch or more ago and then placed assembler after i reserached logistics 3. But theres another problem i was playing 17.39 when 1st crash happen and then it updated to 17.40 after 1st crash. But even after update it kept crashing if i placed assembler directly on ghost.
Re: [Dominik] Game Crash - FluidBoxManager::onDestroy
Yup, managed to reproduce it:
1/ Using [0.17.38] create sandbox map (in my setup, standalone 0.17.38 for win10)
2/ place above blueprint
3/ save map
This gives following save file:
4/ Using [0.17.41] open above save file (in my setup, steam version 0.17.41 for win10)
5/ enter editor mode to place assembler for blue belts
6/ select blue belt recipe
This gives following crash:
1/ Using [0.17.38] create sandbox map (in my setup, standalone 0.17.38 for win10)
2/ place above blueprint
3/ save map
This gives following save file:
4/ Using [0.17.41] open above save file (in my setup, steam version 0.17.41 for win10)
5/ enter editor mode to place assembler for blue belts
6/ select blue belt recipe
This gives following crash:
Code: Select all
c:\cygwin64\tmp\factorio-build-ftwfl1\src\fluid\fluidboxmanager.cpp (464): FluidBoxManager::onDestroy
c:\cygwin64\tmp\factorio-build-ftwfl1\src\fluid\fluidboxmanager.cpp (498): FluidBoxManager::reset
c:\cygwin64\tmp\factorio-build-ftwfl1\src\entity\assemblingmachine.cpp (740): AssemblingMachine::checkFluidMixingWithRecipe
c:\cygwin64\tmp\factorio-build-ftwfl1\src\entity\assemblingmachine.cpp (426): AssemblingMachine::setupForCrafting
c:\cygwin64\tmp\factorio-build-ftwfl1\src\gameactionhandler.cpp (2190): GameActionHandler::setupAssemblingMachine
c:\cygwin64\tmp\factorio-build-ftwfl1\src\gameactionhandler.cpp (323): GameActionHandler::actionPerformed
c:\cygwin64\tmp\factorio-build-ftwfl1\src\input\inputhandler.cpp (61): InputHandler::flushActions
c:\cygwin64\tmp\factorio-build-ftwfl1\src\gameactionhandler.cpp (366): GameActionHandler::update
c:\cygwin64\tmp\factorio-build-ftwfl1\src\mainloop.cpp (1149): MainLoop::gameUpdateStep
c:\cygwin64\tmp\factorio-build-ftwfl1\src\mainloop.cpp (1022): MainLoop::gameUpdateLoop
c:\cygwin64\tmp\factorio-build-ftwfl1\src\util\workerthread.cpp (42): WorkerThread::loopCode: Select all
1539.143 Error FluidBoxManager.cpp:464: this->doneSetup was not true- Attachments
-
- factorio-previous.log
- (30.76 KiB) Downloaded 75 times
-
- factorio-dump-previous.dmp
- (731.57 KiB) Downloaded 70 times
Re: Game Crash
Ok, then that is the first time. Every time I loaded a save with the crash in our current version, which is one higher, it worked fine.boskid wrote: ↑Thu May 16, 2019 7:08 pm@Dominik: how it is that provided save is from 0.17.39, opened in 0.17.40 still crashes? Maybe this issue is because blueprint was placed in <=0.17.38 where this bug was still reproducible, but migration script fails to fix assemblers? I can save this map so it converts to 0.17.40 but it still crashes: no help from migrations.
Edit: now I see why. All the saves before had the assembler already built. While this one still has the ghost.
So it seems that the issue indeed can't be created anymore, but can carry over in the ghost. Which is rather good news.
Re: [Dominik] Game Crash - FluidBoxManager::onDestroy
Sounds reasonable.
So in 70999 and 70848, bug exists because:
1/ in <=0.17.38 blueprint was placed but assembler was left in ghost state
2/ migration to 0.17.39 happend that did not fix assembler as it is still ghost
3/ player placed assembler (without it there would be no crash)
4/ crash happens and is invulnerable to further migrations as no more fixing is provided
Map from this bug report is before stage 3 so it solved question how assemblers in above two bug reports happend to be corrupted even with migration fixes
Solution would be to fix assemblers and assembler ghosts when migrating to 0.17.42, am i right?
So in 70999 and 70848, bug exists because:
1/ in <=0.17.38 blueprint was placed but assembler was left in ghost state
2/ migration to 0.17.39 happend that did not fix assembler as it is still ghost
3/ player placed assembler (without it there would be no crash)
4/ crash happens and is invulnerable to further migrations as no more fixing is provided
Map from this bug report is before stage 3 so it solved question how assemblers in above two bug reports happend to be corrupted even with migration fixes
Solution would be to fix assemblers and assembler ghosts when migrating to 0.17.42, am i right?
Re: [Dominik] Game Crash - FluidBoxManager::onDestroy
Yes, almost exactly like this. One detail is that the bugged ghost can only be created in .38 (not before) because that is when I made the bug by making ghosts show correct fluid connections. In .39 I fixed it.boskid wrote: ↑Mon May 20, 2019 10:49 amSounds reasonable.
So in 70999 and 70848, bug exists because:
1/ in <=0.17.38 blueprint was placed but assembler was left in ghost state
2/ migration to 0.17.39 happend that did not fix assembler as it is still ghost
3/ player placed assembler (without it there would be no crash)
4/ crash happens and is invulnerable to further migrations as no more fixing is provided
Map from this bug report is before stage 3 so it solved question how assemblers in above two bug reports happend to be corrupted even with migration fixes
Solution would be to fix assemblers and assembler ghosts when migrating to 0.17.42, am i right?
The real assembler does not carry the bug over, only the ghost. So yes, I have now added a fix for the ghost. Hopefully that will be the end of it.
Thanks a lot for the help of all of you to figure it out!