A relatively candid description of all the bugs I've exploited on my inanity.dat set: #1: The multiple tank bug. This bug occurs when a tile containing a tank has multiple entries in the monster list. Originally discovered when investigating some of the effects in pi^2.dat's "what the???", I found that duplicating a tank in the monster list has some weird effects. My empirical observations lead me to the following attempt at explanation: - Because of the way that the tanks move, only one tank will move out of the tile. Normally, with any other monster, the tile would "sprout" monsters in all open directions that the monsters will move. The number of monsters "sprouted" will be equal to the number of corresponding monster list entries. - However, for tanks, only one tank will move. Therefore, the location that the tank started at will still have an entry in the monster list, just sitting there. Normally this would do nothing, except that if this tile causes objects to slide (ice, ice corner, ff-nonrandom), the tile will itself begin to slide. - I still do not fully understand exactly what happens next, but the tile will move in the direction that the most recent object on the slip list was moving. Only objects that go onto the slip list after the tank moves off its starting square will be counted here. - The tile, as it begins moving, will retain the identity of whatever was at its location while sliding. Thus, if the tile was ice, the sliding tile will also be ice. If it was force floor, it will also be force floor. - The sliding object's identity will change, however, depending on the direction in which it is sliding. This occurs because the display updates the direction in which the "monster" is facing, and the different-direction-facing monsters are distinct tiles. More on what sort of tiles you can get to slide later. To get a handle on this, I recommend looking at Chipedit's palette. In any case, the internals of the game engine treats this object as a monster (so it's affected by slide delay, won't go through random force floors, etc...), but it has all the properties of the tile it appears to be. - So, for example, if the sliding object looks like an exit, Chip can step into it and win the level. If it looks like a chip, Chip can step into it and pick up a chip. If it looks like a blue wall, Chip can press against it and either turn it to floor or turn it into a real wall. - If Chip occupies the location of the sliding object while it's sliding, if he's not killed (drowning in water, for example), then the tile it appeared to be will be stationary in its new location. So, if he steps into a moving floor tile, the location he stepped into will now be floor. However, the object will continue sliding and take with it the new identity of whatever was occupying its old square. (this actually makes sense, based on the order of movement of Chip and monsters). - Ok. Confused yet? - Back to what sorts of tiles you can create: The tiles come in sets of four; groups of 4 correspond to whether the object is moving north, east, south, or west. I have been able to create the groups with the following tiles: - floor/wall/water/chip - panel-s/panel-e/movable/dirt - ice/ff-s/clone-n/clone-w - clone-s/clone-e/ff-n/ff-e - clone-w/exit/door-b/door-r [EDIT: "clone-w" in this line should read "ff-w". -James Anderson] - door-g/door-y/ice-se/ice-sw - ice-ne/ice-nw/blue-f/blue-r - button-b/teleport/bomb/trap All but the first two and the last cases are directly created when any of the sliding tiles in the list is put under a duplicated tank. The first case can be done by sliding Chip through the "location" with a boost. The second case can be done by pushing a block onto a sliding floor tile. The last case is more difficult - it requires passing the sliding object over a blocked teleport while the object has the identity of a door, then opening the door and making an object slide to make the "teleport" move in the appropriate direction. (incidentally, I would assume that in pgchips, one could push an ice block onto a sliding floor tile and create the exit-2/exit-3/exit-4 tiles). - One can also do other interesting things with these tiles (as well as create them just by adding monster locations to appropriately-defined objects). I'm not sure if one can create any tiles other than these, Chip, and monsters. For many basic examples of these ideas, see the twenty-odd levels in the multiple-tank-bugs.dat set. #2: The (x,32) bugs. - This bug was used extensively in pi.dat's level 41, and it was through my efforts in trying to solve this level that many of the levels in inanity.dat were created. - The gist of the bug is this: The map is 32 by 32, and is treated by the game as a grid with xy-coordinates running from 0 to 31. However, the game is lazy, so it stores data in locations in memory in the lower layer of locations that can be viewed as (x,32) for particular values of x. - The interesting values are these: * (0,32): the current level number. * (8,32): x position of chip. * (10,32): y position of chip. * (12,32): 1 if chip is sliding, 0 if not. * (14,32): 1 if there's a buffered keystroke, 0 if not. * (18,32): x-direction of buffered keystroke. * (20,32): y-direction of buffered keystroke. * (22,32): chip's autopsy report: 0. okay 1. drowned 2. burned 3. bombed 4. killed by block 5. killed by monster 6. out of time * (24,32): chip's x-slipping direction. * (26,32): chip's y-slipping direction. - If there is a submerged clone-n in the lower layer of (x,0), and (x,31) is free (meaning that a block can enter it), then if a button pointing to (x,32) is pressed, the following happens: - The block-n at (x,0) moves "north" and reappears at (x,31). - The data in (x,32) is reset to 0. - The tile in the lower layer of (x,0), formerly a block-n, is replaced by the tile with the value of the data formerly occupying (x,32). - The tiles in the game are each assigned a value from 0 to 255. The values for the game tiles range from 0 to 120 or so, and may be easily found from Chipedit's palette. Floor is 0, a wall is 1, a clone-n is 14, an exit is 21, and so on and so forth. - Resetting the data in (x,32) for x in the above list can have very interesting effects. For example, resetting (8,32) resets Chip's x-position to 0, so he will get "warped" to the left edge of the map. Resetting (12,32) resets his sliding to 0, so if he is sliding, he will stop. Resetting (0,32) will reset the game's counter of the level number to 0, meaning that it will think that the level is now level 0 if it is won (leading to a level bonus of 0) and if the player attempts to go to the next level, the game will wind up back at level 1. If the player restarts, dies, or attempts to go to the previous level, the game will give the "invalid/corrupt .dat file" error and close. Resetting (22,32) will allow Chip to be "immortal" for the remainder of the tick -- it's generally only useful if hit by a monster early in the monster list -- allowing monsters to pass through him if timed properly, or for him to be crushed by a block and not die. - Additionally, since the tile in the lower layer of (x,0) is replaced by the tile with value equal to the data replaced, if the data's value is 14 then that location may be reset again, since the block-n will be replaced by the tile with value 14, also a block-n. If the data's value is 21 then the tile will be an exit instead, which may also be very helpful. #3: Invalid tiles - A few levels contain invalid tiles which are outside of the normal ranges for the game's tiles. These levels were created accidentally by a weird glitch in chipedit that seems to lose parts of levels every once in a while. One is a glitched version of what used to be level 4 in inanity.dat, and it contains a bunch of "00 floor" tiles. Another is a copy of the same level but is different, and renders differently when viewed in chipedit. A third is a glitched version of a sokoban level in an unreleased set. Opening this level in chipedit is advised against, since the editor crashes if the mouse rolls over some of the invalid tiles. - These tiles are just tiles outside the normal range of values (1-120 or so). They are masks and other various graphics used internally by the game to compose different tiles on top of one another. The tile with value K may be fabricated during the game (if a list is desired) by placing Chip on top of a clone-n at (0,0) and connecting a button to (0,32) as well as a glider to trigger the button. If Chip remains stationary, when the glider triggers the button the clone-n beneath Chip will be replaced by the tile with value K, where K is the current level number. Making a set with 256 copies of this level would allow one to catalogue the various types of tiles with values between 128 and 256 if desired.