Sweet, thanks Lin.  More than wanting to know how to do these things, I wanna figure out more about how the game executes its functions, because the more I know, the more I can find out and potentially be of assistance to others.  So I appreciate that you and Fatories are so patient with my being a noob.

Okay, so I've read through a lot of that PDF file, and I was referring to it quite a bit back and forth with the BGB debugger (very helpful because of the additional details, though I hate how it jumps to the green arrow every time I select the window if I'm looking at something else).

I tried searching for this string: (CC39) to see if I could find anywhere that would pluck the value from CC39 and use it somewhere, but that wasn't very helpful for me.  I got a number of other addresses; 1204, 364B, 457E and 4597 which all use 'ld a,(33C9)' which as far as I can tell from the PDF writes the value at CC39 into 'A', but I couldn't figure out then what pulled that information out of 'A' to determine which dungeon I was in, and thus which text string to show.

I see.  I had a feeling that was broadly how it worked, I just wasn't sure of the particulars.  I've printed off a bunch of stuff while I was at work, so I'm gonna do some reading to hopefully be able to understand all of this better.  You guys are a big help too.

Absolutely it would!  Unfortunately it's greek to me.  I am a pretty quick learner, though, when I can reverse-engineer things myself, so maybe if there is enough documentation out there I'll be able to find out more about it.

I've been playing around a little more with dungeon maps, whereas I was previously doing most of my experimentation with the overworld maps.  Something I've noticed is that the first room of each dungeon contains the same 3 interactions, though some have an extra one or two.  They are...

A type 2 interaction with the ID 1200.  I'm pretty sure this is what causes the pop-up text box with the dungeon name on it.
A no-value interaction with ID E201.  I have absolutely no idea what this does, but I am very curious to know.
Another no-value interaction, 7E00.  This one I'm pretty sure is responsible for the warp that appears when the mini-boss of the dungeon has been defeated, because of the type 2 interaction in the miniboss room which also has the value 7E00.

One thing I'm curious about, is that if every dungeon has the same type 2 interaction ID 1200, how does it know which dungeon you're in?
Secondly, how does the E201 no-value interaction function?  What does it do?  Never mind, figured this one out - it's the eye statues that follow you.

Thanks Lin, I fixed up a couple of things in relation to the collision list.

A few months ago, as part of another guide I wrote (ghetto chests) when I was looking into alternative ways of giving the player items, I discovered an address that I provided as part of that guide (0x0000CC99) which indicates which tile the player is standing on.  I'm not sure if anyone's looked into this area any further, but I just noticed something else, as well - the next address (0x0000CC9A) detects what type of tile the player is currently standing on, which could potentially be useful to some people.  For example, if you're using area ID 0, the the tile that reports the value 00 is a blank yellow tile, or tile 2A is the green tile with bouncing white flowers.

As a reminder to how these both work:

0x0000CC99 uses YX co-ordinates, meaning the first value is the Y co-ordinate and the second is the X-coordinate.
0x0000CC9A reports the tile ID that the player is currently standing on top of.

0x0000CC70 and 0x0000CC71 also keep track of more specific position values, I'm not exactly sure what the metric used is (by pixel maybe?) but CC70 determines precise Y co-ordinates and CC71 does the same for X-coordinates.  Also, if you're facing up/down, the following two addresses (~CC72/CC73) will read 01 and 06 respectively, whereas if you're facing left/right they will read 07 and 01.  I haven't yet figured out the significance of this, but I guess it could be useful.

Another thing I discovered while debugging is information about obstacles - places on the map that you cannot pass through.  0x0000CE00-FF through to 0x0000CE70-FF will tell you what you can and cannot walk through on that map.  The values I've found so far are:
00 - Passable
01 - 25% obstacle, bottom right corner is blocked
02 - 25% obstacle, bottom left corner is blocked
03 - Ledge that Link will jump over
04 - 25% obstacle, top right corner is blocked
05 - 50% obstacle, right half is blocked, left half is passable (used for cave/indoor exits) - Also used for horizontal ledges, if the next block is clear then Link will jump over the edge.
06/07 - 75% obstacle, top left corner is passable
08 - 25% obstacle, top left corner is blocked
09/0D - 75% obstacle, bottom left corner is passable
0A - 50% obstacle, left half is blocked, right half is passable (used for cave/indoor exits) - Also used for horizontal ledges, if the next block is clear then Link will jump over the edge.
0B - 75% obstacle, top right corner is passable
0C - 50% obstacle, top half is blocked, bottom half is passable (may work for ledges as well, have not tested as there are no preset tiles for north-facing ledges)
0E - 75% obstacle, bottom right corner is passable
0F - Obstacle
10 - Pitfall, Water (changing this value to 00 will NOT allow Link to walk over pitfalls or walk on water)
11/15/16 - Passable, cannot enter/exit to east/west (used for single-width vertical bridge)
12 - Passable, cannot enter/exit to west (used for left half of double-width vertical bridge)
13 - Passable, cannot enter/exit to east (used for right half of double-width vertical bridge)
18 - Stairs (not the exit kind, the kind that slows movement when you walk up/down them)
19 - Passable, cannot enter/exit to north/south (used for single-width horizontal bridge)
1A - Passable, cannot enter/exit to north (used for top half of double-width horizontal bridge)
1B - Passable, cannot enter/exit to south (used for bottom half of double-width horizontal bridge)

By changing these values, you could make an invisible maze, or block a player from leaving an area without having to change any map tiles.

That's all for now, but I'll keep messing around in the VBA Memory Viewer to see what else I can dredge up.

Hey, you came back!  I was pretty bummed when I came here a while ago and the site was down.  Looking forward to see what ZOLE 5 looks like!

Thanks for the reply, Lin, I'll start to look into that, I'm just hoping you could explain something else to me, if you don't mind, because I'm not very experienced with the coding side of this.  How exactly do I find the Dx40-Dx7F addresses in the VBA memory viewer?  Is it 0xD000 WRAM?

Nevermind that, I figured out what you meant and I understand how that part works with interactions now.

I noticed that all the "time hole" interactions have '81' in the 'Dx40' address.  Is this unusual?

I've been playing around a little with making Time Hole tiles, and I just thought I should share, in case nobody else has discovered the distinction yet, the interaction addresses for different types of Time Holes - the ones activated by your 'Tune of Echoes'.

E100 creates a standard time hole that is activated by the harp.
E101 creates a permanently open time hole, which will stay active even if you leave the map.

I've been studying the start event where Veran attacks Nayru, trying to figure out how the game then turns off the permanently active portal that Veran opens on the ridge.  I do know that exactly as the time hole is activated, the map's memory address goes from D0 to D8.  This seems to be significant in some way because whenever the 'Tune of Echoes' is played to activate an 'E100' type time hole, the map's value changes from x0 to x8.  If anyone else has done much work on these interactions, I'd be interested to know if there was a way to change the ID of a type 2 interaction, in this case to change it from 'E101' to 'E100', making a portal that is opened by an event and then becomes one that the player can activate with the harp.

Edit:  Or, alternatively, if anyone knows how to 'despawn' a type 2 interaction via a script, if either are possible.

I thought that might be the case...  I was hoping to keep the same area and tileset, but just switch the palette after a switch had been triggered.  It's only a minor inconvenience, I can work with it this way, too.  Thanks for the reply.

Hey guys, sorry I've been quiet for a while - I've been working on maps and things, and I haven't really discovered anything new lately.  I've actually run into a bit of a stumbling block with regards to something I'm trying to do, I want to force a map to use a different palette than its native one, and I was wondering if there was any way to do this?

Scratched the contents of this post because the problem I was having I fixed, but I did discover something.  Changing the bytes at the required addresses in a hex editor had the unfortunate effect of glitching my tilesets for whichever area ID was 4 numbers up from the one I was trying to edit.  So, when I modified area ID 3 ($10FDA) in the hex editor, area ID 7 became glitchy.  Same thing happened when editing ID 4 ($10FE2), causing problems with ID 8.

So, I avoided using the hex editor and just tried to use Fatories' suggestion of using setmemory C7xx.  I found it worked perfectly if the area IDs were different, but the rest of the area properties (Tileset, Palette, etc) were all the same.

Fantastic, thanks heaps!

This is fantastic, I just got it to work on a map of mine.  I was just wondering, is there any way I can trigger the change from another map?