Door issues in v0.55

[Gambit37]

I've had a quick play around with 0.55, found a few bugs with doors:

* Narrow doors now have a square hole in the middle!
* Narrow doors don't respect the new tile reordering -- they are always underneath the doorframe, regardless of order in ESB
* I still can't make these open like normal doors, they just appear/disappear. Is that still by design?

What are the properties for setting door side views and offsets?

[Sophia]

Narrow doors now have a square hole in the middle!

I've never seen this. Are you sure you don't have a decoration with alpha or something like that? Can you post a screenshot?
(DSB might be rendering it wrong, if that's the case. I'd have to look into that)

Narrow doors don't respect the new tile reordering -- they are always underneath the doorframe, regardless of order in ESB

Can you post a screenshot of this, too?

I still can't make these open like normal doors, they just appear/disappear. Is that still by design?

Yes. If you want them to work normally, you'll have to hack them to use the normal door opening/closing code, instead of the custom message handler they use now. If you need help with that, I'll try to post some example code later this weekend. At one point there was a good reason why they didn't work like normal doors, but I forgot what it was.
(Sorry. I guess it either doesn't apply anymore, or we'll soon find out what the problem is/was!)

What are the properties for setting door side views and offsets?

Set a side view with side, just like everything else. You can change the offsets by having different offsets for the side bitmap.

[Gambit37]

Regarding square holes: Yes, I do have a 32x32 powerpink image set as the deco property. This was because I cloned from a door that had the deco set.
It seems like powerpink is now being used as an overlay mask to punch holes through the door, rather than how it worked previously which was just to render transparent (ie, reveal the solid door beneath it)?
I thought overlay masks for punching holes had to use solid red (RGB 255,0,0)???

I'll try and find some time to answer your other points, I don't have much spare time at present (trying to start a new business!)

[Sophia]

You can set deco to false and it won't use any decoration.

Honestly, the system of door decorations is kind of a mess. Power pink is designed to "punch holes," as long as alpha isn't in use-- because it's drawn directly on top of the door, and the door is then drawn. So, that power pink that was just drawn onto the door will become transparent when the door itself is drawn. However, this only works if the door itself uses power pink transparency.

In order to preserve the expected functionality, this version of DSB will do some conversion if you, say, try to draw a power pink transparent piece of decoration on a door that uses alpha, or something like that. The reason it didn't make a hole before was because that conversion code wasn't implemented yet.

Eventually, I hope to eliminate a lot of this mess and use a far simpler system:
A copy of the door is made onto a temporary bitmap.
An optional greyscale mask image is used to "punch holes" in the door.
The decoration is overlaid.
The finished door is drawn.

[Gambit37]

Just a quick update: All doors DO respect the order of items on the tile. I think I just got confused about the correct order, but after double checking and re-arranging where necessary, I got all doors to appear ABOVE the doorframes. You just have to remember that the doorframe must be the TOPMOST item in the list (I was thinking the wrong way around!).

Also, deco=false fixed my punched holes problem

New problem: I can't seem to set an offset for the side view, it's ignored? EG, it doesn't matter the value of x_off (below), nothing changes.

Also, because I'm now putting doors ABOVE door frames, having only a single image for side views doesn't work (The door will be drawn OVER the doorframe). Won't doors need the 3 side views to work properly in this case? (side, side_med, side_far).

Code: Select all

-- Narrow Door 5
gfx.door_narrow_archwindow = dsb_get_bitmap(path .. "door-single5")
gfx.door_narrow_archwindow_side = dsb_get_bitmap(path .. "door-single5a")
gfx.door_narrow_archwindow_side.x_off = 100
obj.snp_door_narrow_archwindow = clone_arch(obj.door_narrow, {
	front=gfx.door_narrow_archwindow,
	side=gfx.door_narrow_archwindow_side,
	deco=false
})

[Sophia]

New problem: I can't seem to set an offset for the side view, it's ignored? EG, it doesn't matter the value of x_off (below), nothing changes.

Oops.
I disabled doors respecting x_off for testing something and I forgot to re-enable it. That will be fixed in 0.56.

Also, because I'm now putting doors ABOVE door frames, having only a single image for side views doesn't work (The door will be drawn OVER the doorframe). Won't doors need the 3 side views to work properly in this case? (side, side_med, side_far).

Sorry, I don't really understand what you're saying. Yes, if the door is above the door frame, it will be drawn over the door frame.. and...?

[Gambit37]

I'll send you a pic

[Lord_BoNes]

Noticed another door issue: I started the test dungeon, found the door that says "2 people need to stand here" (only had 1 person in party, so it didn't open... but that's not the problem) I decided to try bashing the door with the mace from the alcove, and DSB crashed with "Lua function door_wood.msg_handler[100008]: base/msg_handlers.lua:378: attempt to index global 'door_arch' (a nil value)"

[Gambit37]

It's been reported a few times and is already fixed in the next version