VMWare Warning

[dmpdesign]

I ran into a problem today that has left me pretty damn disgusted with SOM for the time being.

I had the same map open in vmware as i did on my vista desktop, and i unknowingly created a new event in both sessions to this map. ‎  i then output one, and then the other and it corrupted my event file for that map.

now when i add events they are working in that map and some of them grab garbled data from other events that were working.

needless to say i lost my entire event file fora map that had probably 50 long events on it...so atm im going to try to recover it from an older file, but im still pretty disgusted about it.

The thing that worries me is whether i corrupted the map event file or the game database file that you output the events to.

more info on that after some testing, but please beware making the mistake i made...

[dmpdesign]

for anyone that may want to know, it broke the .map file...

i had to restore that one from an old one, all my events still are in the .evt file ok,but all the objects they are attached to are gone.

oh well, it could have been worse...only 4 hours lost instead of more=P

[Holy_Diver]

This is strange behavior from a programming pov. But I think if you had left the SOM instance you wanted to keep open. Deleted all the files for that map. Then saved from the good SOM instance, there is no way you would not have gotten back a valid set of files. Still this is strange behavior. Meaning either A) the editors don't completely rewrite their files when you save, or B) somehow you saved both around the same time and the files became intermixed or incomplete.

Either way this really isn't a VMWare problem. The same thing could happen by any number of ways of running multiple instances of SOM over the same filetree. It's more of a common sense deal

Seriously though, it sucks to lose work

Gotta be careful, use protection

[dmpdesign]

yes youre right, its not vmware's fault at all, i guess the warning should be double instancing SOM.

The thing that was really odd about it was I know how it happened, and what I expected to fix it didnt work.

It would seem logical to me that if you have conflicting data in a specific section of a file, especially one that is segmented in such a way as SOM files are (x number of slots per record then it moves on to the next record) that you should be able to just move further down the list of the record and fix the problem. ‎  i.e. if event # 50 was corrupted somehow i would think the way the file works i should have been able to go to event 51, or 52 and be able to do what i wanted, however when doing so whacky stuff was happening...for instance when i tried to move to event 51, and say make an event that played a sound when you approached a circle, it would end up being an event that i would have to examine and it would show me garbled text. ‎  very weird.

oh well, just be careful guys.

[Holy_Diver]

Well one reason your analogy breaks down, is the event file records are basically just headers. The most interesting piece of data in the headers is an offset further into the file starting after the last event record, which is basically fully dynamic. What is in the event records, is really just one of these offsets for every "leaf" in the event. These offsets are not necessarily allocated in order also... I think they're allocated in the order you first added an instruction to a leaf. All the leafs in an event otherwise seem to stay side by side one another (that is I have yet to see leaf data for different events interleaved)

But all of that is beside the point. I would think SOM would just completely overwrite one file at a time, but I suppose it's possible it does not. In my opinion whenever you have a button or something that says "save" it should be a complete overwrite. But maybe SOM doesn't care about my opinions

Still if it wasn't a complete overwrite I don't think SOM would always take so long to save. The build definitely seems to rebuild the entire shebang. So my guess is still it does do a full save. Which if so would mean maybe your problems arose from SOM not being able to save all the files to be in accordance with one another... but that I think would've required you to have hit the save button at nearly the same time for both instances of SOM... or at least while one SOM was still working on a file. It's also possible SOM decided you didn't make any changes that would warrant saving all the files, so you ended up with one file pertaining to one instance and another pertaining to another.

The evt files don't care about what's in the map. Really the only prob you'll run into is if the object/npc/monster your event is associated with does not exist (it's number that is) ...then SOM might crash when opening the map or something.