2009-10-25, 07:19 PM
I had an idea that should make the 9999 pieces thing work a couple days ago, but just haven't thought to post anything. I don't really have time to explain right now, but basically it involves making temporary build directories for each map, and writing a "fake" mapbuilding exe (forget the name) that looks thru the saved map and picks out the pieces it needs, copies them into the temporary directory (can be optimized like building a program) with new names up to 1024, then tells the "real" map building exe to work out of that directory to build the map. No reason I can think of it would not work. We could maybe work out an indexing system so we could rename the map piece files to something more friendly also. Could probably use the same style I've suggested for the model files etc., with the number tacked onto the end or front of the pretty name.
I have a feeling many of the SOM files are actually handled by a very simple generic database library. It would probably be productive to either try to work out what the library is/was if possible (it's probably not dynamic if not inhouse) or rewrite it (its logic is not very complicated) for reuse.
Finally, I have programmed a lot of stuff like you'd need to chop up your game world... space partitioning/triangle splitting algorithms, if not exactly what you'd want. It probably wouldn't be tough to track down / retrofit that code if you can't find an industrial solution that does all you need. I really don't want to encourage people making traditional games that way, but it is a potential way to make SOM backwards compatible with future remakes that might include a multi-layer system. But the most likely reason I would actually sit down to program it would be to help people chop up big models they have into map pieces, not for building an entire level that way, but for gateway/transitioning pieces between labyrinth regions in their games.
PS: Has anyone tried tacking on extra lettering to the map piece filenames after those 4 digits just to see if SOM would still accept it as one of it's own?
I have a feeling many of the SOM files are actually handled by a very simple generic database library. It would probably be productive to either try to work out what the library is/was if possible (it's probably not dynamic if not inhouse) or rewrite it (its logic is not very complicated) for reuse.
Finally, I have programmed a lot of stuff like you'd need to chop up your game world... space partitioning/triangle splitting algorithms, if not exactly what you'd want. It probably wouldn't be tough to track down / retrofit that code if you can't find an industrial solution that does all you need. I really don't want to encourage people making traditional games that way, but it is a potential way to make SOM backwards compatible with future remakes that might include a multi-layer system. But the most likely reason I would actually sit down to program it would be to help people chop up big models they have into map pieces, not for building an entire level that way, but for gateway/transitioning pieces between labyrinth regions in their games.
PS: Has anyone tried tacking on extra lettering to the map piece filenames after those 4 digits just to see if SOM would still accept it as one of it's own?