Several errors, requesting some assistance please.

[dmpdesign]

Custom objects could easily (well thats a relative term I suppose) be created to fill your ceiling gaps, but creating map pieces that allow for multiple floors is quite a challenge unfortunately.

I was going to set out to create a cave set that could be multiple floors but realized that it would just take sooooooo many custom parts to build it that the set would likely just be usable for my game only, so since it wouldnt be realistic to build a worthwhile 2 floor cave set that anyone could implement, I cut it from the current project.

SOM has a really bad limitation to only around 1024 or so map parts, and since so many folks have made games with a majority of the included parts (8-900 out of the 1024 total) implementing a set that would likely require about 100 custom parts just seemed like nonsense.

When I finish my current game I am going to modify my SOM tool to use entirely customized parts, and do away with a majority of the prefab ones. ‎  The new game I make with it will be much smaller than dark destiny, but should look alot better and be much more intricate with the ability to have multiple levels, better drop off points etc.

The other thing to keep in mind with multi-tiered map pieces is SOM's hardcoded insta player death at -10m. ‎  If you build a multi level set that is beyond 10m deep, the player will die immediately when touching it. ‎  So this really limits the space you have to work with.

If you become serious about making a full game I will teach you how to make custom parts to fill in gaps and help customize your map pieces to make your game more unique and help work out some of the map designs that SOM originally cannot do.

[dmpdesign]

Here is an example I have in DD where I used a custom object called cave ceiling (its in the SOM download folder) to patch the ceiling area where I built up a stair case and floor of an underground temple entrance.

[Holy_Diver]

I think eventually it won't be hard to work around the 1024 pieces limitation. I can program something that would let game makers select a custom 1024pc. repository for their project and so at least all of your 1024 pieces will be pieces that appear in your game. Well that is technically possible, but it would probably be saner to do things on a set by set basis, so it would be safe to say every set is used in your game though some pieces in the set might not be.

It probably wouldn't be difficult to let game designers hand tweak their sets in extreme cases, though they could probably do that without an automated tool anyway.

As for the -10 thing... don't let that scare you. It's not as bad as it sounds. Before I stopped really level editing my project (based on Tom's DoM) I got suckered into going over the Flame Lair a good bit. One of my obsessions included reworking his area where you jump off a cliff into a quarry like area (well it's a quarry like area now) ....anyway the cliff is much higher than 10 meters... maybe 20 meters, and could probably be as high as I wanted to be without it killing anything. But yeah, you do maybe need a sort of slope to make high things work, or a pyramid like tiering effect... but each tier need only be one piece wide and can be many meters high (not sure the technical requirement... probably approaching 20 meters??)?

There is a general problem with patching however, because objects and map pieces are lit by different algorithms/hardware the lighting tends to be pretty unnatural (if you're patching with something that looks like the area needing patching)

I think when I remake the entire som apparatus I will include a feature for generating pseudo pieces by combining map pieces. The only thing to be wary of however, being that every pseudo piece would count towards your 1024 pieces in the final output (that is if you want to be backwards compatible with the original som runtimes)

Finally this limitation can also be overcome I think by breaking your game up into multiple projects. I think it should be possible to hexedit the exe files so that many games can share the same save data, so that you can effectively link the games into one longer game. You could program events that would keep players from changing games when they're not supposed to (like swapping discs in a multi-disc game basically)

[ArbalestX]

Loving the ideas here~ ‎  I'm not too serious *yet*, the game maker itself actually has some nice ideas, but it could definitely be expanded further. I'll probably post my tester project soon enough so you can see what bad ideas and good ideas I have implemented (constantly warping NPC being a very bad idea; since the NPC warps back to the original spot if you move away far enough.)

I didn't know about the piece limitation that was inside the SOM program. ‎  That would complicate things quite a bit.

I wasn't too worried about the -10m issue, since I know several ways around that.

The idea I had for the cave (2 floor) didn't involve alot of pieces, but I would have to make 3 more palette swaps for the other cave textures. ‎  so space would fill up real quick.

Question Time:

Modifying the Tool? ‎  How does that work?

The custom ceiling is nice, but how were you able to do that? ‎  Did you add it to the stair pieces or was there some sort of way around that? ‎ 

Oh, and the SOM download folder, do you mean the installer at the official website?

[Holy_Diver]

What exactly do you mean by "Modifying the Tool"?

I could guess, but then I might end up posting a lot of crap that was not necessary


PS: I will leave your other questions to others, because I know they can answer them

[ArbalestX]

When I finish my current game I am going to modify my SOM tool to use entirely customized parts, and do away with a majority of the prefab ones. ‎  The new game I make with it will be much smaller than dark destiny, but should look alot better and be much more intricate with the ability to have multiple levels, better drop off points etc.

Then there's also your posts on actually altering the program so it can perform extra functions (or altering previous ones) like your event add-on. ‎  Plus, you also mentioned the repository idea (which seems like a really good idea, if you can't change the 1024-piece limit placed in the game maker.)

[dmpdesign]

the tweaking of SOM itself is holydiver's department. ‎  he may be able to someday do away with the limitations on part depth and part limits.

[Holy_Diver]

Well Todd misspoke I think when saying "modify his tool" ...what he meant is he just intended to customize his data repository. Which is just a matter of editing/making new data files. From' released various tools that can do this to some extent. But their application can be fairly limited. So a lot of the time you have to edit the files directly (hexeditor)

What Todd meant about "my dept." really just boils down to only me and John have a practical understanding of how software works. I know you're also into software development so you can help with as well. John of course does all the translation stuff, and he contributes in other ways technically. I whenever I can am making an effort to develop as many tools as possible for expanding the possibilities of SoM. Originally I just wanted to remake it (build a product that was like som in every way/works with som files, but isn't based on som) ...but since I started working on a project in order to familiarize myself with it, it's charm has sort of rubbed off on me. So I'm also making efforts to extend the original SoM as well. Including fixing a lot of drawbacks and oversights which SoM really should never have been shipped with. In general John has my back whenever I can use some technically literate muscle I think.

Primarily I'm more focused at this time on rectifying matters which pertain directly to my game project (which I also intend to recruit help for) for the time being.


One way to extend it is to develop little standalone apps which can provide various functions during the editing process. I tend to make these commandline apps that mirror Unix style usage. For example I made a little program I called evtcat which can work with evt files in various ways... the usage based on msgcat (a gettext applet) ....I needed that because my maps all share a large number of extremely complex events, and with evtcat I can copy the events from one map to others easily and automatically via a script. My next such tool will probably let you shift your map/part of your map around (while keeping events in place)

Another strategy I'm using, is I was able to devise a dll that looks like ddraw.dll but really it intercepts directx calls and forwards them to the real dll. This gives me access to SoM's address space (in theory -- my initial attempts to find som's writable data segment did not go as well as I had hoped -- but it is theoretically possible -- just need to track down some experts for advice in some mailinglist) ...which will let us do Game Genie type stuff. But on top of that we can also run threads in the dll which can track the counters and load information into designated counters that there is no way to get otherwise... like what status ailments the player is currently afflicted with, or what equip they are using... which can be utilized in events. And of course it's also possible to modify the display process in a number of ways... like it would not be that hard to replace the craptastic sky system som uses, or add underwater effects that are turned on when the player is at some depth and a counter says they are underwater. We could intercept other dlls this way to add other functionality. There is really a lot that can be done with this simple technique.

Another technique is code injection, that is adding new routines to the som runtimes themselves. You can also of course hexedit the runtimes for simple text data substitution.

Other work that needs to be done is cracking SoM's file formats, so we can make new monster models (not currently possible because animation is not understood well) for example.


Why do all this hacking instead of just remaking som (if you're doing so already) ...because "we" love KF and it's heritage I guess (plus it's a truly nerd fueled endeavor -- and heck there is something zen about working with highly constrained tools.... personally I find it refreshing)