JAVD/JAMD (Just Another Void/Mining Dimension) Dimensions not accessable after creating a RFTools Dimension

[TheonlyTazz]

Issue description: JAVD/JAMD (Just Another Void/Mining Dimension) Dimensions not accessable after creating a RFTools Dimension

Steps to reproduce:

1. Create a JAMD Mining Dimension and place a waystone
2. Create an RFTools Dimension, with or without a digit dimlet
3. Power the RFTools Dimension
4. Port to it
5. Return to the overworld and save and exit the game
6. Start the game
7. Try to teleport to the JAMD dimension using either the JAMD block or the waystone

Versions:

• Minecraft: 1.18.2
• Forge: Forge 1.18.2-40.1.54
• CompatLayer (only if on Minecraft 1.10 or 1.11):
• McJtyLib: mcjtylib-1.18-6.0.15.jar
• RFTools: rftoolsbase-1.18-3.0.9.jar
• RFTools Dimensions: rftoolsdim-1.18-8.0.7.jar

Possibly incompatible mods: This Issue happened to 2 Players playing Direwolf20 1.18.2 and i have tried everything to fix it. This issue could lie at JAVD/JAMD aswell, but i'm just hoping to find some assistance here.

Issue on the FTB Issue Tracker: https://github.com/FTBTeam/FTB-Modpack-Issues/issues/1075

Relevant logs, if any:

[McJty]

Logs?

[TheonlyTazz]

Log provided by User: 2022-07-10-2.log.gz

[Raidobw2]

Hello McJty, I don't think this is an issue with your mods, I'll explain why.

I ran tests in SP to reproduce this and only ever could reproduce this while the level.dat file was being locked by NBTExplorer in Windows. Then weird dimension stuff started happening.

In my tests this caused the dimension to exist in live RAM for the uptime of a server until a restart. At the restart sequence, the server would come to a stop and flush to disk, which effectively didn't work on level.dat. Although, since other data files including from RFTools weren't locked, then those saved correctly as well. Which I believe lead to that user report.

I've been able to check the user's world thanks to Tazz, and here's the world folder.

I believe that artifact would contain some kind of backup level data, but in this case, it's corrupted:

If we open the original level.dat, we can see the dimension data is missing:

Under normal circumstances you'd have something like this:

I then do think that something must have happened with that server which caused it to fail saving the important level.dat file. Maybe a power cut or maybe a weird file lock by some antivirus, even for a fraction of a second as long as it's in the right time frame.

This isn't shown in the user log (it might have been the wrong one?), but that error about level.dat would have been marked as such in it (truncated here):

[14juill.2022 21:03:02.491] [Render thread/ERROR] [net.minecraft.Util/]: Failed to rename
java.nio.file.FileSystemException: C:\Users\R3GEN\AppData\Local\.ftba\instances\d42eca22-d649-44a1-8bfd-cebcd44ef5a9\saves\New World\level.dat -> C:\Users\R3GEN\AppData\Local\.ftba\instances\d42eca22-d649-44a1-8bfd-cebcd44ef5a9\saves\New World\level.dat_old: The process cannot access the file because it is being used by another process
    at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) ~[?:?]
    at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) ~[?:?]
    at sun.nio.fs.WindowsFileCopy.move(Unknown Source) ~[?:?]
    at sun.nio.fs.WindowsFileSystemProvider.move(Unknown Source) ~[?:?]
    at java.nio.file.Files.move(Unknown Source) ~[?:?]
    at net.minecraft.Util$4.getAsBoolean(Util.java:474) ~[client-1.18.2-20220404.173914-srg.jar%23319!/:?]
    at net.minecraft.Util.m_137548_(Util.java:532) ~[client-1.18.2-20220404.173914-srg.jar%23319!/:?]
    at net.minecraft.Util.m_137449_(Util.java:543) ~[client-1.18.2-20220404.173914-srg.jar%23319!/:?]
    at net.minecraft.Util.m_212229_(Util.java:568) ~[client-1.18.2-20220404.173914-srg.jar%23319!/:?]
    at net.minecraft.Util.m_137505_(Util.java:559) ~[client-1.18.2-20220404.173914-srg.jar%23319!/:?]
    at net.minecraft.Util.m_137462_(Util.java:555) ~[client-1.18.2-20220404.173914-srg.jar%23319!/:?]
    at net.minecraft.world.level.storage.LevelStorageSource$LevelStorageAccess.m_78290_(LevelStorageSource.java:363) ~[client-1.18.2-20220404.173914-srg.jar%23319!/:?]
    at net.minecraft.world.level.storage.LevelStorageSource$LevelStorageAccess.m_78287_(LevelStorageSource.java:347) ~[client-1.18.2-20220404.173914-srg.jar%23319!/:?]
    at net.minecraft.client.Minecraft.doLoadLevel(Minecraft.java:1935) ~[client-1.18.2-20220404.173914-srg.jar%23319!/:?]
    at net.minecraft.client.Minecraft.m_91200_(Minecraft.java:1871) ~[client-1.18.2-20220404.173914-srg.jar%23319!/:?]
    at net.minecraft.client.gui.screens.worldselection.WorldSelectionList$WorldListEntry.m_101744_(WorldSelectionList.java:473) ~[client-1.18.2-20220404.173914-srg.jar%23319!/:?]

I do believe this error is caused by external issues with said server, and doesn't have anything to do with Minecraft. The solution, which I'll forward to the user, would be to restore the level.dat from a backup and to check the event viewer/logs to see if anything happened the day this world became broken.

I believe you could go ahead and close this issue, since as said earlier, I don't think this is a conflict with your software/other modder's software.

[Saereth]

This is also occurring with ftb team dimensions. Completely removing all team dimensions I've seen rftools dim in created and the server restarted.