Screen->D[], Reset values when Link enters screen?

[ScaryBinary]

I was trying to keep track of how many times Link uses a certain weapon on a screen. I thought I could just increment a value and store it in the Screen->D[] array...that part of the process works fine.

The issue I have is that Screen->D[] seems to be "global" in the sense that if Link leaves the screen and then returns to it later, the Screen->D[] values are maintained (they're not ever cleared). I need to start my counter from 0 each time Link enters the screen. So for instance, Link enters the screen and uses his sword 4 times --- my counter would be 4. If he leaves the screen and then returns to that screen, the counter starts over at 0, so the first time he uses his sword on that visit, the counter gets incremented to 1.

I think I could achieve what I need by having an FFC script reset the D[] values, but that means I have to have an FFC on every screen, just to reset a counter.

Any ideas on how I might accomplish this without having to put a FFC on every screen? Is there some "event" I can key off of to tell when Link has entered or exited the screen?

[DarkDragon]

Nope, not currently. What exactly are you trying to model?

[ScaryBinary]

It's a secret. :tongue:

I have a custom weapon that, for reasons I won't divulge at the moment, needs to do something special the first time it's used on the screen. If Link leaves the screen and comes back, then the weapon should do it's special thing again, but again only on the first time it's used.

I originally had my item script checking a Screen->D[] value, but then I found out that these don't get reset when the screen is re-entered.

[C-Dawg]

It's a secret. :tongue:
I have a custom weapon that, for reasons I won't divulge at the moment, needs to do something special the first time it's used on the screen.


OHBOYABIGSECRETDONTTELLANYONESHHH.

Anyway.



If Link leaves the screen and comes back, then the weapon should do it's special thing again, but again only on the first time it's used.
I originally had my item script checking a Screen->D[] value, but then I found out that these don't get reset when the screen is re-entered.

You could use global variables. As I understand it, you want Link's first use of the item to "activate" something on the screen, then when Link comes back, the something "goes off." Well, if you're comfortable limiting the total number of active screens to something reasonable (like, say, no more than 3 screens waiting to be triggered) just set up two global variables for each screen: map_trigger_set1, screen_triggerset1. Then just load up the current map and screen here when Link uses the item. To prevent the trigger from going off right away, monitor Link's location (via checking map and screen number he's on) and don't let the set triggers go off until Link has moved away.

If you want an unlimited number of screens, wait for me to get array functions working (or make them yourself using the data in a spare map).

[beefster09]

What I did for my Dominion Rod script was I hid that data in a dummy FFC. It should be enough for just using one variable, you just can't ever use that FFC at any time.
I would have released it yesterday, but I still didn't get help on my psuedo-solidity.

[ScaryBinary]

What I did for my Dominion Rod script was I hid that data in a dummy FFC. It should be enough for just using one variable, you just can't ever use that FFC at any time.

Yeah, I was thinking about that, too, but the drawback is that my weapon could be used anywhere, which means I have to reserve an FFC on every screen in the game. Is that what you did? Or is there a more efficient use of FFCs that I'm missing?

I think I can do what I want using the combination of a global script (assigned to Slot 2) and the weapon's item script...without using the FFCs. But I'm not sure yet. I need to play around with my idea more.

[Nimono]

It's actually QUITE simple. Do what I did for my Cane of Somaria script: When it's activated, store the current map and screen to some variables. When it loops back, it checks if said variables are equal to the current map and screen. If not, just reset the variable back to normal! Trust me, it'll work. ;) (How do you think I made sure that it didn't think there was a block already on-screen when you leave screens after using the Cane once? :P)

[ScaryBinary]

It's actually QUITE simple. Do what I did for my Cane of Somaria script: When it's activated, store the current map and screen to some variables. When it loops back, it checks if said variables are equal to the current map and screen. If not, just reset the variable back to normal! Trust me, it'll work. ;) (How do you think I made sure that it didn't think there was a block already on-screen when you leave screens after using the Cane once? :P)

I thought of that, too, but I believe it will fail if Link leaves the screen and returns without using the weapon on a different screen.

Or are you talking about using a global script to do the looping/resetting, with the item script being the one that stores the map and screen values? That's what I was thinking in my post above.

At any rate, I'll go check out your script to see what you did!

--- EDIT ---
Just checked out your Cane of Somaria script. Looks like it's what I need to do. Thanks!

[Praethus]

Can't you just set all the D[] values to 0 whenever link enters a new screen?

[ScaryBinary]

Can't you just set all the D[] values to 0 whenever link enters a new screen?

That's essentially what we're doing. My initial issue (after discovering that D[] didn't reset itself automatically) was I couldn't find an "easy" way to tell when Link entered a new screen or left the old one. There isn't a "Link is leaving the screen" event or a "Link is entering the screen" event to attach a script to. But as pikaguy900 did in his scripts, you can use a constantly-running global script to monitor Link's location (his current location and his last known location), then reset the screen variables when he transitions from one screen to the next (by comparing the current location with the last known one).