Editor crash on loading specific level data (PoR, City of Haze)

[LSDonkeyKong]

I'm having an issue after updating today, but the changes that may have caused this error may have literally been made between updating versions.

I am working with a PoR mod that's had a lot put into it - This happened during changes I made to City of Haze, changes were made to the tileset, layout, and map to the area. There are several graphical and music changes I've worked on, so I am not exactly sure, but I think this happened specifically with a room data overlap. I am pretty sure the rightmost side of a room is intersecting the bottom of another one. Regardless, the editor crash prevents me from addressing this.

tl;dr - Editor crash on any attempt to load level data for the City of Haze. I apologize if this is a rookie error.

crashlog.txt

[LagoLunatic]

I don't see how the most recent update could have caused that.

The specific cause error is as follows: When DSVEdit is reading one of the rooms in area 01 sector 00, it reads through each entity in the entity list, looking for the end marker of the list. However, it hits the end of the file (overlay9_93) before it ever sees this end marker. This causes it to throw an error as it tries to read past the end of the file.

The only two possibilities I can imagine that would make this happen are:

• The project got corrupted in some unknown way, and something overwrote that end marker in overlay9_93
• You truncated overlay9_93 for some reason, cutting off the part that had the end marker in it

If you send your overlay9_93 I can try to tell which of these (if either) happened.

[LSDonkeyKong]

Didn't mean to completely pin it on the update - My bad.

I've found the game will still run from a new file till you get to City of Haze itself. Said build triggers an emulator dialogue regarding the header upon startup, and getting to the City of Haze is a complete hardlock. Overall, this really sounds like something happened like you're describing.

overlay9_93.zip

[LagoLunatic]

Alright, so it's not option B, the file's not truncated.

It appears as though layer 03 in room 01-00-1A overwrote the entity list for that same room. This could have happened if you edited the dsvedit_freespace.txt file yourself manually and made a mistake. Or if DSVEdit has some bug in it.

Alternatively, maybe that room's entity list pointer is supposed to be 02301E28, but somehow became 02301E08. This could have happened if you edited the room's entity list pointer directly on accident. Is that room supposed to have no entities but a single special object 27 ("Dark academy background and rain and sound effects")? If so, this is likely what happened.

[LagoLunatic]

Actually looking closer, it wasn't only 01-00-1A that had its entity list overwritten. 01-00-00 and 01-00-01 also had something similar happen to them. So more likely to be freespace related than accidentally editing the pointers related.

[LagoLunatic]

...But then again, I just remembered DSVEdit has a safeguard in place that avoids overwriting nonzero free spaces even if you mess up the dsvedit_freespace.txt, so maybe it's not freespace related.

You should probably just revert to a backup from before whatever caused the mysterious corruption happened.

[LSDonkeyKong]

I actually haven't touched dsvedit_freespace.txt myself, but I'm getting the feeling that I maybe should have done something related to it - May not be worth explaining completely here, but music sequence files were directly replaced with other tracks much earlier in development. If that's at fault, then it was somehow working completely as intended up until now.

On the other hand, all of those rooms had just underwent an intense makeover, albeit rigorously tested with each little change, including use of the imported bgm. However I do not recall making any changes between the three of them working as intended and this happening.

After thinking through all of this, there may be too much going on to make this worth pinpointing. All I can really think to say at this point is that the rooms you are describing are very likely the ones that had been overhauled via Tiled.

[LagoLunatic]

I've never edited DS music myself, so I'm not sure if that would affect anything. That mostly affects snddat/sound_data.sdat, right? Does it affect any other files, like arm9.bin or overlay9_93? If the answer is "no", then I don't think music editing and dsvedit_freespace.txt are related at all.

The three rooms I'm referring to are the first three rooms of City of Haze. (In vanilla, at least.)

[LSDonkeyKong]

Actually, snddat/sound_data.sdat was the only file I had to do anything to.

Those are the rooms in question. I may have an obvious answer, not sure though - It didn't have any adverse effects at first, as it was the third room where things got screwy, but both the Portrait entity and the warp room entity were removed from their respective rooms, but the map tiles were not changed to reflect that. (Edit- I want to specify that I intentionally removed these) The game was also set to start in the first room in vanilla City of Haze. It was before changing the start room that I last did a manual backup, which has a blank, single-screen sized room in place of that third one.

I guess I'm worried of doing it again, if you know what I mean. If any of those are a dead giveaway, then I guess it's a relief.

[LagoLunatic]

None of the things you just said have any chance of corrupting data like this.

[LSDonkeyKong]

That's unfortunate. I hate to only have ongoing issues, but I do want to note that the corrupted project is still editable and playable as long as you avoid having to load that overlay, with side effects that make this seem more of a lost cause - The common entry in the sprite editor seems to be perpetually informing me that there's no space to contain itself, and the project is displays blatant checksum problems when it is running.

I need to say I have no experience editing dsvedit_freespace or its format/language, just never touched the file. Decided to just open it and, is it of concern that it seems to call on overlay9_93 six different times?

_dsvedit_freespace.txt

Edit - The backup's dsvedit_freespace.txt appears to repeat no numbers at all, and this seems to repeat several? The one attached has several references to arm9.bin and other assorted overlays as well.

[LagoLunatic]

No, everything in there looks normal.

Each line represents a single contiguous chunk of free space. The same file appearing on multiple lines simply means there are multiple chunks of free space. This is completely normal if you have edited that file with DSVEdit in a way that uses free space at all.

[LagoLunatic]

Like I said earlier:

DSVEdit has a safeguard in place that avoids overwriting nonzero free spaces even if you mess up the dsvedit_freespace.txt, so maybe it's not freespace related.

Looking into dsvedit_freespace.txt any more is probably a waste of time.

[LSDonkeyKong]

Gotcha, gotcha. I'll keep an archive of this copy, on the chance I can ever figure out what occurred or it proves useful for something, but it's time I go ahead and redo on a reliable backup, and get as far away as possible from whatever happened here.

All my experience is from programming games but not hacking them, so I'm not sure whether to trust my first thought on everything, but it feels like between Tiled and DSVEdit, something was recorded out-of-order or too many times, as the built version of the corrupted rom seemed to house many more resources that overwhelmed DSVedit when loading things unrelated to overlay 93.

I really appreciate the help, this program has completely revived a project that has been worked on and applied to several different engines for a long time. Unless you want to leave this open as a potential risk towards data, I'd call this closed.