Re: The Maunstraut 2009 Project

[Holy_Diver]

I tried literally everything to work around this. It just makes no sense.

The only thing that works is to remove the item or replace it with a different item. I monkey with the glitched item all I want, I can delete it, and remake it in a different item number, and so on. It all causes the crash to reappear. There are some events tied to the item, but I'm fairly certain if I deleted those events or assigned the instructions/conditions that reference the item to completely different items the crash would still occur.

So I just replaced the item with a standin and made it "un-take-able" so I can move on for now, hopefully without seeing this behavior crop up in another form

This is what I get for including a cursed Muramasa sword in the project

[dmpdesign]

Do you happen to have any other item/object with the same model or name as the one thats giving you problems?

[Holy_Diver]

The same model yes (but no problems)

If I remake the item in a different item# same problem. I'm not sure if I tried renaming it, but geez, surely the name is not the prob (if I didn't try changing the name I tried everything else independently -- and probably the name as well)

[dmpdesign]

The one that caused my bug was a duplicate model with the same name.  I had two 'crystal flask' items in my table and im guessing what ever call functions SOM uses in its tables doesnt support duplicate name IDs?

[Holy_Diver]

No, SoM would never use names when it can use the numbered IDs instead. Must've been a coincidence. There really is no reason a name should matter.

[dmpdesign]

No, SoM would never use names when it can use the numbered IDs instead. Must've been a coincidence. There really is no reason a name should matter.

Lots of databases have issues storing duplicate names in certain tables, or running call functions by name and having a deadlock over information thats in there twice.  SOM is pretty craptastically built in many ways, I dont think it would be surprising at all.  It really depends on how it rights to memory and recalls from memory.  Im not saying Im right, but I wouldnt discount anything with the kind of bugs weve found in the program already.

[Holy_Diver]

SoM isn't a database, it's a dinky little game

Now I dunno, as for the tool itself. If you had two objects with the same internal name... that could maybe be a problem. But the name the editor (as in game maker) provides for the game is purely cosmetic (sorry if I misunderstood you)

Besides having items of the same name is totally necessary, if you want to say have an event that replaces an item with an item of the same name, but with extra potential.

[dmpdesign]

I agree its necessary and I have exactly that concept in my game (3 levels of the primary weapon similar to the excellector)

I opened up the Item.PRM and Item.PR2 files to have a look see if I can figure out how the map references them.  I dont see item numbers in there, but there is a file that I need to find that will show exactly what is stored in a save game for map configuration.

Does anyone know which file is created/modified that holds the information about a map that was visited?  In other words, surely SOM creates a section of the save file that remembers counters, items still on the map and whether or not they were picked up.  This is not an SOM config file, but a section of the save file.

I know if I make map changes about what is in a treasure chest or barrel, then load a save game and try to get those items the changes will not show up...so there is something in the save file that remembers whether or not the chest was opened and apparently caches the item that should be in the chest when you do open it.

example:
I create a map with a chest that holds a moonstone...run a game and save it before opening the chest.
I then edit the map and change the moonstone to a moonlight sword in the chest.  I output the information and test the map...while in test mode I load my save game and then open the chest, I will get the moon stone not the sword.

Furthermore, if I make a change to a map that had not yet been visited in the save game, I can change it all I want and the changes will show up when I go to test them in the save game.  So it writes each map as you enter it the first time, and not the whole game when you first start it. (if we could force SOM to load all maps into the save file when you first start a game it might help the warp stage slowness or choppiness some people get changing maps in tom's game).

So my feeling is if we can find where in the save file that information is stored, then we can see how SOM looks for that info, whether its by name or item id number etc.  Then we can at least be sure the naming convention isnt the cause of the problem.

[Holy_Diver]

Well looking up some data by name involves about a 1000x more steps than looking it up by a fixed numeric id. So SoM is not going to be looking anything up by name, though it's possible the tools do by way of a second party system (probably a Windows API routine if anything) for instance when building the initial databases in the parameter editor for example. They are alphabetized in the parameter editor after all. Still I think the odds of a duplicate name slowing that down are probably 0.

As for in SoM files, you won't see any numbers as such. Because the numbers are just offsets into the files which are counted by the fixed size (in bytes) of an item record for example. All SoM files work this way. So the first record is item 1 or 0 (depending on how you count) then say 64 bytes in (assuming 64 bytes is the size of the individual records) you will find the beginning of record 2 or 1 (again depending on how you count)


Anyway, just remember when swapping out equipment for another item (as you probably know) the player will still have the first item equipped even though they no longer have it in their inventory. Same if you take an item they have equipped from their inventory afaik. Some day I will probably find a way to hack around this.