Other Map Creator use with SoM

[HwitVlf]

Could you be clear on this line...

However, the editor will crash when you try to 'output' (aka convert the .MAP file to an .MPX file) a map with a PRT # over 1024.

The Map Editor (it has the Piece placement grid etc) is SOM_Map.exe. The program that outputs (converts MAP files to MPX) files is MapComp.exe. MapComp.exe is what crashes if you try to convert a MAP file that references a PRT file numbered over 1024~. The actual editor (SOM_Map.exe) is unaffected.

Basically how I read this is all Map files have a PRT number (either embedded in them, or in the file name??)

The PRT number is simply the name of the .PRT file for any particular map Piece.

In order for all map pieces to be displayed distinctly in the editor they must all have different PRT numbers (true or false?)

Yes. The PRT file's name (which is a 4 digit number) decides where it appears in the editor's 'icon-tile' table. Inside a PRT file is the name of the MSM, MHM and icon files used for the given Piece.

And finally are you saying if you put a map piece with a PRT over 1024 in your map, and push the build button, the editor will crash/not do the build output?

The converter program (MapComp.exe) will crash and won't 'output' the map (aka build the .MAP notation file into the actual .MPX files that the game uses). The editor (SOM_Map.exe) then displays a closable error box but is otherwise unaffected.


I know there is a lot of untranslated Japanese in the exe but it doesn't actually appear in SoM. It's mainly just programmer's notes, labels and such.

[Holy_Diver]

I know there is a lot of untranslated Japanese in the exe but it doesn't actually appear in SoM. It's mainly just programmer's notes, labels and such.

Well I think it is mostly stuff that only shows when the tools are glitching out, but I see Japanese all the time, and sometime my tools convert into Japanese. Maybe you don't see it because your environment locale is not set to default to Japanese which is something you gotta do to play most Japanese games -- because Japanese programmers have apparently never heard of locales!!

If you look into the resources (you can do it graphically with Resedit) you will see all the familiar buttons and backgrounds all in Japanese. Stuff you already translated once, but the same Japanese GUI stuff is repeated 2 to 4 or more times all around the place. It's not programmers' notes. Its the Resource side of the graphical user interface. If you don't know what "resources" are they're Microsoft's way of embedding crap like icons and bmp files, buttons, all kinds of stuff (pretty much all the widget crap you see in a traditional File Edit slider popups etc type Windows app) directly inside the exe file.

Edited: https://en.wikipedia.org/wiki/Resource_%28Windows%29

[dmpdesign]

Lol, I make those in paintbrush, its all i have at work :P

[Holy_Diver]

Offtopic: After you change things it probably wouldn't hurt to change the language for the resources to English instead of Japanese. But actually it would probably be ideal to leave Japanese resources inside and just make copies of everyone with the name changed to English. This is where the problem actually is I think. See the resource locale system is probably completely independent of the programs locale state, which is why I regularly see these Japanese resources. Still I wonder if you don't ever see Japanese, because if Japanese is the only resources in there, you'd think it would default to them anyway.

Anyway, I'm not planning to give the tools any special proper localization attention the way I will be doing for the exe's very soon. Though if we got a bunch of foreigners around the world wanting to use SOM I'd change my tune. I think I'd rather wait until I can replace the SOM launcher with my own parent process. That would keep everything a lot more organized. The same parent process would be the same or similar to the one that I'm planning to have launch the standalone games as well/first.

[HwitVlf]

Lol, I make those in paintbrush, its all i have at work :P

Hah, showing off again! Looks like I need more practice. I could spend an hour and end up with doodles,
and you whip out perfect looking diagrams in your spare time at work :)
My version:


AsusX2; Sorry to be off topic, I'll shut up now

[Holy_Diver]

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?

[Holy_Diver]

PS: You'd still have to make your newly built map work out of som_db.exe and make it thru the standalone game build/output process somehow (meaning hacking that app)

It's probably all easily doable, but worth pointing out the problem extends further than just the mapbuilding applet. Which... might be reason to wait for a more comprehensive approach.

[Holy_Diver]

^Or could it be the map geometry is stored inside the built map file? Seems like an odd design choice, but it occurred to me that might be the case after recalling some odd comments here and there