Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#1 2013-09-24 02:39:14

Vitharix
Member
Registered: 2011-12-29
Post 323/396

Trigger clarification

Proper implementation of a trigger eludes me.

After consulting the Compendium and all of these threads, I still can't put it all together.

What I'm trying to do is turn off wild battles when the player steps on one trigger tile, and turn them back on when the player steps on the other.

I can't seem to find documentation of the full extent of trigger structure. I know that there is the trigger table at x94000 and the other at $D6B7 and the structure of triggers in the event data, but I suppose what I'm struggling with most is what to make of "trigger timing", trigger flags, and how I should put my trigger into the table(s). Moreso than anything, I'd like to understand how these all function together.

Can somebody lend a helping hand?


another relevant post

Last edited by Vitharix (2013-09-24 04:57:50)

Offline

#2 2013-09-24 06:26:37

Miksy91
Member
Registered: 2010-10-16
Post 1,898/2,308

Re: Trigger clarification

Hi (, and might as well talk to you sometime soon elsewhere as well) !

I remember trying to take out the wild battles in my own hack with script code 37 ("Deactivate PKMN battles"), but it didn't work.
I believe the problem is that code 37 doesn't do that, instead of a possible reason that the trigger tile that you step on wouldn't call the script you're intending.
You should actually test if codes 37 and 38 work the other way around!

But if trying to call something else from the first trigger event won't solve the problem, you have to adjust the trigger table in 0x94000. The structure there tells, where in ram the data/flag of certain map is located, and the next two bytes work as the map bank & number for that ram address.

For example, if we wrote bytes "70 DC 05 0A" in the beginning of the table, 00 would be written to $DC70 from the start (actually, that 00 is written there is probably incorrect but whatever!). Now, you can put trigger events to map 5.10. Now if you put trigger events there and probably while at it, happen to use a script code for changing the trigger flag (12 or 14), the byte in $DC70 is re-written to the value you chose for the trigger number to be.

And when the value in DC70 is for example 02, only trigger events that use flag 2 (as shown with Johtomap) will activate when you step on them. Normally, you don't have to "return" back, so like, if the first trigger event uses flag 0, you probably want to change that to 01 for flag 1 event to activate etc. But if you feel like going for something complicated, you probably need to adjust it over time.

Last edited by Miksy91 (2013-09-24 06:30:15)

Offline

#3 2013-09-24 07:54:10

comet
Member
Registered: 2012-04-09
Post 299/673

Re: Trigger clarification

your confusion stems from the fact that there are actually two things called triggers

the one youre talking about is an x/y trigger (coord event). these just run some script when they get stepped on

the commands did get mixed up. updating the compendium would probably make it more confusing

Offline

#4 2013-09-25 00:24:53

Vitharix
Member
Registered: 2011-12-29
Post 325/396

Re: Trigger clarification

Miksy91 wrote:

But if trying to call something else from the first trigger event won't solve the problem, you have to adjust the trigger table in 0x94000. The structure there tells, where in ram the data/flag of certain map is located, and the next two bytes work as the map bank & number for that ram address.

So: [$FFFF][map no.][map bank] is the structure, then.

It looks like in the ROM it is in this order: [map bank][map no.][$FFFF]

Does each trigger need to have it's own entry in the table, or is it just one for each map you've put one on?

For example, if we wrote bytes "70 DC 05 0A" in the beginning of the table, 00 would be written to $DC70 from the start (actually, that 00 is written there is probably incorrect but whatever!). Now, you can put trigger events to map 5.10. Now if you put trigger events there and probably while at it, happen to use a script code for changing the trigger flag (12 or 14), the byte in $DC70 is re-written to the value you chose for the trigger number to be.

For the script I have attached to the trigger(in Johtomap), do I need to have the script look in the RAM where the bit was written from the entry in the table and use that bit to make the script run when the trigger is stepped on?

And when the value in DC70 is for example 02, only trigger events that use flag 2 (as shown with Johtomap) will activate when you step on them. Normally, you don't have to "return" back, so like, if the first trigger event uses flag 0, you probably want to change that to 01 for flag 1 event to activate etc. But if you feel like going for something complicated, you probably need to adjust it over time.

So the 00, 01, 02 that's written to the RAM has a dual-function, yes? To tell the game that 1) there's a trigger on this map and b) the variables tell the game what happens when the tile is stepped on or if it happens automatically when the player steps on the map. Where do the commands dotrigger and domaptrigger (or 11, 12, 13, 14) come in to play?

comet wrote:

your confusion stems from the fact that there are actually two things called triggers
the one youre talking about is an x/y trigger (coord event). these just run some script when they get stepped on
the commands did get mixed up. updating the compendium would probably make it more confusing

Ah, that sure wasn't helping me. What are the other thing called a trigger?




EDIT

Well I figured it out. Turns out that the codes 37 and 38 don't do what the Compendium says; unless of course I'm missing something.

But I first checked the ram address where I had the bit being set and it worked, so I just then looked at my script and figured it out from there. I'm still don't fully understand how it works, but at least I did it, eh?

Also, don't forget to put code 11, 12, 13, 14 at the beginning of the script.....

Last edited by Vitharix (2013-09-25 05:02:42)

Offline

#5 2013-09-25 06:29:37

Miksy91
Member
Registered: 2010-10-16
Post 1,902/2,308

Re: Trigger clarification

Vitharix wrote:
Miksy91 wrote:

But if trying to call something else from the first trigger event won't solve the problem, you have to adjust the trigger table in 0x94000. The structure there tells, where in ram the data/flag of certain map is located, and the next two bytes work as the map bank & number for that ram address.

So: [$FFFF][map no.][map bank] is the structure, then.

It looks like in the ROM it is in this order: [map bank][map no.][$FFFF]

Apparently I got it wrong. It's indeed [Map Bank][Map No.][Pointer to RAM]

Vitharix wrote:

Does each trigger need to have it's own entry in the table, or is it just one for each map you've put one on?

Each map that uses these "coordinate event" triggers (which you place on the map as events) needs to be in this table indeed. I believe that when you step on a trigger event on a map, the following code gones through;

check if the values in DA00-DA01 (= "Map Bank, Map No. in ram") match with the first two values of any 4-byte entry starting at $94000 (+ keep current table index somewhere safe)
if "match" {
 
 load the value from the ram address that follows the start point of this entry somewhere safe (in other words, loads the value from ram that this Map Bank and  Map No. in the trigger table defines)
 check if this value matches with the flag of the trigger tile that was stepped on
 if "match" {
  start executing script
 }
 else {
  return
 }

}
else {
 return
}
Vitharix wrote:

For the script I have attached to the trigger(in Johtomap), do I need to have the script look in the RAM where the bit was written from the entry in the table and use that bit to make the script run when the trigger is stepped on?

That kind of a code I explained above does all the background process. If the Map Bank and Map No. are explained in the trigger table, the trigger tile's flag is compared with the trigger number of this map in ram. If those match, script is executed.

Vitharix wrote:

Where do the commands dotrigger and domaptrigger (or 11, 12, 13, 14) come in to play?

12 and 14 can be used to change the trigger number of the map you are on, or any specific map. Thus, activating trigger events of other flags.
11 and 13 are just for checking what the trigger number value in ram is. Could be useful if you don't want to use bit numbers for everything!

Vitharix wrote:
comet wrote:

your confusion stems from the fact that there are actually two things called triggers
the one youre talking about is an x/y trigger (coord event). these just run some script when they get stepped on
the commands did get mixed up. updating the compendium would probably make it more confusing

Ah, that sure wasn't helping me. What are the other thing called a trigger?

Script header works so that the First Part of it executes scripts datas based on the trigger number value in ram for the map you just arrive to. It works with the exactly same method as these trigger events placed on the map. Though using it is a bit more complicated since you have to be familiar with its;
1) Structure
2) The fact that it's not "super fast", or better, the Second Part of script header is executed a bit faster and can be used to re-draw graphics on the screen and that kind of stuff before they're displayed in the game. First Part won't be able to do this, but it can be used for the "common business".

Vitharix wrote:

Well I figured it out. Turns out that the codes 37 and 38 don't do what the Compendium says; unless of course I'm missing something.

Yeah, I don't think they work that way either. Another example of false documentation are codes 0A and 0B.
0A is actually "bigger than", while 0B is "smaller than".

Offline

#6 2013-09-25 10:03:06

Tauwasser
Member
Registered: 2010-10-16
Post 407/447

Re: Trigger clarification

Miksy91 wrote:
check if the values in DA00-DA01 (= "Map Bank, Map No. in ram") match with the first two values of any 4-byte entry starting at $94000 (+ keep current table index somewhere safe)
if "match" {
 
 load the value from the ram address that follows the start point of this entry somewhere safe (in other words, loads the value from ram that this Map Bank and  Map No. in the trigger table defines)
 check if this value matches with the flag of the trigger tile that was stepped on
 if "match" {
  start executing script
 }
 else {
  return
 }

}
else {
 return
}

Actually, the game does not work like that. It traverses the table and tries to find the entry. When finding it, it returns de and carry flag reset. When it hits the end of the table without finding the entry, it returns carry flag set. However, most routines do not check the carry flag return value at all. Instead, they will check if de != 0x0000. This will always be the case as de is not preserved inside this routine.

Miksy91 wrote:
Vitharix wrote:

Well I figured it out. Turns out that the codes 37 and 38 don't do what the Compendium says; unless of course I'm missing something.

Yeah, I don't think they work that way either. Another example of false documentation are codes 0A and 0B.
0A is actually "bigger than", while 0B is "smaller than".

Whoops, just checked the game code for these. Guilty on all charges. Though 0x37 and 0x38 are tricky, because they use low-active logic to enable battles >:-|

cYa,

Tauwasser

Last edited by Tauwasser (2013-09-25 10:14:59)

Offline

#7 2013-09-25 18:22:08

Vitharix
Member
Registered: 2011-12-29
Post 327/396

Re: Trigger clarification

Tauwasser wrote:

Though 0x37 and 0x38 are tricky, because they use low-active logic to enable battles

What must one do in order to use them correctly or, is there a more efficient way to accomplish it?

Offline

#8 2013-09-25 19:29:50

Miksy91
Member
Registered: 2010-10-16
Post 1,904/2,308

Re: Trigger clarification

Tauwasser wrote:

Actually, the game does not work like that. It traverses the table and tries to find the entry. When finding it, it returns de and carry flag reset. When it hits the end of the table without finding the entry, it returns carry flag set. However, most routines do not check the carry flag return value at all. Instead, they will check if de != 0x0000. This will always be the case as de is not preserved inside this routine.

That was only my assumption actually. Could have as well mentioned it there.

Tauwasser wrote:

Whoops, just checked the game code for these. Guilty on all charges.

You did a really great job on the compendium otherwise though! If it wasn't for that, my current hack probably wouldn't have gotten started at all.

Offline

#9 2013-09-25 22:47:46

Tauwasser
Member
Registered: 2010-10-16
Post 408/447

Re: Trigger clarification

Vitharix wrote:
Tauwasser wrote:

Though 0x37 and 0x38 are tricky, because they use low-active logic to enable battles

What must one do in order to use them correctly or, is there a more efficient way to accomplish it?

Use 0x38 to disable battles and 0x37 to enable them.

cYa,

Tauwasser

Offline

#10 2013-09-27 01:49:57

Vitharix
Member
Registered: 2011-12-29
Post 331/396

Re: Trigger clarification

Tauwasser wrote:

Use 0x38 to disable battles and 0x37 to enable them.

Thanks for these (and all other in the compendium :p)

Offline

Board footer

Powered by FluxBB