Interesting stuff. I'm going to sit down with that document later.
Making a new object is probably the best way to go.
Edit: I read over the patch for the doors in OoE. Your solutions are pretty much what I would have thought to do. Sound logic.
Edit2: I just had a thought. Would it help at all to look at the warp points? They essentially do the same exact thing as portraits, except they transition between sectors similarly to doors. What I want is a door that functions like a portrait, so the inverse of the warp points.
I looked into how portraits, warp points, and magical tickets teleport the player. They all do it the same way, calling one function to set the destination area index/sector index/room index/x pos/y pos, then calling a second to trigger the actual room transition. This second function does all the hard stuff like loading tilesets and updating the map. So it should be pretty easy to just call these two functions to get a transition working, compared to trying to modify the door code to do it.
There's a bit of an issue with making a "fake door" entity though: Entities only have Var A and Var B to work with in the level editor, but we need to be able to specify the area index, sector index, room index, x pos, and y pos for each fake door individually.
So to get around this limitation we can cram those five values into two variables like this:
Var A: AASS
Var B: RRXY
Where AA means area index, SS means sector index, RR means room index, X means the x pos in screens, and Y means the y pos in screens.
This does have one minor limitation compared to real doors, which is that doors let you specify the x/y offset position in pixels, but this only lets you specify it in multiples of the screen size. But the DSVanias only ever need to use multiples of the screen size for door destinations anyway, so no real loss here.
So now this should be codable, but in ASM it'd probably be kinda tedious to write all the conditions and math and stuff. So I decided to try out something I had been looking into recently, which is using devkitPro to compile C code into ARM ASM. Figuring out all the compiler settings and such at first was quite a pain, but after that, it worked out really well.
Here's the finished code for it: https://github.com/LagoLunatic/DSVania_C_HackingThis file
specifically has the logic for the new door object.
To compile this, first use DSVEdit to add a free space overlay to your PoR project so there's room to put the code (Tools -> Add Overlay).
Then in por_interarea_doors/main.asm change PROJECT_DIR to point to where your project folder is.
Install devkitPro and in por_interarea_doors/build.bat make sure DEVKITARM points to the right path where you installed it. Then just run build.bat and it should all compile, link, and assemble correctly.
(Note that you need to reopen the project in DSVEdit for DSVEdit to notice the changes.)
Then just add a new entity to the room, specifically special object 07 ("Unused") and then set the var A/B appropriately. Voila!
Dawn of sorrow doesn't display the monster names on the bottom right screen when you hit them, is it possible to add it ?
I looked into it. There's no easy function here, doing this is really complicated and requires calling a bunch of functions to create an OAM sprite, but I did somehow manage to figure out what functions to call with what arguments, so I got the basic text display working: https://i.imgur.com/5j9O04h.gifv
It's far from complete: It doesn't have the fancy icon behind the text, the text never disappears, and the OAM slot I chose to use for it could be used for something else, I just chose one that looked unused at random. These would also likely be fairly complicated to fix.
The source code for this is also in that repository I linked, inside the dos_enemy_name_popup folder, if anyone wants to look into it. The instructions for compiling it are the same as above.