Closed CHanzyLazer closed 2 years ago
Am i seeing this correctly that you do not care about the insane amount of Lag that checking the Structure every possible tick is causing? Because that is what you are doing, checking it every single motherfucking Tick.
I also noticed you tested that in Creative, would you please test if the Bug exists in Survival? Because I am pretty sure the "Creative Punch" doesn't send some of the Events that breaking it with a Pickaxe or so does.
Edit: I am gonna check if the Crucible has a backup check every X ticks in case an Event didnt fire too, so there might be a bug in that specific case.
Am i seeing this correctly that you do not care about the insane amount of Lag that checking the Structure every possible tick is causing? Because that is what you are doing, checking it every single motherfucking Tick.
I also noticed you tested that in Creative, would you please test if the Bug exists in Survival? Because I am pretty sure the "Creative Punch" doesn't send some of the Events that breaking it with a Pickaxe or so does.
Edit: I am gonna check if the Crucible has a backup check every X ticks in case an Event didnt fire too, so there might be a bug in that specific case.
OK, of course, I didn't check the Structure every possible tick , which can also be seen in the Files changed.
According to my research, this bug can only be triggered when the player is "standing" on the crucible. Therefore, I think that when the player destroys one of the wall, of course, it executes the breakBlock()
function and sets mStructureChanged
to T
, but this wall has not been removed at this time. Since the player has been "standing" on the crucible, the onwalkover
function will be called to apply Temperature Damage before the wall is removed, and the getTarget(T)
in this function will call checkStructure(F)
.
At this time, the structure is still okay (because the wall has not been removed in time), so checkStructure(F)
will think that the structure is complete and set mStructureChanged
to F
, so the subsequent checks will not be carried out.
Therefore, my solution is to provide a function checkStructureOnly
that only check structure and do not modify the mStructureChanged
. This bug is avoided by replacing the checkStructure
function in the original getTarget(T)
with it.
but this wall has not been removed at this time.
Very sure it has been removed at that time, because the onWalkOver Function is called within the same Thread (at a very different Iteration) and is very much NOT multithreaded. The whole break Block part does not wait a tick to remove the Block, it INSTANTLY removes the Block, and that instant is what sets the Structure Changed to true.
Edit: Also it sets mStructureChanged to false because it literally just scanned if the Structure is correct. Why would it suddenly become invalid after having proven to be valid, and that before the function even returns?
Maybe there are some problems with my analysis, but after my test, it is really caused by the function onWalkOver
:
In the survival mode, as long as I stand on a multiblock structure, there is a large steam turbine, it is still maintain the structure after removing one of a dense wall. This bug will not exist after changing getTarget(T)
to gettarget (F)
in onWalkOver
.
I think I fixed it, it seemed to work so I wont need this Pull Request.
I am still very much puzzled as to why this even happens, because the mere act of trying to check Structure is screwing this over...
Structure okay
Original
Fixed