Slime Salad

The title might be a bit alarmist, because it isn't strictly speaking a "crash" but the results are the same. I accidentally stumbled onto it today (Didn't lose any work, fortunately! Maybe it's impossible to lose work this way, I dont' know!). At any rate, here's how it goes down:

Step 1: Open an instance of Custom, but don't do anything

Step 2: "Accidentally" open a second instance of Custom. Load a game

Step 3: Go to one of the sprite editors. In my case, I went to the Hero Editor. Choose a picture to edit.

Step 4: "Notice" that you have a second instance of Custom open. Close that instance.

Step 5: Back in the window where you're editing a hero sprite, hit the "[" key to change your palette. Crash get!

If I were to guess at the cause, I would say opening an instance of Custom creates some kind of placeholders for various things (Whatever happened to OHRRPGCE.pal, etc? Probably that stuff) and that custom is courteous and gets rid of that stuff when you close. However, if you have a game open and are editing it, the other custom erroneously gets rid of those placeholders leaving your editing custom confused.

An easy(?) solution would probably be to prohibit Custom from having two instances running in the first place. You already are forbidden to edit 2 RPGs at the same time by the "Custom has found an RPG already unlumped!" thing so I don't think there'd be any lost functionality.

So far my game still runs fine and I don't seem to have lost any data so whatever failsafes and safety measures you guys have in place for things like this seem top notch, though I've been saving religiously just in case. I only bring it up because it's a semi-easy thing to accidentally do, and now that I think about it it might even be something I've done before.

Versions I've tested in are November 11th-ish 2012, February 13th 2015 and January 20-ish 2015. Behavior is identical.

Opps! That happens because Custom detects whether an instance is already running by checking whether the working.tmp directory already exists. But if there are less than 5 files in it, it just assumes those are some files the OS refused to delete when it was cleaning up last time (happens a lot on Windows with music files).

Turns out you can abuse this to open the same game twice at the same time, and it even partially works! But the two instances don't entirely sync up their data, so some edits will be overwritten and lost. It does make me wonder though... making two parallel instances of Custom cooperate correctly might actually be significantly less work than adding multiple windows so that you can look at different things at the same time (which has been requested a number of times).

The error handling isn't that great. Its probable that whatever you were working on most recently won't be saved, and there's a lot of errors that don't need to be fatal, but it's more work to recover from errors gracefully.

I used to open two games at once in Custom sometimes, like when I wanted to export graphics from one and use them in the other or something like that without closing and reloading the first game just to get a few sprites from the other.

When did that stop being possible, anyway? I don't remember ever running into any crashes from it when I used to do it every now and then (but then again, I never really opened up two Custom.exes and quickly closed one of them after not doing much, and I never tried to open double copies of the same game either.)

EDIT: I think I did this using two copies of Custom.exe in different folders, if I remember right--not two of the same exact file. So I guess this changed whenever working.tmp folder and its files stopped being a subfolder of the folder where Custom is located and started going somewhere else?

Yes, since working.tmp was moved (it's in <User>/Application Data/OHRRPGCE/ under Windows) now all copies of custom.exe will try to place temp files in the same directory. There isn't any need for that limitation; the only reasons we do it is so that 1) if Custom crashes then it'll definitely get noticed next time you run it; 2) to prevent you editing the same game twice at once which would lead to one set of changes overwriting the other. But as long as we disallow number 2 we could allow editing different .rpg files at once.

I might just do that now, as I'm in the process of improving crash recovery to fix the bug Giz reported.