Door - Revision history

The Green Herring: terrain -> item

2021-02-10T05:46:25Z

terrain -> item

← Older revision		Revision as of 05:46, 10 February 2021
Line 3:		Line 3:
	\|id={{Byte\|9}}		\|id={{Byte\|9}}
	\|char={{CharSwatch\|10}}		\|char={{CharSwatch\|10}}
	\|category=~~terrain~~		\|category=item
	\|stats=no		\|stats=no
	\|destructible=no		\|destructible=no

The Green Herring at 02:28, 10 February 2021

2021-02-10T02:28:17Z

← Older revision		Revision as of 02:28, 10 February 2021
Line 9:		Line 9:
	\|uses zzt-oop color=yes		\|uses zzt-oop color=yes
	}}		}}
	The '''door''' element is one of the built-in puzzle elements of [[ZZT]]. It blocks the [[player]]'s path unless the player has the corresponding [[key]]; together, they allow the designer to create a simple lock-and-key puzzle. When a door is touched without the player carrying its key, the game prints "The X door is locked!" where X is the color, and impedes the player. When the player touches the door while carrying its key, the game prints "The X door is now open." where X is the color, and replaces the door with an identically-colored [[empty]]. The engine uses the background color of the door to determine what color of key it requires.		The '''door''' element is one of the built-in puzzle elements of [[ZZT]]. It blocks the [[player]]'s path unless the player has the corresponding [[key]]; together, they allow the designer to create a simple lock-and-key puzzle. When a door is touched without the player carrying its key, the game prints "The X door is locked!" where X is the color, and impedes the player. When the player touches the door while carrying its key, the game prints "The X door is now open." where X is the color, consumes the key, and replaces the door with an identically-colored [[empty]]. The engine uses the background color of the door to determine what color of key it requires.

	By default, when creating a door, the engine creates a white-foreground element with a background color corresponding to the requested color. For example, any request for a blue door results an element that is {{ColorSwatch\|fg=white\|bg=dark blue}}. This can be exploited with [[ZZT-OOP]] to programmatically create elements with a white foreground and a dark background color other than black, which is not normally possible, by using [[Put\|#put]] to overwrite the door with an applicable element (such as a key or a [[gem]]) or using the [[Change\|#change]] command to turn it into one. An external editor can be used to place any color of door the designer likes, as long as the background color matches the key that must be used to open it. Blinking doors (or bright-background doors if blinking is disabled) function identically to non-blinking (or dark-background) doors. A chart indicating the default door colors follows:		By default, when creating a door, the engine creates a white-foreground element with a background color corresponding to the requested color. For example, any request for a blue door results an element that is {{ColorSwatch\|fg=white\|bg=dark blue}}. This can be exploited with [[ZZT-OOP]] to programmatically create elements with a white foreground and a dark background color other than black, which is not normally possible, by using [[Put\|#put]] to overwrite the door with an applicable element (such as a key or a [[gem]]) or using the [[Change\|#change]] command to turn it into one. An external editor can be used to place any color of door the designer likes, as long as the background color matches the key that must be used to open it. Blinking doors (or bright-background doors if blinking is disabled) function identically to non-blinking (or dark-background) doors. A chart indicating the default door colors follows:

The Green Herring: 🚪

2021-02-10T02:27:04Z

🚪

New page

{{Element
|zzt-oop name=door
|id={{Byte|9}}
|char={{CharSwatch|10}}
|category=terrain
|stats=no
|destructible=no
|effect on movement=wall
|uses zzt-oop color=yes
}}
The '''door''' element is one of the built-in puzzle elements of [[ZZT]]. It blocks the [[player]]'s path unless the player has the corresponding [[key]]; together, they allow the designer to create a simple lock-and-key puzzle. When a door is touched without the player carrying its key, the game prints "The X door is locked!" where X is the color, and impedes the player. When the player touches the door while carrying its key, the game prints "The X door is now open." where X is the color, and replaces the door with an identically-colored [[empty]]. The engine uses the background color of the door to determine what color of key it requires.

By default, when creating a door, the engine creates a white-foreground element with a background color corresponding to the requested color. For example, any request for a blue door results an element that is {{ColorSwatch|fg=white|bg=dark blue}}. This can be exploited with [[ZZT-OOP]] to programmatically create elements with a white foreground and a dark background color other than black, which is not normally possible, by using [[Put|#put]] to overwrite the door with an applicable element (such as a key or a [[gem]]) or using the [[Change|#change]] command to turn it into one. An external editor can be used to place any color of door the designer likes, as long as the background color matches the key that must be used to open it. Blinking doors (or bright-background doors if blinking is disabled) function identically to non-blinking (or dark-background) doors. A chart indicating the default door colors follows:

{| class="wikitable"
|+ Default door color chart
|-
! ZZT-OOP name !! Element color
|-
| Blue || {{ColorSwatch|fg=white|bg=dark blue}}
|-
| Green || {{ColorSwatch|fg=white|bg=dark green}}
|-
| Cyan || {{ColorSwatch|fg=white|bg=dark cyan}}
|-
| Red || {{ColorSwatch|fg=white|bg=dark red}}
|-
| Purple || {{ColorSwatch|fg=white|bg=dark purple}}
|-
| Yellow || {{ColorSwatch|fg=white|bg=brown}}
|-
| White || {{ColorSwatch|fg=white|bg=light grey}}
|}

== Black doors ==
While doors can be placed in all of the available colors, and black-foreground doors work with no issues, doors with black background colors (or dark-grey when blinking is disabled) will have glitched behavior when interacted with:
# Touching a door or opening one will create a garbled mess in place of the color name that includes "Blue", "Green", "Cyan", "Red" and "P";
# The player cannot open it unless they have at least 256 gems, whereupon the gems counter will be decremented by at least 256—or more.
Both of these are out-of-bounds errors related to the arrays used for keys, as follows:

=== Color naming ===
The color naming for pickup messages is handled by the <tt>ColorNames</tt> array in GAME.PAS line 92, which has entries for color indexes 1 to 7 of the CGA color palette. This is an array of strings up to eight characters in length. When the engine attempts to access the color name for index 0, the color black, it attempts to access the entry prior to the first entry, <tt>Blue</tt>, and goes out of bounds into where the preceding <tt>ProgressAnimStrings</tt> array exists in memory. It then fails to detect when an entry ends, and prints as much of the succeeding portion of memory as it can fit, producing the glitched message. When editing the engine, the bug can be fixed by changing the array range from <tt>1 .. 7</tt> to <tt>0 .. 7</tt> and adding <tt>'Black',</tt> to the start of the array before <tt>'Blue',</tt>.

=== Counters ===
The key counter in the world format is defined in GAMEVARS.PAS line 111, under <tt>TWorldInfo</tt>, as a boolean array named <tt>Keys</tt> which ranges from 1 to 7, covering CGA color indexes 1 to 7. Collecting the keys of these colors sets their equivalent boolean to "true", which is indicated internally as <tt>01</tt>; when used, they are set to false, or <tt>00</tt>. When the engine attempts to access the entry of this array for color index 0, the color black, it sets <tt>00</tt> in the byte prior to that of the Blue key, and in doing so goes out of bounds into the second byte of the gems counter, a 16-bit signed integer that thus uses the second byte to indicate units of 256. Because of this, the player's gems counter will be reset to just the amount covered by the first byte, from 0 to 255. The bug can be fixed by changing the <tt>Keys</tt> array range from <tt>1..7</tt> to <tt>0..7</tt>, but doing so will also change the world format, making all standard world files incompatible with the engine.

[[Category:Elements]]
{{ElementsNavbox}}