Update: Its Not the RAM drive causing the issue. I have now taken the save off the RAM drive and restarted the server. Within 10 minutes of doing so, a player reported their blocks had transformed into hydro bays. The server logs show the same "share violation" and "access denied" errors on the blocksmap.dat file as before. Attached is two epb files, one from before transformation and from after. Attached are the latest server logs from after the save was taken off of the RAM drive. The player reporting the problem is Quilue He was in the Zanpumah sector The transformation happened right after warping to Akua and back again. The effected structures we're not in use but we're parked at his base. I am searching for processes or anything that might be locking the blocksmap.dat file via procmon and resource monitor but so far nothing has come up.
As there is no new info or suggestions etc from anyone I will proceed to the next step. I will now update the scenario to the latest version provided by @ravien_ff , who has included a number of speculative fixes. I will note the transforming blocks all seem to be the same ones. - AUX Cores, large and small - Automated Ice drills - Automated mining drills - Excavator turrets - Windmills All of these blocks turn into Hydro bays. If we have ruled out server hardware/setup as a cause (for now) then perhaps we need to look some more into these specific blocks and their setup? Perhaps the "share violation" error is a 'red herring' and not actually something to be concerned with. A quick google of that error and it seems to be a common unity error with lots of other games. Another avenue is perhaps the playfield server(s) are trying to open the blocksmap.dat file at the same time and that's what is generating the error? Is there anyway to log this? Proc mon and Resource monitor have not shown any file locks on the blocksmap.dat file and we have been running it for over 24hrs while more instances of block transformations are being reported. Any other ideas and guidance on this is welcome please, I am starting to feel a little lonely here right now. Thanks.
The only thing they'd have in common is their position in the block config file is most likely why, as all the Project Eden player placeable ship and base devices are placed in the same area in the config, if there's a block ID shift it would make sense any of those blocks would be affected.
Update: 23/03/26 Since the BIOS update and running the server form a dedicated NVME I have had no blocksmap read errors or any spawn in issues. Server has been regenerating POIs, Deposits and is responding flawlessly. I also partitioned the NVME drive that the server is installed on and loaded up the Vanilla server up to run at the same time, hoping to simulate any potential interruption., I am running identical EAH Timetable tasks across both servers at the same times. My OS installation hasn't performed an update recently so I cannot rule that out yet. Still keeping an eye on the server logs and windows event viewer. I will keep on testing and keep you posted Update: 26/03/26 Ok, I was able to recreate it yet again and came across these perflib 1008 errors in windows event viewer at the time of the affected POI spawn in and also at the time of the Blocksmap error in the playfield logs (UCH Vessel with SV Thrusters sticking out of the top) Maybe worth taking a look? I will continue to keep an eye out. Thinking it must be a Windows background task.
I honestly believe it's not the game itself but something interrupting. the only thing I can think of is somehow get the server/game to make more attempts at loading that file or increase the detection window. Hardware and software has changed a lot over the past 10 years, Windows 11 especially is an absolute nightmare when it comes to performance management. Parking cores, shutting down drives (sometimes bricking them... don't ask,) intrusive virus scans and auto updates too. Actually considering switching to Server and use a process manager like Rexxus uses. But first I will check them disabled one by one with my current setup I am aware that not everyone here uses Windows 11. I am also aware that some servers affected here are hosted so who knows what OS they are using.
Ok, While running an Abandoned Mine I reached the Final boss then regrouped back at my ship and exited the game for the 8am stability reset scheduled with EAH. I have atacthed the playfield logs for just before and after the restart. In these logs we can see a blocksmap read error at 08:02.59 when the server starts again. This POI is not a regenerating POI nor were any EAH timetable tasks taking place at this restart. I logged back into the sever and as I am about to approach the Protoinfector it decided to pop into a blue haze just like the exploding coolant barrels. Sadly, no perflib errors at the time of this error, so we can rule that out.
Update: Adjusted EAH timetable tasks to operate 5mins apart form each other and the restarts have been switched to full shutdowns. This does mean players will have to wait even longer to rejoin. I have also delayed the Vanilla Server's EAH tasks by an hour. Examples: RE2 Server Wipe Schedule Server Stop 23:55 Wipe POIs 00:05 Wipe Deposits 00:10 Check Server not Started 00:15 RE2 Stability Restarts (Might ditch these altogether) Server Stop 07:55 and 15:55 Check Server not Started 08:05 and 16:05 Vanilla Server Wipe Schedule Server Stop 00:55 Wipe POIs 01:05 Wipe Deposits 01:10 Check Server not Started 01:15 No Stability Restarts (Only for testing MP Story capabilities anyway) Hopefully by doing this I can rule out EAH causing any sort of interruption. I have also adjusted my server's power management. Drives no longer turn off to save power.
At this point I have exhausted all options I know of within the scenario to try to prevent this issue from happening. While always adding new blocks to the very end of the config will not technically fix this issue, it will make it so when the block mapping file isn't read it won't actually change any block IDs. More of a bandaid way to avoid the issue's symptoms rather than any kind of actual fix, however. The entire point of dynamic block IDs was so that you could arrange the block config file in a more human readable and organized way rather than having to give each block a specific block ID and position in the block config. If the dynamic block ID system does not actually function properly for dedicated servers, then I'd rather just have the ability to set fixed IDs for all blocks 0-4095 so that the block config file could still be organized. This weird system of a half functioning dynamic block system gives us all the downsides of a fixed block ID system with none of the upsides of a dynamic block ID system because blocks can't even be organized or moved around in the configs. That makes the block config file a disorganized mess since new blocks must be added to the very bottom no matter what type of block they are. In the end it's just frustrating that a game system meant to allow for better block configs doesn't work as it should in MP so you can't actually make use of its benefits. Why use a dynamic block mapping system over a fixed ID system if the dynamic block mapping randomly breaks in save games? Based on how long this issue has been happening and the number and types of servers that are affected, I do not believe there are any solutions to this issue that are feasible for players to implement and any fix would be from the developers. The only thing that can be done is for scenarios and servers to always add new blocks in the config to the very end of the config file so that when this issue happens it won't change the block IDs in a running save game. To be clear, this isn't a fix, it's a workaround, and one we will be following going forward in RE2 at least. I still hope the issue can be actually fixed, but I also understand this is a complex issue that may take more work than it's worth to fix.
I have had one report of the issue happening on a fresh save that had gotten no scenario or game updates, though that was just a single report so it could have been a fluke or they made a mistake. So yeah I would be curious if you're able to somehow trigger the issue in a fresh save though like I said it's unlikely you'd actually know it happens because the block IDs will not shift.
Update: We are completely spent on this issue now. I and my other server admins have been through perf logs, event viewers, permissions, the Windows firewall, everything we can think of and nothing we can find is locking or preventing access to the blocksmap.dat file. The Only log that shows this "access Violation" error is the Empyrion server log. My discussions with @RexXxuS have also seemed to run into a wall. Why HWS doesn't get this issue and we do is still the biggest mystery and question that needs answering in my opinion but at this point it could be a million things. It could all boil down to a single setting in Windows or just the version of Windows they are running or anything like that. For the record, we still have not reverted to the RAM drive setup and are still using a standard (out of the box) setup for the dedicated server. We are still getting blocks transforming into other blocks. And it seems to be more frequent now than ever before. I am once again asking, please, can Eleon take an interest in helping to fix this issue? Thanks
Yeah, unfortunately this issue is a black box for me, since it is not happening for me. Maybe because I'm the only one who go line by line, every patch through all configs and cherry pick/merge exactly what I want / need (e.g. I often do not even add new blocks during a season but keep my config as is until the next season)? With PhpStorm and its diff comparison picker I know which patch adds what exactly - sometimes not even changelogs tell. (here is a screenshot how the merge looks for me for the next season, 170 changes I have to compare and cherry pick one by one: https://imgur.com/4wLE5Hg) My hardware specs etc. are publically in my forum guide. Not sure if the hardware or Windows OS matters. Overall I am always very sceptical of external scripts and mods and what not, so can't / won't help with that. At this point it sounds almost binary. Either it's a hardware/external tool issue or a game / managing issue. If it is a game / managing issue, then I recommend running a season (at least 3 months) completely without touching the BlocksConfig.ecf regarding adding/re-ordering/removing any blocks (which I mostly do by the way - again, you would need to spend many many hours doing the cherry pick / merge yourself after each patch). You can change properties like MarketPrice etc. but keep the rest unchanged. Obviously you start a completely fresh savegame, no weird tools of migrating savegames I saw here and there. If you then still have issues, we can talk about hardware and Co. issues.
I think you and maybe others misunderstanding this "dynamic block system" or even call it a feature. All there is behind it was the technical debt of a limited 2048 ID range that ran out. And the solution was to extend it to 4096 "IDs" but make it easier to maintain by defining unique block names. That's all behind it. It was not meant to re-arrange and re-order and remove/add during a season. With a new season you could do it, because the blocksmap.dat file is created fresh in a savegame. Again, if this issue appears with an absolute fresh savegame, without any weird scripts, mods, hacks, whatever running in the background and especially not with migrating old savegame data, especially structures, then we can talk about a clear hardware / OS issue.
Thank you @RexXxuS For this info. Our next test then will be to run a new save with the existing scenario version. I will use thing like the survival kit to allow players to speed run their level up and get back to their current progression more easily and resume the season. We will then monitor to see if the issue happens with a new save or not.
