Could I get a little bit more information on Interactions?

[BigTarantula99]

I saw the beginner's stuff here: http://zeldahacking.net/forum/index.php?topic=31.0, but I would like to add onto that a bit.  I'm still confused with some interactions.  Hopefully knowing some of this will make my hack turn out much better.  (It'll be worth it in the end.)

Here are my main questions (Lin, I know you've said you don't remember some of this.  If you don't that's okay.).
1.  What's the difference between Interaction Type 1 (red) and 2 (orange)?  Besides that 1 doesn't have it's own set location and 2 does.
2.  What's the difference between Interaction Type 1 (red) and 3 (yellow)?  I see type 3 on many map screens but don't have a clue what they do.
3.  What is Interaction Type 5 (blue) and is it ever useful?
4.  How do I use Interaction Type 8 (gray) with an owl statue?
5.  What is Interaction Type 9 (white) and what's the difference between type 9 and type 2?
6.  When is the best time to use each type of interaction as supposed to another?  What's an example of a good time to use each type?  I already know many custom interactions (72) use Interaction type 2 so I'm good on that.

I know it's a lot of questions so you can take as long as you'd like with this answer.  But if I don't find out about this stuff, I won't get very far in my hack or it won't be nearly as good.  Thank you so much!

[Lin]

1 and 5. Interactions 1, 2, and 9 are all the same. The IDs all share the same assembly pointer tables, so having a type 1 interaction with the ID of 2201 and a type 9 with that same ID will create the same thing. The only difference is 1 is a no-parameter interaction (it only contains the interaction ID), type 2 has two parameters (commonly used for coordinates but can be used for other things), and type 9 has I believe four parameters. When I originally created ZOLE I didn't know this.

2. See 1. Type 3s (yellow) are literally just bank 0x12 pointers. They point to a group of interactions and are used to save space spawning interactions that may have already been defined somewhere else.

3. Type 5 is the same as type 3 except the enemies only spawn is a specific flag is set. I think it's flag 80 but I'm not entirely sure. The only place I've seen these used is the second screen in Seasons where you met Din. After that event, octoroks will spawn.

4. I've never messed with them before but I just looked into them. They're very simple. 13XX is their ID, with the XX being the text index you want them to show. As usual, you'll just have to try and find the text using ZOTE since there is no pointer editing unfortunately. The position value is just the YX you want the owl to appear at.

5. See 1

6. Ah, great question. In 1 I explained that 1, 2, and 9 are all the same, so really it comes down to your scripts. Fatories and I started using type 1s for our 72 scripts to conserve space if the script didn't take any parameters. Even for ones that did, like a position value, if we needed the space we would use a type 1 and do a "setposition" command in the script. Our philosophy was we'd rather take up the 1MB+ of space you get with scripts filling the position and other values instead of taking up the small hundreds of bytes you get with interactions. Of course, if you plan on making it a widely-used script that accepts a position, you might want to just use a type 2.


EDIT: If you're curious, I made a tiny program a long time ago that never became anything or got released (it's attached). Most of it is junk and only works for specific interactions (it's a small semi-NPC sprite editor) but it allows you to put in any interaction ID and will give you the bank, relative address, and exact address of the interaction's assembly if you want to get dirty.

[BigTarantula99]

When is the best time to use each type of interaction as supposed to another?

as opposed to another, duh...

I also hear about these "banks" which you told me in another thread is a set of 0x4000 bytes.  Okay, but what is contained in each one?  So if an Interaction Type 3 points to Bank 0x12, what is actually in that bank that's significant?

[Lin]

A bank is just a way data is grouped. The gameboy uses 16-bit addressing, meaning it's memory can only go up to 0xFFFF. But wait, ROMs need at least 24-bit addressing! The gameboy then introduces something called the memory bank controller (MBC), which will contain one defined bank in its memory from 0x4000-0x7FFF. So if it's reading bank 12, it will have the same data in the ROM at 0x48000-0x4BFFF stored in its memory from 0x4000-0x7FFF. In order for the gameboy to read this data, instead of using 0x48123 for the address, it uses 0x4123. This is why you almost always see pointers in the range of 0x4000-0x7FFF.

Bank 12 is mostly home to all of the map interaction data. Of course, it can be anything, but the developers were kind enough to organize everything so that certain banks contain certain data. The type 3 ID is a pointer, meaning its value is most likely going to be 0x4000-0x7FFF. So to get the absolute address, take bank 0x12, multiply by 0x4000, subtract 0x4000 from the type 3 ID, and add it to the bank's total. 0x12 * 0x4000 + type3ID - 0x4000. To reverse an absolute address and turn it into a gameboy pointer, the easiest way is to modulus the absolute address by 0x4000 and add 0x4000. So absoluteAddress % 0x4000 + 0x4000. Now, the gameboy always keeps the ROM's 0x0000-0x3FFF data loaded in the beginning of its memory from 0x0000-0x3FFFF, meaning bank 0 is always loaded and accessible. If you wanted to read from it, you wouldn't add the 0x4000, you would just use the absolute address. This means it's possible to keep the first 2 banks of the ROM loaded into the RAM and whole-number-accessible. But you probably won't have to deal with that.

Type 3s point to interaction data. You can't really edit this with ZOLE so you'll have to use a hex editor. The interaction format is pretty simple though - Fx ID ID (any parameters in bytes here). So a type 2 interaction with the ID 1234 located at the coordinates 28, 68, would (probably) look like: F2 12 34 28 68. The pointer doesn't know how many interactions it's going to read, so it goes until it hits the byte FE. Interactions for maps usually end with FF, but IIRC in the game code, FE means it's the end of a loaded pointer (AKA type 3) and it needs to resume the normal data. So if you point a type 3 to your regular map's interaction data, your game might crash or the interactions will stop loading after the type 3. The same type 2 interaction above being ended would just look like: F2 12 34 28 68 FE. And that's it. Pretty simple stuff.

[BigTarantula99]

Wow,  I was not expecting all that : )  Thank you very much, that definitely helped.

One other thing that I didn't think deserved a separate thread - I've seen certain tutorials and such regarding ZOSE to start a script like this:

Code:

writelocation xxxxxx
setinteraction72 $$
jump3byte yyyyy

writelocation yyyyy

But starting a script without jump3byte and the other writelocation still works fine.  What difference does adding jump3byte make?

[Lin]

Well back in the day when ZOSE first came out, type 72 interactions had to initially start in bank C, where the original scripts are located. There was very little space here, so in order to preserve as much of that space as possible we would make it jump immediately to a bank with more space. I believe with the newer ZOSE though you don't need the jump3byte and can start at any address you want.

[BigTarantula99]

Hooray, I get more stuff now!  Thanks!