New EVENT program

[kilroyfx]

Holy, Holy ‎  , Holy ‎  !!

Mmmm thanks for your help Holy, but I don't need to traverse the individual commands or the leafs. ‎  Sorry to be snarky, but your making some assumptions. I'm not worried about writing a program in fact its basically done already. ‎  I think you need to go back and analyze those files again and make a couple games with SOM because there are some interesting relationships between the files and how they made SOM interpret them...you almost have to read in between the lines to get it.

Holy, Holy , Holy !!

Holy, What I want to do, is help people make better games and ease some of the headaches associated with making a map. ‎  So, I just wanted some input before I finish this program. ‎  I don't want to go in and change events or manipulate commands....I just want people to have a little more power to extend their creativeness.

Holy, it seems that SOM relies on a system with no pointers, it uses placement and order as pointers which seems dangerous. ‎  Yes there are 258048 bytes allocated for the Event Headers or whatever you call them, and that allows you 1024 Events at ‎  252 bytes each (but 10 are reserved, of that 10, 3 of them are useful). This order seems to dictate what happens at the end of the file, or after 248048. And that is the rest of the Event Commands seemingly without a header but instead a tail of about 4 bytes. ‎  I don't think the commands on each leaf are split up...They are in exact order, although if you delete an EVENT a harmless gap occurs in the 1024 list of Events, this gap is ignored and the count stays accurate. But I digress, I'm truly not worried about this...I am worried about creating something that nobody will use or appreciate.

I feel bad for smashing you down everytime you speak Holy, -- nah I'm just joking what was I sayin?? ‎  I like smashing you down....:)

Really, you should run my posts through BeNice2.0 ‎  I know you downloaded it and play with it every night :) ‎  You probably concatenated it and tried to figure out how it worked....

[Holy_Diver]

Theatrics aside

You don't know what SOM does internally. Files are files, programs work out of memory. SOM saves your file when you hit the save button, so it's safe to assume it does not do anything like memory mapped file operations.

Most likely SOM uses a very simple database library for it's file procedures.

If you just clear out a record from the evt file, you will be leaving junk in the data portion of the file, which eventually SOM (or the imaginary database library) will barf on. Probably when you start trying to erase and create new events in the editor. Then your file will be corrupt. I have experience in this aspect of SOM. If you copy an event record, things might (because there is no reference provisioning in the file format) feel safe, until you delete one of the records you copied, which will in turn delete that events information in the data portion of the file, which will corrupt all the events you created by copying, and will cause SOM to crash / leave you with a corrupted file. SOM does not copy events itself this way. If you copy an event the entire data portion is replicated in the file, so you need to know how to work with the event data. I'm not sure what you're up to, but you need to at least understand what is and isn't a valid evt file (peoples' projects are important to them after all)

I'm trying to help you out here.


PS: From what I was able to gather, you seem to've misunderstand what I meant before about extracting and concatenating events. My goal in that case was simple. I have many endless global events in my project. I needed to extract the global events into their own evt file, then concatenate that file with the evt files of the other maps. To do that you don't have to know what the events are doing, but you gotta understand how to correctly pull events out and put them back in. You can do a merge by extracting the events you're replacing then putting in the new set you want (I have not decided philosophically whether to add some overwrite options or not)

[HwitVlf]

But I will have to think about that challenge, because that is a real problem. :)

Yes, my suggestion may be more effort than it's worth, especially since it would be almost redundant if the model-animation format gets figured out.

Other than that, just being able to copy a single event from one map to another would be a great help. It can be a huge pain to setup a complex set of 'Always On' events that need to be triggered everywhere in the game.

[kilroyfx]

Yeah, I understand all that..I would not remove a record and leave the junk behind....It would appear to work maybe...The test is this.....make a program with an interface that allows you to really "beat up" a .map and its .evt file....right ?? Then basically try duplicating and deleting Events a lot of times and then run the level.....compare it against the original level...

You will know if you have corrupted the files....I am aware if you duplicate an Event Record (one of 1024) then you must delete the corresponding Event Data (you dont need to really care about exactly what commands are going on in there though) Just as long as you delete the right one....

How about this, I will make an interface that allows you to remove events and their matching data, and also allows you to duplicate events - which means it needs an object or NPC to be assigned to (or the same object,npc,enemy) ‎  and you can test the hell out of it...I guess eventually if your not careful you could delete all the events....but then just add some more...see if you can fragment the file for lack of a better term !!

or however you want to do some real world testing....but I am confident that I can get it to work, and that I understand the ramifications of doing it wrong. ‎ 

Just to be clear, for every Event-Record there is a corresponding Data-Portion....I have removed the Event-Record only and seen that SOM survives the lobotomy...but I know this is wrong. ‎  Every Event-Record must correspond to an Event-Data-Portion.....and even more so has to correspond to the .map file in 1 of 3 sections either object,npc or enemy (you really have to know what you are doing in these files) I'm telling you I looked at these files for a couple hours and I get it....

I mean come on, I have broken down .wav files and decoded them in a day with FFT's and created amplitude driven video on Avid's and XSI's editing suite :) ‎ 

[Holy_Diver]

If you "remove" something just be sure you adjust every offset byte in the file to account for the difference. It doesn't make sense really to operate on the file. It's easier to think in terms of of translating a file into an all new file, or rewriting the file in other words.

If you understand how the file works there should be no need to test it in any rigorous way. Either way, believe me you will know immediately if you messed something up when you try to use the file in any realistic way. SOM is very finicky. If you don't fully understand every single piece of relevant information in your file then you need to do more tests until you do.

Here btw is the encoding for the text message instructions. I don't have any plans to do anything in the dept. you appear to be interested in. I will need the encoding for the other instructions however when I remake SOM. So I hope you document everything and share with the community along your way.

16bit opcode
16bit offset (including opcode/offset bytes)
....? ?? info

^That is presumably the pattern for every instruction. The offset is a pure number. I'm assuming the opcode itself includes all 16bits and is always the same per each type of operation/instruction.

0000=message (1 string)
0001=message2 (r/g/b/0/size/size/0/0/string/font)
008D=IF(choice) = (3 strings)
008F=ENDIF

^Above are the opcodes for these 4 instructions, and the byte layout (I did not concern myself with ENDIF)

size/size is a 16bit number 0~900 for the size of the font (whatever that means) and 'font' is a string... 0 might not always be zero.

These are just my notes. There's probably a clearer way to write this up.


PS: I haven't really looked into the records. Off the top of my head there is a 30 byte name. 60 bytes in there is the first of 16 32bit stage offsets. Then every 96bits there is another (in other words there are 64bits sandwiched between each offset)

[Holy_Diver]

Other than that, just being able to copy a single event from one map to another would be a great help. It can be a huge pain to setup a complex set of 'Always On' events that need to be triggered everywhere in the game.

Like I've said I've already done this. I will release that utility with 3 other text dumpers soon. These will be high quality command line utilities. The evtcat program I've not released yet because no one seemed to need it immediately and because it could use a bit more fleshing out. Still if you need to copy over a bunch of global events, save yourself the trouble and send me a PM and I will help you do what you need to.

The evtpot program I'm working on right now is surprisingly identical, so all of the improvements it's seen will be apparent in evtcat.


PS: I will eventually get around to a graphical tool for these utilities. Probably called Sword of Moonlight Ex. But I will develop that first for a simple wrapper for the games including a console for SomEx extension output. This is the most PC way I can think of patching over the exe at runtime. I will eventually get around to extending SomEx to wrap around the "tools" which will be the logical place to provide a graphical interface to these dev tools. Anyone is free and probably wise to take advantage of them however. I don't mind coughing up the sources if you want to learn from them or copy code into something you're doing. But I'd rather develop the tools themselves in conference. I'd like to help out with some particular things in the editor dept. like extending the map piece per project allotment, however in general I'm more focused on the game side of things, and I think the Excellector standalone graphical interface to the ini driven game extension framework I'm focused on will be my first priority for a long time before think much about the tools themselves. I wouldn't mind internationalizing the tools asap if there is interest. I suspect anything I will do with the tools will be more of an afterthought. By that time I will probably be remaking the tools anyway.

[kilroyfx]

Well if you can successfully extract an EVENT and add it all the maps then thats a powerful tool. ‎  That means you can scan through an EVT file, search for an EVENT then remove it and remove all of its junk....which is a delicate task. Then you insert this into other EVT file, my question is what object do you assign this to? ‎  You cant just leave it assigned to the current object# because that has risks. ‎ 

Anyway, yes I plan to do a similar operation, but thats not my main focus....it is incidental for what I am already doing. ‎  I am really interested int creating better maps, and the EVENT handling gets in the way (I have an interface that surfs on top of SOM_MAP and it is a hack) a didnt want to create a whole new interface) but I just want to show people what they are missing. ‎  And, in my program when you mass delete objects or duplicate whole rooms...A. You cant delete the events, therefore ROOT objects are not deleted B. You cant duplicate EVENTS so duplication of whole rooms dont carry any EVENTS .....

Anyway, I figured it would take a day to implement an EVENT program.....But I think it would be great to be able to extract EVENTS and not only place them in maps on a GLOBAL level but share them with other people...I mean I have written HUGE event structures taking up say 1 or 2 EVENTS SLOTS that pull off very neat effects !!

We could share the knowledge and increase the quality of the SOM games that are appearing....

[Holy_Diver]

Well I can't really offer much advice because you haven't communicated what it is you're doing from a design pov. Your approach from what I can gather seems to be something like an AI agent that interacts with SOM on behalf of the user. Whatever you're doing it's much more creative than anything I could've imagined from my own perspective, so I wish you the best of luck / think it's great.

I really can't imagine how something like this would work unless you're regularly saving and reloading the map in order to perform your operations. Otherwise you'd have to have access to SOM's internal state, which I could facilitate, but once inside making head or tails of it to me as I imagine it would not be a wise investment of time.

Personally (call me uncreative) I really don't see so many ways to extend the tools. But there's a lot I don't know about; hacking in general is a new and unusual domain for me.

[Holy_Diver]

On binding events. I have not implemented this feature set yet (one reason I have not released evtcat) however as I recall the event bindings are stored in the evt file. My guess is that is the only place they're expected to be found. As the utility works now, it's wise to bind your global events to object 0. So when you shuffle them around from map to map it won't matter. If you add events to a map with a obj/npc/enemy binding that is unavailable, the map editor and probably the game as well will crash.

Therefore when using the tool the user must be cognisant of what bindings are going where. There should be options to tell the tool either what bindings to keep or what bindings to default. However the basic method would be to manually instruct the tool to remap the bindings on a per binding basis. If you're a user you can make these provisions on your own. Or if you're a tool of some sort, you can manage these options on behalf of your user. Also filtering the input thru a single or set of bindings would make sense.

[kilroyfx]

Well, thats precisely what I am doing and at first I didnt think it would be fast enough...but saving and loading map63 seems to be fast enough to be useful...its the only way to do this inside SOM_MAP. ‎  I dont want to write a new editor, people are resistant to new things, and I wouldnt want to do all that work and be responsible for the tech support. My approach is simple, load up 63.map and 63.evt into RAM, manipulate both, SAVE them and ‎  make SOM_MAP load them ‎  in...

Seems to work fine....except sometimes SOM_MAP complains......but nothing is ever lost and you can pull off some neat tricks....


The real fun is when you play your map and see all these sweeping changes....like offsetting all your tiles by 128 or multiple of 128. The whole level looks great, and you have changed all the models/textures of the walls,ceiling,floor ‎  A castle becomes a straw-hovel....a wooden house interior becomes ornate...etc...Also rotating and duplicating creates a confusing maze of rooms and hallways which is great for a tunnel-runner/arcade version of SOM....