Watcher
Level: Smitemaster

Rank Points: 902
Registered: 02-04-2003
IP: Logged

The situation I'm looking at here is this: place a build marker on a square occupied by a floating platform (over pit). Let a builder complete the marker's request, then move the platform. Several different things can happen, most of them weird.

First of all: the platform does not change shape at all. It appears to have done so in-game, but if you move it, it returns to its original shape. The precise behaviour depends on what you built:

If you build a floor, water, or pit tile, the platform can still be moved across that tile freely, as though the tile were still pit. When you move the platform off this tile, it becomes the type you built, and blocks the platform's movement as usual. (This can be seen with pit tiles by using platforms over water instead.)

Hot tiles work the same way. Oremites disappear, leaving a floor tile that works as above.

Walls, trapdoors, and bridges disappear completely as soon as you move the platform. This is particularly bad with trapdoors: if there are no trapdoors in the room at first, then all red gates switch when the trapdoor is built. However, they do not switch back when the trapdoor disappears, allowing you to "flip" red gates.

Crumbly walls work like walls. However, if you break them before moving the platform, they turn into pit. This elicits the following error:

Assertion error in line 7222 of .\DbRooms.cpp: "bIsPlainFloor(this->coveredOSquares.GetAt(wX, wY))"

Fuses work exactly as you'd expect: you get a fuse suspended above pit, which completely ignores the platform floating beneath it. Bombs also work fine: they rest on the platform, but does not move with it, and they'll fall into the pit if you move the platform out from under them. The editor doesn't allow placing bombs on platforms, but it does allow placing platforms under bombs, and marks this situation as an error. I don't actually see any need for this marking -- the behaviour of this situation is completely predictable and consistent with the interaction of platforms and other elements.

I'd expect that when a builder manipulates a square containing a floating platform, then the platform square is actually removed, changing the shape of the platform and possibly splitting it. Alternatively, you could fix this problem by having builders refuse to work on a square containing a platform, but I think this would be an ugly kludge.

In summary, I'd like these changes:
1) When a builder manipulates a square containing a platform, they remove that platform square, changing the platform's shape and perhaps splitting it into 2, 3, or 4 platforms.
2) The editor should allow placing a bomb on a platform, and should not mark this as an error. The gameplay code already handles this situation, so nothing else would have to be changed.

____________________________
Today the refrigerator, tomorrow the world!

---

[Last edited by Watcher at 04-29-2007 11:00 PM]

Sergenth
Level: Master Delver
Rank Points: 296
Registered: 05-04-2005
IP: Logged

In a builder-related issue, I discovered odd behavior when a builder places a breakable wall over different types of objects.

When a build marker for a breakable wall is placed over a regular wall, pit, water, or hot tile, the builder will go over and place the breakable wall, BUT, when the breakable wall is destroyed, the original regular wall, pit, water, etc is left behind. In the case of the water, the north portion of the water's "shore" graphics goes missing.

Is this a feature or an unforeseen layering thingy?

When a normal breakable wall is destroyed, a regular floor tile is always left behind, matching the floor style that surrounds the majority of adjacent squares to that connected cluster of breakable walls. A builder's breakable wall is not consistent with this behavior.

mrimer
Level: Legendary Smitemaster

Rank Points: 5134
Registered: 02-04-2003
IP: Logged

Watcher wrote:
In summary, I'd like these changes:
1) When a builder manipulates a square containing a platform, they remove that platform square, changing the platform's shape and perhaps splitting it into 2, 3, or 4 platforms.

I've fixed the bug of platform shape not changing when tiles are removed by building. I'm undecided on whether to allow breaking a platform into multiple pieces.

2) The editor should allow placing a bomb on a platform, and should not mark this as an error. The gameplay code already handles this situation, so nothing else would have to be changed.

Thanks for reporting this. Fixed.

I've also fixed the reported problem of built crumbly walls not having some floor type left there when they get broken.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

Tim
Level: Smitemaster

Rank Points: 1979
Registered: 08-07-2004
IP: Logged

Not too sure if I should make a new thread for this, or whether this is already fixed, or that its purely intentional, but I found that builders also have problems with yellow doors.

If the (yellow door) sqaure where the orb connects to the door is removed, the orb will no longer work.

____________________________
The best way to lose customers is to let little kids running loose on a forum with too many mod points.

mrimer
Level: Legendary Smitemaster

Rank Points: 5134
Registered: 02-04-2003
IP: Logged

Tim wrote:
If the (yellow door) sqaure where the orb connects to the door is removed, the orb will no longer work.

I'm undecided on whether to change the current behavior.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

Kevin_P86
Level: Smitemaster

Rank Points: 535
Registered: 06-28-2005
IP: Logged

mrimer wrote:

Tim wrote:
If the (yellow door) sqaure where the orb connects to the door is removed, the orb will no longer work.

I'm undecided on whether to change the current behavior.

IMO, it's a little arbitrary that only removing one specific (might as well be random) door square stops one or more orbs / pressure plates from affecting it.

I think it'd be far more intuitive if the remaining door squares (even if they are split into two or more doors) should still be affected by orbs and pressure plates the same way they were before.

____________________________
+++++[>+++++<-]>[>+++>++++>+++++<<<-]>.>+.>-------.<++++.+++++.

coppro
Level: Smitemaster
Rank Points: 1309
Registered: 11-24-2005
IP: Logged

IMHO, that's too abusable and non-intuitive. I'd say that when a door is broken in two, the engine should ensure that any relations are still kept intact.

eytanz
Level: Smitemaster

Rank Points: 2708
Registered: 02-05-2003
IP: Logged

I agree with Kevin and coppro. I don't think most architects or players pay much heed to which square they select to associate a door with - I think it is normally conceived as a holistic approach. Especially since you can't really associate one or with multiple squares of the same door. I think this needs to be changed so that if a door square is removed, all remaining door squares (whether or not they are still contiguous) should be associated with the same orbs/pressure plates as the entire door was earlier.

____________________________
I got my avatar back! Yay!

Tahnan
Level: Smitemaster

Rank Points: 2460
Registered: 11-14-2005
IP: Logged

Tim wrote:
If the (yellow door) sqaure where the orb connects to the door is removed, the orb will no longer work.

Wow, yeah, I'm with those guys. Incidentally, it's not just removing the square where it connects that'll break it: if reomving a square splits a door, only the door containing the connection-to-orb square will work.

NiroZ
Level: Smitemaster
Rank Points: 1302
Registered: 02-12-2006
IP: Logged

Unfortunately I don't have access to a computer with DROD on it at the moment, but what about pressure plates? Does it behave the same way as the door does in regards to builders?

Watcher
Level: Smitemaster

Rank Points: 902
Registered: 02-04-2003
IP: Logged

I see this thread still has a "to be investigated" icon, so I guess there's nothing wrong with using it for a followup. I've now aquired version 3.0.2 (rev. 1), and everything in this post refers to this version.

Floating platforms now change shape the way you'd expect. However, there's still one weird issue. If you make a 1x3 platform and get a builder to remove its middle tile, you're left with something that looks like two 1x1 platforms. However, they still move in synch, so you've created a non-contiguous platform. While this is certainly amusing, it really doesn't fit with the way platforms normally work. Also, there's no indication that the two platforms can't be moved independently of each other.

Pressure plates work similarly. If a pressure plate is split into two the same way as above, the two parts still work as one plate, and are depressed and released together. There's also an odd bug here: To depress the plate, you have to move some creature onto one of the squares that are still plate. However, to release the plate, you have to clear the entire original area of the plate, including squares that have been changed into something else, such as floor.

For example: make a 3x1 on-off plate. Turn the middle tile into pit, and the eastern one into floor. Now step on the western tile, and have a roach move onto the eastern tile (which is now floor). Move west. The plate is not released as long as the roach remains in place.

Modifying yellow doors still works the way Tim and Tahnan observed: everything depends on which squares the orbs/plates are associated with.

All of this is not quite intuitive. I'd expect the following: Platforms may be split into parts that can move independently. Splitting a plate should turn it into two plates that act identically to the original. When a door is split, orbs/plates that affected the original door should affect both parts of the door the same way.

I tried figuring out how this might be accomplished. First, here's a procedure that determines splits when a tile in a multi-square object is removed. Call the removed tile X.

1. Check the four squares orthogonally adjacent to X to see whether they are part of this object. Make a list of those that are.
2. Take the first tile in the list, and determine which tiles this is now connected to. TCB already has a procedure for this (used for determining platform connections when beginning a room).
3. This collection of tiles forms a single new object. Store this object, and make special note of the tile that was taken from the list (call it the reference tile).
4. Remove the reference tile from the list. Additionally, go through the list and remove any tiles that are part of the object that was just determined.
5. Repeat steps 2-4 until the list is empty. You now have a number of new multi-square objects and a reference tile for each object.

And here's how this procedure can be used for platforms, plates, and yellow doors:

For platforms: Simply execute the procedure. Reference tiles are irrelevant and don't need to be stored. Here, it's important to remember that two platform tiles can be adjacent without being connected (if there are other platforms in the room), so the procedure for determining connectivity needs to be modified to explicitly only consider tiles that were part of the original platform.

For plates: First, run through the tiles of the original plate to see if any tile holds door effect data (DED for short). If one does, copy this data into some temporary storage, then remove it from the room's regular DED. Now perform the split. Then copy the DED in temporary storage onto each reference tile.

The depressed/released setting for each new plate should be the same as for the original plate. If the original plate was depressed, it's possible that several of the new plates will be released during the same turn. Note also that if Beethro is standing on a 1x1 on-off plate that is removed by a builder, the plate simply disappears -- it's not released, and therefore doesn't affect any doors. I think these are both acceptable, but they're worth making note of.

For doors: This one's a bit nastier. First, determine which tiles are part of the original door. Now run through the room's DED. For each orb/plate, determine if it affects any tile in the original door. If so, copy this information into temporary storage and remove it from the orb/plate's DED. You don't need to remember which particular tile is affected -- just what the effect is, and which orb/plate it was taken from. Now perform the split. Afterwards, make a second run through the room's DED. For each orb/plate, compare with your temporary storage to see if it's supposed to affect the door. If it is, modify its DED to have this particular effect on each reference tile.

These procedures for removing plate and door tiles do a lot of meddling with door effect data even when this isn't strictly necessary, but they should work in all cases.

____________________________
Today the refrigerator, tomorrow the world!

schep
Level: Smitemaster

Rank Points: 865
Registered: 03-01-2005
IP: Logged

File: builders_plates.patch (16.3 KB)
Downloaded 54 times.
License: Public Domain

Here is a big source patch which fixes all these issues. To apply it, cd to the main source directory (one above DROD and DRODLib) and do

patch -u -p1 < builders_plates.patch

More specifically:
* When a builder breaks a platform into pieces, the pieces will move independently.
* When a builder removes a yellow door tile, any orb or pressure plate data pointing to the removed tile will be moved to stay on the door if possible.
* When a builder breaks a yellow door into pieces, connections from orbs and pressure plates will be copied (so that the pieces of the yellow door always go up and down together).
* When a builder removes a pressure plate tile, the plate will be updated to no longer check status of that tile.
* When a builder breaks a pressure plate into pieces, the pieces will now operate independently, and each will have the same actions that the original plate did.
* The previous change will also apply to the editor when you break up a pressure plate by right-click or paste. (The editor already dealt with yellow doors as above.)
* Changed the processing when unoccupied pressure plates pop up at the end of the turn so that the order depends only on their placement in the room, not the order the plates were created.
* Fixed bug: pressure plate fails to pop up when flying player is above it.
* Fixed bug: pressure plate is depressed when flying player enters the room above it. (Only affects cases where the role was set in an earlier room. If a script in the room entered changes player's role during turn 0, it's already too late and the plate will pop down, then up.)

The last two aren't directly related, but I happened to notice them, verify them as bugs, and fix them while looking at so much pressure plate code.

The thing about the order in which pressure plates pop up deserves some more comment. It's a rare issue to begin with, but can make a difference even without builders present. The gory details, which can be skipped if you only care that there's no longer hidden information and existing rooms won't break:

I downloaded all the 3.0 holds from Holds and scanned for rooms in them and in TCB where the change might make a difference. The only rooms that qualify were one from my own hold where I was testing this stuff, and Memories : Underneath the Island : 2N. But that one's not on Holds yet; I just happened to have it. It's just that demos there might possibly break; the room does not break. My own victory demo from the room is unaffected (and I didn't use the optional plate).

---

[Last edited by schep at 05-12-2007 05:45 PM]

mrimer
Level: Legendary Smitemaster

Rank Points: 5134
Registered: 02-04-2003
IP: Logged

I've applied this patch and verified that the builder/plate/door updating works properly in a test hold. Excellent work!

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.