Announcement: Be excellent to each other.


Caravel Forum : DROD Boards : Bugs : weird fuse behavior
New Topic New Poll Post Reply
Poster Message
blorx1
Level: Smitemaster
Rank Points: 920
Registered: 07-18-2009
IP: Logged
icon weird fuse behavior (+1)  
We all know that if a fuse is on a yellow door and it closes the fuse dissapears but if a mirror is on the fuse when the door closes the fuse stays I realize that while a mirror is on a fuse it is the eqivalent of gone but to me it seems the fuse should dissapear contrary to what it does

____________________________
If you need to think outside of the box, then you didn't build a good enough box.
09-26-2009 at 10:12 PM
View Profile Send Private Message to User Show all user's posts High Scores This architect's holds Quote Reply
TFMurphy
Level: Smitemaster
Rank Points: 3118
Registered: 06-11-2007
IP: Logged
icon Re: weird fuse behavior (+6)  
Good eye.

This brings up a host of related bugs, which include the following:
* A mirror protects a fuse from igniting after being hit by a bomb.
* A mirror will prevent a scroll from falling if the bridge/platform it's on falls/moves.
* If there are multiple Conquer Tokens in the room and one is covered by a mirror, then you can activate one Conquer Token, then move the mirror and activate the second Conquer Token (causing an assertion). This also works with Power Tokens and Disarm Tokens, but those are really just a cosmetic change (no assertion error).
* I've also noticed that through some quick testing that Mirrors do not drop if the Trapdoor they're on falls "normally". Obviously, this can only happen in very rare circumstances, like if a Trapdoor-dropping Character appears on top of the mirror and then moves off the square. This is all because it uses the DestroyTrapdoor subroutine, which does not check for Mirrors. Naturally, this also saves any Scroll that happens to be under the Mirror too.

Many of these things also occur in DROD RPG due to the same code being used. That said, DROD RPG needs a good look at mirror persistence anyhow, so it can wait until that's cleared up.

Scrolls, Tokens and Fuses should be the only objects affected by this (since, to my knowledge, they're the only items that can be covered by a mirror).

In some cases, the easiest fix is going to be checking for the existence of a Mirror before a particular Switch statement. However, some things need a little more careful coding to get them to perform as expected. As some examples:

CDbRoom::CheckForFallingAt
	//These objects fall into pit/water.
	switch (wTSquare)
	{
		case T_STATION:
		case T_BOMB: case T_ORB:
		case T_SCROLL:
		case T_POTION_K: case T_POTION_I: case T_POTION_D: case T_POTION_C: case T_POTION_SP:
		case T_MIRROR:
			Plot(wX, wY, T_EMPTY);
			if (bIsWater(wOSquare))
				CueEvents.Add(CID_Splash, new CCoord(wX, wY), true);
			else
				CueEvents.Add(CID_ObjectFell, new CMoveCoordEx(wX, wY, NO_ORIENTATION, wTSquare), true);
			// If there's a scroll under the mirror, invisibly make it fall too
			if (wTSquare == T_MIRROR)
			{
				const UINT wCoveredSquare = GetTSquare(wX,wY);
				if (wCoveredSquare == T_SCROLL)
					Plot(wX, wY, T_EMPTY);
			}
		break;


CDbRoom::CloseYellowDoor
		switch (GetTSquare(wSX, wSY))
		{
		case T_FUSE:
			Plot(wSX, wSY, T_EMPTY);
			this->LitFuses.erase(wSX, wSY);
			break;
		case T_MIRROR:
			if (this->coveredTSquares.GetAt(wSX, wSY) == T_FUSE)
				this->coveredTSquares.Remove(wSX, wSY);
			break;
		}


CDbRoom::ChangeTiles
		case SwordDisarm:
		case PowerTarget:
		case ConquerToken:
			//Toggle on-off state of all tokens of this type in the room.
			for (wY=this->wRoomRows; wY--; )
				for (wX=this->wRoomCols; wX--; )
				{
					const UINT wTSquare = GetTSquare(wX,wY);
					if (GetTSquare(wX,wY) == T_TOKEN)
					if (wTSquare == T_TOKEN)
					{
						const BYTE tParam = GetTParam(wX, wY);
						if ((RoomTokenType)calcTokenType(tParam) == tType)
						{
							SetTParam(wX, wY, tParam + TOKEN_ACTIVE);  //toggle on-off
							this->PlotsMade.insert(wX,wY);
						}
					}
					if ((wTSquare == T_MIRROR) && (this->coveredTSquares.GetAt(wX, wY) == T_TOKEN))
					{
						const BYTE tParam = GetTParam(wX, wY);
						if ((RoomTokenType)calcTokenType(tParam) == tType)
						{
							SetTParam(wX, wY, tParam + TOKEN_ACTIVE);  //toggle on-off
						}
					}
				}
		break;


Note that that last change will also require a fix to GetTParam to remove an Assertion error, since it currently doesn't expect us to change the TParam of a token underneath a mirror.

Not sure if the bomb-protection aspect "should" be changed -- it's in the same class of bugs, but you could argue that it might be an interesting mechanic and have an aspect of intuitiveness to it. Or it could just annoy people with yet another mechanic to remember. Easily fixed, anyways.
09-28-2009 at 07:50 PM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
schep
Level: Smitemaster
Avatar
Rank Points: 865
Registered: 03-01-2005
IP: Logged
icon Re: weird fuse behavior (+3)  
I'm looking through things related to this, and a number of questions come up.

These unofficial polls close when I'm done coding and testing related changes. mrimer gets a 51% vote. All other coherent and relevant opinions are given equal vote shares per user (including me), totaling 49%. You may vote for options not listed here. Good reasoning and/or example of precedent in a published hold may get me to change my own vote.

#1. A mirror on top of a fuse is hit by a bomb/fegundo explosion.

(a) The mirror is destroyed, and the fuse lights (just as would happen if the mirror and fuse had been side by side and both within the blast).
(b) Current behavior: The mirror is destroyed, but the fuse does not light.

I vote for (a). It's hard to imagine an explosion obliterating a big glass mirror but failing to ignite something underneath which was designed to be flammable.

#2. Currently, the script command "Build marker" will not place build markers for potions, fuses, or bombs on a square containing a mirror.

(a) Place the build marker there anyway. It's theoretically possible for the building to be completed, but the Builders may have to wait, like they would if a roach is on a tile where they want to build a wall. [Edit: Or, depending on #3 below, the Builder may be capable of building here immediately after all.]
(b) Leave this as is.

I vote for (a).

#3. If a mirror is moved onto a square with a build marker for a potion, fuse, or bomb, and a Builder comes and builds there, the mirror is replaced with the built object.

(a) The Builder should wait for the mirror to move before building there, like they would if a monster were on the tile [edit: and the Builder intended to build a wall].
(b) The Builder should build the potion, fuse, or bomb underneath the mirror.
(c) The Builder should build a fuse underneath the mirror, but should wait before building a potion or bomb, since mirrors should not be on top of those objects.
(d) Leave this as is. Stupid mirrors in the way.
Edit: (e) The Builder should build a fuse underneath the mirror, or should destroy the mirror in the process of building a potion or bomb.

I abstain from voting on this issue for now.
I have now voted for (e).

#4. The Room Editor allows architects to place obstacles, orbs, bombs, mirrors, and Citizen Stations (but not light posts) on top of tunnels. The player can move through the tunnel and come out standing on an object which would usually block the player.

(Thing-under-mirror bugs do not come up here, since it's impossible to push a mirror onto a tunnel, and the editor won't allow placing the mirror over any potion, fuse, scroll, or token.)

(a) The Room Editor should not allow placing these things on tunnels.
(b) The Room Editor should not allow placing obstacles on tunnels. The others are okay, because explosions can remove the others (or a combination of briars plus explosions, in the case of orbs). When one of these objects is on a tunnel, movement to that tunnel should be blocked like it would be if tarstuff is on the tunnel.
(c) Let architects do what they want. When any of these objects is on a tunnel, movement to that tunnel should be blocked.
(d) Leave this as is. Yay standing on weird stuff.

I vote for (b).
Oh, wait. Vote retracted. I think I've seen some holds use obstacle-on-tunnel as a one way passage, right?
Edit: Confirmed (in JtRH, no less). Vote is for (d).

[Last edited by schep at 03-05-2010 12:28 AM : New option in #3]
03-01-2010 at 12:49 AM
View Profile Send Private Message to User Send Email to User Show all user's posts This architect's holds Quote Reply
Chaco
Level: Smitemaster
Rank Points: 3626
Registered: 10-06-2005
IP: Logged
icon Re: weird fuse behavior (+1)  
schep wrote:
I think I've seen some holds use obstacle-on-tunnel as a one way passage, right?

Yeah. Journey to Rooted Hold level 25 uses that property in this room (1S2E) to create a one-way passage.

____________________________
Quick links to my stuff (in case you forgot where it was):
Click here to view the secret text


[Last edited by Chaco at 03-01-2010 02:02 AM]
03-01-2010 at 02:02 AM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
Jatopian
Level: Smitemaster
Rank Points: 1842
Registered: 07-31-2005
IP: Logged
icon Re: weird fuse behavior (0)  
03-01-2010 at 05:17 AM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
Briareos
Level: Smitemaster
Avatar
Rank Points: 3516
Registered: 08-07-2005
IP: Logged
icon Re: weird fuse behavior (0)  
I vote a a a d, too.

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009) :(
03-01-2010 at 11:25 AM
View Profile Send Private Message to User Send Email to User Visit Homepage Show all user's posts Quote Reply
jbluestein
Level: Smitemaster
Avatar
Rank Points: 1670
Registered: 12-23-2005
IP: Logged
icon Re: weird fuse behavior (0)  
a a a d. Most consistent while preserving established canonical behavior.

Josh

____________________________
"Rings and knots of joy and grief, all interlaced and locking." --William Buck
03-01-2010 at 02:36 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
Someone Else
Level: Smitemaster
Avatar
Rank Points: 1304
Registered: 06-14-2005
IP: Logged
icon Re: weird fuse behavior (0)  
I vote a a c d.
03-01-2010 at 11:14 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
schep
Level: Smitemaster
Avatar
Rank Points: 865
Registered: 03-01-2005
IP: Logged
icon Re: weird fuse behavior (+1)  
You know, Builders may be stupid, but they're also powerful. Once they get somewhere ready to act, they can destroy walls, stairs, doors, platforms, pressure plates, tunnels, oremites, hot tiles, bridges, bombs, fuses, potions, briars, and tarstuff. And we all know it's relatively easy to destroy a mirror. So I'm thinking, why not let Builders continue to destroy mirrors?

Also, my statement of 3.(a) implied an untrue fact. Builders will not wait for monsters to move before building scrolls, fuses, or bombs, but will build the thing right underneath the monster. The only time a Builder will wait to build on an adjacent square is if a monster is there and the thing to be built is a wall or crumbly wall. I think the reason for this must be an Imperial order concerning structural integrity (roach carapaces do not make good rebar), not an inability to encase the monster in stone.

Builders are also skilled enough to put things like bombs and potions underneath any type of monster without harming it, or even remove the floor it was standing on. (Drownings and endless plummets are the results of biology and gravity, respectively, and are not directly caused by the Builder.) Since fuses can fit underneath mirrors, I'm guessing Builders can build them underneath a mirror without moving the mirror.

So my vote for #3 is now
(e) The Builder should build a fuse underneath the mirror, or should destroy the mirror in the process of building a potion or bomb.

[Last edited by schep at 03-05-2010 12:20 AM]
03-05-2010 at 12:14 AM
View Profile Send Private Message to User Send Email to User Show all user's posts This architect's holds Quote Reply
Kwakstur
Level: Smiter
Avatar
Rank Points: 385
Registered: 05-05-2006
IP: Logged
icon Re: weird fuse behavior (0)  
a a e d

____________________________
Also known as ExpHP everywhere else.
03-07-2010 at 04:17 AM
View Profile Send Private Message to User Send Email to User Visit Homepage Show all user's posts Quote Reply
coppro
Level: Smitemaster
Rank Points: 1308
Registered: 11-24-2005
IP: Logged
icon Re: weird fuse behavior (0)  
a a e d
03-08-2010 at 01:35 AM
View Profile Show all user's posts Quote Reply
schep
Level: Smitemaster
Avatar
Rank Points: 865
Registered: 03-01-2005
IP: Logged

File: MirrorBugsTest.hold (3.2 KB)
Downloaded 40 times.
License: Public Domain
icon Re: weird fuse behavior (+12)  
Okay, fixes made. Technically question #3 was tied 3-3-1, but since nobody voiced opposition after I described option e, I gave it the tiebreaker.

Changes in svn revision 9389 (I'll provide a diff file if anyone really wants):

- Closing doors breaks fuses even when a mirror hides the fuse.
- When an explosion hits a tile with mirror and fuse, the mirror is destroyed and the fuse lights.
- Tokens which can toggle state get toggled even when under a mirror.
- If a mirror hiding a scroll falls into a pit or water, the scroll also falls.
- The script command 'Activate Item At' can activate tokens hidden by mirrors.
- If a character appears on a "T-Layer" object on a trapdoor and drops the trapdoor by moving, the object falls if building a pit or water would cause it to fall. [Affected objects: mirrors, potions, orbs, tarstuff, briars, bombs, and stations. Scrolls already worked correctly. Tokens, obstacles, and lightposts never fall.]
- Scripts can place build markers for potions, fuses, and bombs on tiles with mirrors.
- Builders will build fuses underneath mirrors rather than replacing the mirrors.
- When a briar destroys a mirror, any scroll, fuse, or token which was underneath is also destroyed.
- When a Builder destroys a mirror by building a potion or bomb, any scroll or fuse which was underneath is also destroyed.
- Deleted unused and obsolete method CDbRoom::FindLongMonster().

The attached hold provides ways to test all this, plus some behaviors which should not have changed but I needed to double-check since I messed with related code.


[Last edited by schep at 03-20-2010 10:51 PM : a couple more fix descriptions]
03-20-2010 at 10:40 PM
View Profile Send Private Message to User Send Email to User Show all user's posts This architect's holds Quote Reply
Jatopian
Level: Smitemaster
Rank Points: 1842
Registered: 07-31-2005
IP: Logged
icon Re: weird fuse behavior (0)  
I still like a a a d. But whatever, I suppose.

____________________________
DROD has some really great music.
Make your pressure plates 3.0 style!
DROD architecture idea generator

[Last edited by Jatopian at 03-21-2010 12:35 AM]
03-21-2010 at 12:35 AM
View Profile Send Private Message to User Show all user's posts This architect's holds Quote Reply
Syntax
Level: Smitemaster
Rank Points: 1218
Registered: 05-12-2005
IP: Logged
icon Re: weird fuse behavior (0)  
Good work!
03-23-2010 at 06:40 PM
View Profile Send Private Message to User Show all user's posts Quote Reply
New Topic New Poll Post Reply
Caravel Forum : DROD Boards : Bugs : weird fuse behavior
Surf To:


Forum Rules:
Can I post a new topic? No
Can I reply? No
Can I read? Yes
HTML Enabled? No
UBBC Enabled? Yes
Words Filter Enable? No

Contact Us | CaravelGames.com

Powered by: tForum tForumHacks Edition b0.98.8
Originally created by Toan Huynh (Copyright © 2000)
Enhanced by the tForumHacks team and the Caravel team.