Open timhutton opened 8 years ago
DaveyBiggers
commented
8 years ago Option 4: Future-proof the generators. Document the code, wrap up the RNGs somehow, write big comments in the code, add integration tests to make sure any breakages are caught immediately.
This is my preferred solution. The other options just seem like hacks, and negate most of the benefits of having mod-side generators in the first place. It would be very easy to add the integration tests.
jaspercayne
commented
8 years ago Suggestion for actually saving the cuboids? Create an byte array to hold the cuboid's information, only recording blocks that are not air blocks. If each block is storing it's coordinates, block ID, and metadata it would allow for recreating the exact structure that exists when the selection is saved, and with minimal extra data, since it can be assumed that anything that does not have a position recorded in the array would be an air block. Then when instantiating the cuboid again later, you can iterate through the array and add each block in, or removing existing blocks in the world by the lack of information in said array based on the assumption of an air block. By using a byte array, the actual size would be minimal, and by omitting air blocks it gets even smaller. I can post some a c# mock-up of this later if requested.
Problem: even if use a fixed seed, if the code for the generator changes then the mission spec is lost.
Option 1: Mod sends back mission xml with drawblocks instead of generator spec. But this could be very large, so maybe we need a new compressed blocks section, to reduce the size.
Option 2: A new 'SaveMap' button in the Mod GUI would save a specified cuboid to disk. cf. #24 But still would be a large file.
Option 3: The generators run on the platform side, sending a compressed cuboid of block specification to the Mod. Then saving the XML is trivial since already where needed.