2009-09-06, 11:16 PM
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)
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)