Jump to content
IGNORED

Tunnels of Doom cheat found


S1500

Recommended Posts

 

At least one bug where you get a glitched item was described in 99'er or Micropendium. I read about it and used it in 1985.

 

 

I think it goes, when you find a scroll or more items in a room, refuse them, then drop your armor or weapon there. Leave and re-enter. I seem to recall any 3 items left in a room produce a glitched item.

 

A glitched item will have a name of "0" and an attack parameter of 32. You can drop a sling into this bubbling cauldron and get back a ranged weapon titled 0(32). The 0(32) persists in saved games.

 

The name 0(32) was an in-joke among my friends. It sounded like escalating from plain old Sword, +1, directly to M-1 tank or an F-18 fighter.

 

Bonus points to the person who looks at the GPL and explains the bug!

  • Like 1
Link to comment
Share on other sites

Actually, I can see both of these being intentional bugs designed to give massive power to the in-house testers to ensure they didn't need to run through the game too many times to test various expected conditions. The circumstances to get each glitch to occur are just screaming intentional edge case to me for some reason. . .

  • Like 2
Link to comment
Share on other sites

Actually, I can see both of these being intentional bugs designed to give massive power to the in-house testers to ensure they didn't need to run through the game too many times to test various expected conditions. The circumstances to get each glitch to occur are just screaming intentional edge case to me for some reason. . .

 

I think it is a simple buffer overrun. One edit buffer for the current room holds 3 objects, but when you leave the room, it goes into storage for the room. There's not room for the 3 objects in the storage, but it still says there are 3, so when you come back it copies some memory from past the end of storage.

 

My game AdventureQuest (unreleased) had a save file with sectors of 192 bytes of 6-bit tiles (arranged in 16x16) + a monster and item storage in the remaining 64 bytes. When the sector is in use, the 64 byte object list is unpacked into working memory. When the sector goes out of use, the list gets re-packed. I spent a lot of time ensuring that it would always retain its integrity when copied back to that 64 byte buffer. Because I didn't want the bug that TOD had.

 

(it was actually a nested list.. each object in it was "Duck Typed" by a list of key-value pairs, and value could itself be a list.)

This was built to allow for more weird corner cases than I could think of!

If this structure had been damaged it would have been interesting.)

Link to comment
Share on other sites

 

I think it is a simple buffer overrun. One edit buffer for the current room holds 3 objects, but when you leave the room, it goes into storage for the room. There's not room for the 3 objects in the storage, but it still says there are 3, so when you come back it copies some memory from past the end of storage.

 

My game AdventureQuest (unreleased) had a save file with sectors of 192 bytes of 6-bit tiles (arranged in 16x16) + a monster and item storage in the remaining 64 bytes. When the sector is in use, the 64 byte object list is unpacked into working memory. When the sector goes out of use, the list gets re-packed. I spent a lot of time ensuring that it would always retain its integrity when copied back to that 64 byte buffer. Because I didn't want the bug that TOD had.

 

(it was actually a nested list.. each object in it was "Duck Typed" by a list of key-value pairs, and value could itself be a list.)

This was built to allow for more weird corner cases than I could think of!

If this structure had been damaged it would have been interesting.)

 

Yeah, items in ToD have their characteristics copied with them, so if it read past the buffer it's probably picking up a "32" consistently from a memory area beyond that.

 

Come to think of it... ToD must be using VDP memory to store item and room data, it's the only place with enough RAM on a base console. Using Classic99's debugger you could probably find in memory where it's storing all of it and discern the data structure.

 

In my own CRPG, I use two bytes for all items; a category and a # assignment. If the top bit of the # is set, it's an unknown item of it's type. All other data (damage, hit, protection, etc.) is stored in data tables that are referenced. This means you can't have honing stones or similar effects that change your item's abilities, as I'd have to store the entire structure for an item (16 bytes) everywhere.

  • Like 1
Link to comment
Share on other sites

VDP has a GARBAGE COLLECTION that is often triggered for various reasons.

 

A compression may result in a GPL command that using AND or a XOR or OR might change the way a branch value works.

 

But more likely it is a TESTING CHEAT CODE method to speed up looking for errors, but never removed from GPL code.

 

Many games have this left into the code. Later people find them by accident.

Edited by RXB
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...