The giant Ghini miniboss would be simplier to add as an actual enemy and have the script operate the rocks.  In fact the ghini miniboss also contains code that advances Link up a few squares, and that could even be altered to extend how far link travels.  You need to use F4 as an interaction type to set a boss or miniboss.  It could also just be that minibosses just don't work in the overworld.

I already found all the music data, and imported a song from Seasons into Ages.

What's left is trying to figure out the actual format of the data so we can made custom songs.

Not sure, but I think it might have somthing to do with the subscreen halting the code that deals with placing new sprites in the new room.  Since the glitch involves either the current sprites being totally transplanted to the next screen, or moving slightly, my guess is the level loading routine activates, but the sprite loading routine is interrupted.  If you think about it, firing up the subscreen will keep the current sprites in their spots, and they disappear and come back when you go to and from the menu.  So I think what happens is you enter the subscreen after the level data routine is activated, but the current sprites, which get scrolled away normally, stay put or only go partway, then the new data is loaded.

Oh and if you didn't know already, if you scroll a key onto room 80, it will turn into the hookshot, and if you scroll a key into room 6A, it becomes the Bird Key, but with the nightmare key graphics.  Sprite $30 is used for keys mostly, but also for special items.

The special flag is bit 7, and is used in various things like lock blocks, boss battles, and other things.  That being said if you put a lock block in the same room as a boss, unlocked it and left the room,when you return the boss will be defeated.

Actually this is better off as a unique interaction for maximum control.

For one thing, the spawn enemy command can only spawn a certain type of enemy.  What if there was a custom enemy sprite that, when loaded, will check to see what the arguments of the interaction are and feed that data to the script?  For example, let's say that sprite 80(don't think it exists) is spawned by a script.  The sprite's sub ID will be any sprite of your choosing, and the new interaction will then read that sub ID, load it, then perform the spawn enemy subroutine.  What you can do with a script you can do with ASM.  The script could then handle the sprite locations, the puff of smoke, and the secondary conditions(if one left, turn it red and change stats).

Furthermore, there is really no difference between interactions, enemy sprites, and projectiles.  Code is code.  Perhaps it's possible to make certain enemies contain scripts.

Yeah, it's because you arn't changing the act level data.

I said before that the overworld is split into two chunks.  One is at 24000, and the other is at 68000.  This contains the actual level data the game uses.  The tiles at 98000 are only graphics for the overworld ONLY, and will not appear if you run the game in a regular black and white gameboy mode.

Furthermore, the data at 237A0 is not level data, but tilesheet data.  The game, along with the Oracle games, actually has most of the tile attributes mixed in with ASM.  For example, there isn't a byte that controls if somthing is a slashable crystal or not, but there is instead a check for that particular ID in the sword ASM code that tells the game to treat that tile as a crystal.  The same goes for bushes and tall grass.  Stuff like water, and walls, and pits are defined in the tilesheet colission data.

Very nice.  I always loved dungeons that are intricate and not just a series of disconnected rooms with monsters.

You need to use tile A0 for regular floors.  The one you are using pulls you in down a hole.  The funny thing is that tile, 3E I believe, is actually used in a room in Seasons, but it seems to otherwise act like a regular floor.  So that means if you were to import the level data from the Aquamentus room in Seasons, you couldn't walk through it because all the tiles are set wrong.  Mind you recall that in Seasons there are two rupee rooms that I believe uses this tile and the ones arround it, while all 3 in Ages suck you down a hole.

It's not a bug.

I think it's just the tiles, and I don't think there are any markers to say when one room is done an another starts.  I think it's just room number +80(tiles).  I never really looked into the overlay data much.

The map did change.  You see, in the DX version, there is a seperate section of data that contains a tile overlay.  It's purely graphical, and if you were to add an object, you would still interact with it, but you would not be able to see it unless that tile was changed in the other section.  If you were running it on a regular gb, you would see the changes.  Also, the first two bytes of any room are special.  The first one is, for the overworld, the tile used as the base of the room.  The second byte is the animation index.  For dungeons, the first byte is a bit different.  The first nybble is the room template.  Basically, each room has different preset wall configurations, starting from walls on all sides, to no walls at all.  The second nybble is the first 16 tiles in the tileset, and that is the floor for the room.  The rest is added in as object data.

For objects, there are 3 types.  The first type is a tile ID, and it's x/y position on the map.  It's two bytes long.  3 byte objects have 8x, for horizontal rows, and Cx for vertical columns, prefixed to the data.  x is how many tiles, starting at one(not zero).  Third, there are 5 byte objects that tell the game to add in a warp.  Warp data is part of the actual level data itself.  It starts with Ex, which x being the map type you want to have.  E0 means overworld, E1 means a dungeon or indoors, and E2 means a side scrolling area.  Then comes the dungeon map number, room number, and the x/y co-ordinates(pixel placement).  Overworld data can have several warp data on a screen, provided you place them in the right order.  Dungeon maps can only have one warp per screen.

Also note that objects F0 through FD are not single tile large, but are made up of several tiles.  For example, F5 in the overworld is actually a tree that's 4 tiles large.

Knowing me I bet I made a mistake somewhere.  Also, I wrote that before I knew crap about Z80 ASM so I think I can explain it better now.

Basically, pointers can reference 3 sections of ram.  If the second byte of a pointer is from 00-3F, then it will reference 0000 to 3FFF in ram, which is also 0000-3FFF in the rom file too.  Second, if the second byte is from 40 to 7F, it will reference 4000 to 7FFF in ram.  Finally, anything that uses CX or DX or stuff all access space in the later sections of ram,  FF00 to FFFF is used for direct page access.

Now most data pointes go from 40 to 7F(second byte) because they are stored at 4000 to 7FFF in ram.  All you need to do is reverse the bytes, so if F5 4B is the pointer, than the data is located at 4BF5.  In the rom, you use the start of the bank as the starting address.  So for example, F5 4B at 24000 is 24BF5.  If it were F5 5B, then it would be 25BF5, and if the offset were at 28000, it would be 29BF5.

Now how the game works is that the overworld level data(not the overlay data, but remember that if you are playing in GB mode, you will see this data as is) is broken up into two banks.  Overworld screens from 00 to 7F are stored in at 24000, or bank 09  Screens 80 to FF are located at 68000.  The routine that determines which of the two banks to load is at 3532 in the rom.  It loads the screen number, then checks to see if it's 80 or not.  The it either loads bank 09 or bank 1A.

What makes me wonder is why the programmers didn't just have one entire list of events for all the dungeons like how 21xx works?

That reminds me, there are things this game does that is quite forign to what I've seen in Z80.  For example, if the game wants to read the second ID byte in an interaction, it goes 1E 44, and if it wants to read the first byte, it's 1E 42 or somthing like that.  Those two values must be a ram address, but it doesn't seem to make sense.  Then of course we have a thing that turns a value into a pointer, 1A DF 2A 66 6F, which I don't know what goes on there.  I think there must be some special memory routines that are set up for quick access.  Being able to know what does what(and different values do affect certain things) will allow for greater understanding of the game engine.

Edit:  Actually double checked.  1E 42 is the second ID byte, and 1E 44 is the current piece of code excecuting.  Also it's at D540, so I think this means that 1E is wired to get data from that section, making it somewhat of an additional direct page addressing.  More experiments needed, but my guess is that poking around in that section of ram will reveal a bunch of oft used memory locations needed for everything from events to weapons.

It's not a bug.  The blade traps actually do not travel the full length of the screen.  If they did, the traps would actually pass through each other.  The first LOZ game has this too.  Did you try experimenting with all the traps available?

Furthermore, could you please tell me what room this is in?  Did you check to see if any interactions might be in the way?

I think we need more context, but I do recall that blade traps only go so far.  Did you try an orange trap?

Actually, if I recall, there are two Octorok movement types, which is why there are 2 for red, and 2 for blue.  Gold is just fast so it gets it's own.