Disk will fill up with saved worlds

[timhutton]

Minecraft saves every world. After many missions the hard drive will becomes full. Especially if making a new world for every mission.

Suggestion: have a flag in the XML saying whether to save the world, defaulting to false.

[TGlas]

Dear Tim,
Good point - I just tried to delete these temporary worlds manually.
I am using the

<DefaultWorldGenerator/>

tag in my mission file, however, I cannot find the generated worlds in the usual location (I believe that this should be "~/Library/Application Support/minecraft/saves/" on my Mac). Does this mean that the worlds are not saved, or do you have any idea where to look?
A related point: how are the worlds named, so I can search my hard disk?
Tobias

[timhutton]

@TGlas If you launch with launchClient then the saves are in run/saves in the same folder.

(If you launch through the standard Minecraft launcher using the jar in the Mod folder then the saves are in the location you describe.)

[DaveyBiggers]

Thoughts:

• We need to make sure we don't delete anything the user might want to keep - eg if a user has manually created a world to use for experiments.
• We don't want to delete the files under Minecraft's feet, while the world is still loaded.
• We could keep a list of files and delete them later, but we also want to be robust to the possibility of the Mod crashing before deletion occurs.
• We could persist that list and carry out the deletion on startup, but this won't protect us from filling the disk during a long continuous run of experiments.

Proposal:

• The IWorldGenerator.createWorld methods currently choose a filename based on the current date/time (to prevent accidental reuse of a file)
  This code can be tweaked so that the filename begins with something like "TEMP_" - something that clearly and unambiguously signifies - to both humans and Malmo - that the file is temporary.
• A new flag can be added (to the XML? or to startMission? or to MissionRecording?) - to preserve the file. This will default to false. If true, the filename won't start with "TEMP_", obviously.
• On client startup, all TEMP_ folders can be nuked.
• We also need to nuke things as we go along. One way would be to refactor the createWorld methods, extracting the common code (generating the filename, launching the server?) into a static method in MapFileHelper.java, which can then, once the server has finished loading the new file, call the same nuke code that gets called on startup (but passing in the newly created filename, to avoid nuking that one). (Though FileWorldGeneratorImplementation.createWorld doesn't quite fit with this scheme - MapFileHelper.copyMapFiles should use the same filename generation scheme that the other WorldGenerators use.)

@bengioe - I'd welcome any counter-proposals.

[bengioe]

@DaveyBiggers Yes, that seems good, it won't require much tweaking of what I implemented.

As for the XML flag, I think that each WorldGenerator should have a flag, similar to forceReset. In my current implementation I called it 'destroyAfterMission', and it defaults to false.

[bengioe]

@DaveyBiggers What do you think of bengioe@196af5c ?

• I didn't change FileWorldGenerator, I'm not sure I understand what is going on but it seems to me that by default the copied world is being overwritten even if forceReset is false. So there won't be this filling up issue.
• If more than one instance of Malmo is running using the same saves folder, inevitably one will destroy the (temp) save files of the other. I'm not well versed in the Minecraft code but I assume this has some negative effects, although on short lived episodes this did not seem to be a problem for me. (Minecraft has a "locking" mechanism, but it is poorly executed, so there is no way to tell if a save folder is being used or not).

[DaveyBiggers]

Fixed by #304.