Diadem of Maunstraut

[dmpdesign]

Well the only way to really get everything to work properly running it through SOM is to have a copy of all the SOM files Tom used to create the final game.

The map stuff like you said is expected not to work as the files needed for that are in the original project file and not the output directory that DoM was created with.

Tom recently sent me some copies of a test file to use to try to cause freeze ups, and I can't get those to work because my SOM files are different than his, eventhough he copied his entire DOM directory for me to use.

I suspect when the .exe is written it really is not the same thing as a renamed .som project file....but even if it were, its highly possible the object ID's that were referenced in one project dont match what is in your base files.

For instance, when you create DoM, you may have obj number one on your object table a barrel, and maybe object number 2 was a box. At that point the file is pointing at two places for the information. For this example, lets use the barrel object...when you open the DOM.SOM project (not the .exe but Tom's original files) the actual barrel in the editor is pointing at two different places to get the whole file...part of the file (the model, texture and .prf file) the DOM.SOM file is looking into the C:\programfiles\KF\SOM\Data\Obj directories to grab that information...the other part of the file (the name you called it and its location on the obj editor's list for DOM specifically) is looking at the actual directory that DOM.SOM file data is stored in. The two combined tell DOM.SOM how to act when you run it via SOM.exe

Alternatively, when Tom finishes his game and outputs the .exe file...the file that was originall DOM.SOM now becomes DOM.exe, and a few things happen. Number one, the files originally referenced in C:\ProgramFiles\KF\SOM\Data are now written into the output file and data files somehow, this includes textures, models and .prf files. (There are some custom files this doesnt happen, but lets not confuse the issue at hand with these rare occurences).

Now, this is where my understanding is very limited, but that new DOM.exe file and however it incorporates the models etc that were originally a part of SOM now has a whole new table it writes to that references all the object models and part configurations. There is certainly no guarantee in mind that this matches its original SOM configuration, and even if it does, it most certainly is possible that your install of SOM differs from Tom's.

To avoid this problem with Tom testing DD for me, I have just uploaded my entire installed SOM program folder to an ftp server that he downloads and runs on a seperate machine. That way I know he has the exact same fiile structure I do.

Even if Tom gave you all his files though, I really think that there is a big difference between the .exe output file than there was in the original project.SOM file it was created from.

If you want my advice, and Tom is willing, I would zip up your DOM folder, including your save game and get it somewhere that Tom can download it and see if it operates correctly using his original SOM set of files. Or alternatively see if Tom will copy his entire directory somewhere for you to download and overwrite your files.

Either way, I think the answer will be that the .exe really isnt 100% compatible with being renamed .som and edited with random SOM file configurations. The sad truth is your save file (hopefully you have more than one) is probably jacked up.

Sorry if my post is long and confusing...