Hi MMR and Mnemonic and thanks a lot for the super-quick responses!
Regarding the wme.log file, I didn't mention it before because the problems I'm referring to are really beyond its scope, but I do know it very well by now and I use it myself with the Game.LOG() method. You're correct regarding this file appropriately logging problems such as missing/misspelled files and in such cases it logs everything needed to repair the problem.
In the specific case I'm referring, it logs no such info. The engine crashes even without properly closing the file. The last entry in the file is the "Data initialized in x ms" and the normal closing lines:
Shutting down...
Shutting down scripting engine
********** DEBUG LOG CLOSED ********************************************
are *not* there at all.
I did notice the file wme_crash.txt is created in such cases. The thing is that although I used to crack copy protections when I was younger (and dumber...) and I knew the 80x86 instruction-set and registers very well back then, these days (more than ten years later) a dump of the registers and a stack trace of a module I never saw its source code, right after an access violation crash, really tells me absolutely nothing... I guess this file was intended for you, Mnemonic, for debugging the engine and not for the rest of us debugging the games.
As for the "walk-behinds", I still think there's not much difference in painting them, compared to cutting out parts of the background and placing them into scene as separate objects. Or were you talking about something else?
I was talking about exactly that. All I'm saying is that if something is already there, there is no point in putting it there again. Just like you use region entities for hotspots and not sprite entities (with the same image that is already drawn on the background), I think you should use region entities and not sprite entities for the "walk-behinds" as well. If needed, they might have an additional property or something for stating what they really are. And, of course, they will be affected by the z-order specified in the node view. I'm just against having to maintain the same image twice. Suppose I decide to change the color of something in the background image and I forget I'm also using that part of the background as a sprite entity for the walk-behind mechanism. Here is a bug waiting to happen. I know this rule from the world of writing code: Never hold copies of the same piece of code in more than one place. Always make a function of that piece of code and call it from wherever you need it. That way, if you need to change something in that code, you change it only in one single place.
That said, I'm not implying that my logic is, in any way, better than yours (or anybody else's, for that matter). This is just the way I think the "walk-behind" mechanism should be implemented, but I'd still love this engine even if it stays just the way it is. And except this small issue, the SceneEdit tool is way better than the one used in AGS, in my opinion.