EAH does NOT read the blocksmapping, it reads the API and the API reads your configs. The API doesnt use the blocksmapping either The mapping file is pure so the new block range ids are stored, if the file wouldnt be updated on changes then you wouldnt be able to add new things either. Since it would never store an id to new added blocks and the game would not know the block then There is no way for us to verify this, what you did and what changed. Only thing I can say is that the provided info is not enough for us to look into this If its a bug, then we need configs and save games from before it happend and after it happend. Only then there is a posibility we might find something (no guarantee) All I can say is that if you add new blocks ALWAYS add them complete at the bottom, and never between Do NOT delete anything, set it to hidden if you dont want it to show up This are the 2 rules we follow internally and we never had an issue, not in SP or MP
I'm sorry, but I don't understand what you mean. The block IDs on Spanj's server are different than if I start a single player game right now and check those same blocks, because the block mapping file stores the order the blocks were added to the save game. EAH and the dialogue modding API both read the correct block ID values for the save game regardless of what order those blocks are in the configs, except in the case above where EAH was showing a different ID range for a time. I would hope that I'd have the benefit of the doubt that if I say "we do not remove blocks from the blocks config" that would be enough to assume we don't. I've been trying to get server admins to send in the save files, but none have been able or willing so far. It was hard enough to ask Spanj to take 4 hours out of his day to investigate and report this issue, so I don't blame them for not being able to take the extra time to do that too. Yes this might work because then if the block mapping file is ignored at any time, the block ID order would still be the same. However, that's not what the expected behavior of the block mapping file is, so it would still be a bug with the block mapping, just one that won't show up if you always add blocks at the end since you're keeping the order the same. But, again, if this is not how block mapping is supposed to work, why does it work this way in SP all the time, and in MP all the time except when blocks randomly turn into other blocks? It feels like I am not being listened to here and it's frustrating. I keep saying we don't remove blocks and that the issue isn't tied to any scenario updates. It really does seem like the game itself just "forgets" about the block mapping file on occasion, forcing some kind of weird desynced block update to structures that converts specific blocks into other specific blocks based on the scenario configs rather than the block mapping file. Again, I personally would argue that something behaving differently in 0.1% of situations would be a bug, but I also understand it's going to be hard to find a cause without enough data. If the solution to avoid this bug is to add blocks only to the bottom of the configs, then I suppose that is what we will have to do.
I spoke with Vermillion, and as a test, we're not going to add (or remove, or re-order) any blocks in the block config file for a few months and see what happens. If we have a verified report of the issue happening in a fresh save that hasn't yet had any new/removed/reordered blocks in the block config, we'll try to get the server admin to submit the logs and save game.
I understand your frustration, and I want to clarify a few points. First, regarding EAH: as has been explained multiple times, EAH does not modify block IDs or read the block mapping directly. It only reads the IDs from the API, which itself reads the save game and config data. EAH is not responsible for the block ID desync issue you’re seeing. Pointing to EAH as the cause is a misunderstanding of how the system works. Second, in order to investigate this properly, we need a reproducible case. Without save games and configuration files from both before and after the issue occurs, there is no way for us to verify or diagnose what is happening. This is not a matter of doubt or trust—it's simply a technical requirement. We cannot analyze an issue that cannot be reproduced or traced. We fully understand that the issue happens very rarely, which makes collecting the necessary data difficult. But without it, any further speculation on causes—whether game bug, config change, or scenario update—cannot be confirmed. Once a reproducible case is provided, we are happy to look into it thoroughly. For now, the safest approach is to follow the suggested best practice: always add new blocks at the bottom of the configs, which helps prevent potential desyncs.
First off, thank you for re-opening this case and getting the discussion going. I created this as bug report because I believed it was the best format to get all parties involved in this investigation. Perhaps I was mistaken, however if you feel this needs to be moved to a different forum category that is fine with me, as long as we keep trying to get to the bottom of it. Speculations that EAH is somehow responsible for this issue were an ignorant and desperate attempt to force a discussion in the direction of resolving the problem. I have no idea how EAH works or what it does in the background. All I had to go one was screenshots of it showing 2 different block IDs for the same thing over the course of the issue and then it miraculously fixing itself. I think we can confidently conclude this was an error and now we know EAH cannot be the cause. Thank you for that information. One thing we do know is that this problem does not occur on HWS RE2 server. Rex has knowledge and processes that are far beyond mine and other server admins understanding of how the backend of Empyrion works. This enables him to create procedures and processes to ensure all updates for both Empyrion and the scenario are merged into an active save game correctly. Rex and I have been discussing this via discord and we are in the process of comparing notes. I hope to gleam from him what it is that we are, or are not doing, that may lead us to a smoking gun and thus we can focus are collective efforts there. For now there are far to many unknowns and still not enough data to go on. Current timeline of events around the latest incident on Broken Eden: 4th of March - Build 42 of Reforged Eden released - Broken Eden is shutdown and build 42 update is applied to the server - Server is back online and no issues are apparent. (I was also streaming post update with no issues) 6th of March - Standard scheduled server restart and maintenance (EAH subtask, backup, clear templates) - 1 hour later First ticket raised on Broken Eden for Wind turbines transformed into Hydro bay - Over the course of the next few hours and days as people log in over the weekend we have about a dozen or so more tickets with similar transformations. - investigations by admin team show disparity in Block IDs for Wind turbines as screenshots shown in my first post. 7th of March - Investigations continue, block IDs seem to have changed back to what they were before and the Wind Turbine is now showing the original block ID. - No more incidents occur but tickets continue to come in as people log in to find their blocks have transformed while they were offline. We are not sure exactly when the Block IDs returned to their original ID. Not all players were effected, even those with the same blocks on their ships that transformed for others. I will be asking my players to try and capture clips and video of this happening if they witness it again. I will also ask them to send me a blueprint of the ship prior to transformation and post transformation. Is there any additional logging or diagnostics we can enable on the server (assuming it wont fill the drive up in a few hours) that might help? Thank you again everyone for getting this discussion going, hopefully we can get to the bottom of this and whatever the cause and subsequent fix we will be helping the players better enjoy the game!
Hi Spanj, We can leave the report here, think this is the best place for it at this point Any additional information you can provide when it happens again could help finding out what it exaclty is Best is also to make a backup of the scenario, and save game before you apply an RE update so the diffrences could be seen between before and after when this happens again, I know this is time consuming but afraid this might be the only way to really find if its an issue or not There is no extra logging that could be enabled
