Yet Another Script Problem (YASP)

[Nimono]

Well, this time, it's serious. To protect my plans with the scripts I will show soon, I am going to take out any mentions of the names. :D

These two scripts work in tandem to trigger one effect, but when I open a quest in ZC with them in it, the player freezes before the quest is finished loading.


ffc script -taken out-
{
int Activated = 0;

void run()
{
while(true)
{
while (Activated == 1)
{
Screen->ComboD[176] = 3;
}
}
}
}


import "std.zh"
import "-taken out-.z"
ffc script -taken out again-
{
int Type = 0;
int Piece = 1;
int Weapon = 0;

void run()
{
while(true)
{
if (Type == 0)
{
-taken out-.Activated = 1;
}
else if (Type == 1)
{
Screen->ClearSprites(0);
int ScrnNPCs = Screen->NumNPCs();
if (ScrnNPCs == 0)
{
-taken out-.Activated = 1;
}
}
else if (Type == 3)
{
if (Link->Item[Weapon])
{
-taken out-.Activated = 1;
}
}
}
}
}

Yeah... I have no clue what's wrong. Is it because I try to clear the guys from the screen?

[Saffith]

Offhand, I'd say it's because you have an infinite loop without a Waitframe().

[Nimono]

Offhand, I'd say it's because you have an infinite loop without a Waitframe().

Oh darn, I forgot that. XD I'm too used to item scripts. XD Thanks for telling me that. :)

Edit: Well darn. That fixed the freezing problems, but... Now, whenever the "thing" is triggered, it goes to the wrong location. Okay, help me out here. I want to put a combo at an exact location without using FFCs (Because for some reason, doing it that way completely erases combo type...). I want to put Combo 3 at 96,80. How would I tell the script to look at x-96, y-80?

[Saffith]

I'm not sure I see what you mean... Are you trying to change Screen->ComboD at a particular location? If that's it, it would be Screen->ComboD[ComboAt(96, 80)]=3.

[Nimono]

I'm not sure I see what you mean... Are you trying to change Screen->ComboD at a particular location? If that's it, it would be Screen->ComboD[ComboAt(96, 80)]=3.

Oh. XD I've always wondered how I'd use ComboAt.... XD

Edit: It works, but there's a problem- The Combo Type refuses to work. :(

[Saffith]

What type of combo is it you're changing it to?

[Nimono]

What type of combo is it you're changing it to?

Stairs. If I change it using a variable that isn't a loaded FFC, the combo type works. If I use a variable with a loaded FFC, the combo type doesn't work. It doesn't work here, either, and this is in build 240!

[Saffith]

So Screen->ComboD[x]=3 works, but Screen->ComboD[x]=ffcPtr->Data doesn't? Is that what you're saying?

[Nimono]

So Screen->ComboD[x]=3 works, but Screen->ComboD[x]=ffcPtr->Data doesn't? Is that what you're saying?

Huh? No, let me explain...

Before, I tried to make a variable be equal to "(96)&(80)", and that would put it at the wrong spot. When I did that, the stairs worked.

If I did "ffc varaible_here = Screen->LoadFFC(32)", I had to put the FFC's X and Y positions into one variables, so I'd do "variable_Here = (FFC->Y & 240)+(FFC->X>>4)", which is supposed to attach it to a specific combo location instead of by pixels (or so I was told). Then, when putting THAT variable into the ComboD line, it acts like I put the combo on Layer 1.... Meaning, the combo type gets completely erased!

Not even your version of doing it worked. :(

[Saffith]

Hm... Okay, what are you changing it from, then?
And when you say it doesn't work, you mean you can walk over the stairs and they just don't warp you anywhere?

[Nimono]

Hm... Okay, what are you changing it from, then?
And when you say it doesn't work, you mean you can walk over the stairs and they just don't warp you anywhere?

What do you mean, what am I changing it from?

And yes, I can walk over the stairs and they won't warp me. Cancel Warp was NOT set on the screen's Tile Warps.

[Saffith]

I mean, what sort of combo is there before you place the stairs?
Is the old combo type still in effect afterward?
And if you change it, does it make any difference?

I'm just trying to think of some reason this might be happening, and I haven't been able to reproduce it myself.

Edit: Wait, now I'm seeing it. Hm, that's definitely not right.

Edit again: Okay, try moving the FFC after you place the stairs. It seems like it might be blocking them somehow.
Yeah, something's definitely not working right here.

[Nimono]

I mean, what sort of combo is there before you place the stairs?
Is the old combo type still in effect afterward?
And if you change it, does it make any difference?

I'm just trying to think of some reason this might be happening, and I haven't been able to reproduce it myself.

Edit: Wait, now I'm seeing it. Hm, that's definitely not right.

Edit again: Okay, try moving the FFC after you place the stairs. It seems like it might be blocking them somehow.
Yeah, something's definitely not working right here.

Okay, I'll try that. ...Yep, that was the problem. By the way, in the second FFC script I showed, for some reason, the check for the enemies isn't working right. It'll activate whether there are any enemies on the screen or not. =/ And by the way, I took out the ClearSprites() part because it deleted all enemies on-screen... (I forgot that enemies count as NPCs....)

[Saffith]

Now that I think about it, it's probably supposed to block the stairs like that. Need it to do that sort of thing for moving platforms and such. Still, it's failing to get the FFC's position properly for some reason...
For the enemies thing, try using Trace() to check the value of Screen->NumNPCs(). Be sure it's what you think it is. Also, make sure it's actually being activated where you think, since it looks like there's more than one way it can happen.

[Nimono]

Now that I think about it, it's probably supposed to block the stairs like that. Need it to do that sort of thing for moving platforms and such. Still, it's failing to get the FFC's position properly for some reason...
For the enemies thing, try using Trace() to check the value of Screen->NumNPCs(). Be sure it's what you think it is. Also, make sure it's actually being activated where you think, since it looks like there's more than one way it can happen.

Okay, I have NO clue how to work Trace(); ..... Mind helping me out?

[Saffith]

Just give it a number and it'll record it in allegro.log when it executes.
So if you put Trace(5); in your code, it'll put "5.0000" in allegro.log whenever it runs that line.
Since you can only trace numbers, be sure to use distinctive ones to mark what's what.

[Nimono]

Just give it a number and it'll record it in allegro.log when it executes.
So if you put Trace(5); in your code, it'll put "5.0000" in allegro.log whenever it runs that line.
Since you can only trace numbers, be sure to use distinctive ones to mark what's what.

You can't trace variables? Because I traced "ScrnNPCs" to find out what it's becoming, but.... Nothing. I can't seem to find it. :(

[Saffith]

If you see nothing at all, it'd be a good idea to trace some other things to be sure it's doing what you think it's doing.
If, for example, you have this:

if (condition)
{
int ScrnNPCs = Screen->NumNPCs();
Trace(ScrnNPCs);
// ...
}
else
{
// ...
}
... You might try this instead:

if (condition)
{
int ScrnNPCs = Screen->NumNPCs();
Trace(1111);
Trace(ScrnNPCs);
// ...
}
else
{
Trace(2222);
// ...
}

[Nimono]

If you see nothing at all, it'd be a good idea to trace some other things to be sure it's doing what you think it's doing.
If, for example, you have this:

if (condition)
{
int ScrnNPCs = Screen->NumNPCs();
Trace(ScrnNPCs);
// ...
}
else
{
// ...
}
... You might try this instead:

if (condition)
{
int ScrnNPCs = Screen->NumNPCs();
Trace(1111);
Trace(ScrnNPCs);
// ...
}
else
{
Trace(2222);
// ...
}

I tried doing another Trace (Using "2101", since I'm REALLY into AYB stuff now. XD), but... It never appeared in Allegro.log. Here's the output:

SETV d2,0
SETR d3,REFFFC
PUSHR d3
PUSHR d2
SETR d4,SP
SETV d2,0
SETV d2,0.0001
COMPAREV d2,0
GOTOTRUE 133
SETR d2,gd2
PUSHR d2
SETV d2,0
POP d3
COMPARER d2,d3
GOTOTRUE 18
SETV d2,0
GOTO 19
SETV d2,0.0001
SETV d3,0
COMPAREV d2,0
GOTOTRUE 30
SETV d2,1
SETR gd1,d2
PUSHR d4
SETV d2,28
PUSHR d2
GOTO 137
POP d4
GOTO 126
SETV d3,0
SETR d2,gd2
PUSHR d2
SETV d2,1
POP d3
COMPARER d2,d3
GOTOTRUE 39
SETV d2,0
GOTO 40
SETV d2,0.0001
SETV d3,0
COMPAREV d2,0
GOTOTRUE 92
PUSHR d4
SETV d2,49
PUSHR d2
SETR d2,gd0
PUSHR d2
GOTO 150
POP d4
SETR d6,d4
ADDV d6,1
STOREI d2,d6
PUSHR d4
SETV d2,59
PUSHR d2
SETV d2,2101
PUSHR d2
GOTO 140
POP d4
PUSHR d4
SETV d2,68
PUSHR d2
SETR d6,d4
ADDV d6,1
LOADI d2,d6
PUSHR d2
GOTO 140
POP d4
SETR d6,d4
ADDV d6,1
LOADI d2,d6
PUSHR d2
SETV d2,0
POP d3
COMPARER d2,d3
GOTOTRUE 79
SETV d2,0
GOTO 80
SETV d2,0.0001
SETV d3,0
COMPAREV d2,0
GOTOTRUE 90
SETV d2,1
SETR gd1,d2
PUSHR d4
SETV d2,89
PUSHR d2
GOTO 137
POP d4
SETV d2,0
GOTO 125
SETV d3,0
SETR d2,gd2
PUSHR d2
SETV d2,3
POP d3
COMPARER d2,d3
GOTOTRUE 101
SETV d2,0
GOTO 102
SETV d2,0.0001
SETV d3,0
COMPAREV d2,0
GOTOTRUE 124
PUSHR d4
SETV d2,113
PUSHR d2
SETR d2,gd0
PUSHR d2
SETR d2,gd4
PUSHR d2
GOTO 144
POP d4
COMPAREV d2,0
GOTOTRUE 123
SETV d2,1
SETR gd1,d2
PUSHR d4
SETV d2,122
PUSHR d2
GOTO 137
POP d4
SETV d2,0
SETV d2,0
SETV d3,0
SETV d3,0
PUSHR d4
SETV d2,131
PUSHR d2
GOTO 137
POP d4
GOTO 6
SETV d2,0
SETV d3,0
POP d3
QUIT
WAITFRAME
POP d3
GOTOR d3
POP d3
TRACER d3
POP d3
GOTOR d3
POP d0
POP d3
SETR d5,d3
SETR d2,LINKITEMD
POP d3
GOTOR d3
POP d3
SETR d5,d3
SETR d2,NPCCOUNT
POP d3
GOTOR d3

Please note that for some reason, the NPCCOUNT thing seems to happen AFTER a check for a certain inventory item in Link's inventory.... What's up with that?

[Saffith]

Wait... Are you not running the script in the game before looking for the output? 'Cause you have to do that first.

[Nimono]

Wait... Are you not running the script in the game before looking for the output? 'Cause you have to do that first.

Wait, I have to do that? Last time I tried that, I could've sworn there was no output whatsoever....

Edit: Nope, no output whatsoever. Would you like to see the allegro.log?

[Saffith]

Sorry, been busy lately... :p
Try putting a Trace() as the very first statement in run(), where it can't possibly miss it. If that doesn't give you something, it must be unable to write to the file properly for some reason.

[Nimono]

Sorry, been busy lately... :p
Try putting a Trace() as the very first statement in run(), where it can't possibly miss it. If that doesn't give you something, it must be unable to write to the file properly for some reason.

I think I got it to work once, but... It gave me a lot of numbers that made no sense....

Edit: By the way, do you happen to know how to correctly work the functions "Link->Warp" and "Link->PitWarp"? Every time I use the latter, nothing really happens when it's called. :( Take a look at this excerpt of code from my Harp of Ages script:


else if (Link->Item[ID2])
{
if (CurMap == 2 || CurMap == 4 || CurMap == 6 || CurMap == 8 || CurMap == 10)
{
Time = 0;
Link->PitWarp(WrpDMap2, WrpScrn2);
Quit();
}
else if (CurMap == 1 || CurMap == 3 || CurMap == 5 || CurMap == 7 || CurMap == 9)
{
Time = 1;
}
}
If he has item x, this code will warp Link to a certain dmap (The "WrpScrn2" is always the same screen number Link is on), but for some reason, it never really does anything... See, I put all the code for all 3 tunes from OoA into this one script, for ease, but... Could that be the problem? Or is it, for some reason, checking for ALL the maps there?

[Saffith]

I think I got it to work once, but... It gave me a lot of numbers that made no sense....How do you mean? They just weren't what you expected, or they literally couldn't have been generated by the script?


Edit: By the way, do you happen to know how to correctly work the functions "Link->Warp" and "Link->PitWarp"? Every time I use the latter, nothing really happens when it's called. :(Hm. They should work just about the same way. If one works and the other doesn't, I'm inclined to think it's a bug.
I've been meaning to start looking at the compiler stuff. I suppose I'll look into it if DD doesn't beat me to it.

[Nimono]

How do you mean? They just weren't what you expected, or they literally couldn't have been generated by the script?

Hm. They should work just about the same way. If one works and the other doesn't, I'm inclined to think it's a bug.
I've been meaning to start looking at the compiler stuff. I suppose I'll look into it if DD doesn't beat me to it.

1: They were a lot of numbers that were usually things like "0.000000001" and then all these seemingly-random numbers placed to tell what that stupid number's value was....

2: Yeah, the code for the Tune of Currents part of the script is basically the same as the code for the Tune of Ages part. Neither work. Only the "Tune of Echoes" part works, because it changes a certain combo (And I also have to MOVE the FFC at its location because of the bug I was told about with FFCs. ;) )... Or, maybe I'm using the wrong items.....

[Saffith]

1: They were a lot of numbers that were usually things like "0.000000001" and then all these seemingly-random numbers placed to tell what that stupid number's value was....I'm still not quite certain I see what you mean... Can you give a specific example of this?

[Nimono]

I'm still not quite certain I see what you mean... Can you give a specific example of this?

*sigh* Okay, the stuff is still in the allegro.log file...

Decrypting...okay.
Opening...okay.
Reading Header...okay.
Reading Rules...okay.
Reading Strings...okay.
Reading Doors...okay.
Reading DMaps...okay.
Reading Misc. Data...okay.
Reading Misc. Colors...okay.
Reading Game Icons...okay.
Reading Items...okay.
Reading Weapons...okay.
Reading Maps...okay.
Reading Combos...okay.
Reading Combo Aliases...okay.
Reading Color Data...okay.
Reading Tiles...okay.
Reading MIDIs...okay.
Reading Cheat Codes...okay.
Reading Init. Data...okay.
Reading Custom Guy Data...okay.
Reading Custom Link Sprite Data...okay.
Reading Custom Subscreen Data...okay.
Reading FF Script Data...okay.
Reading SFX Data...okay.
Done.
128 83 0
128 83
128 83 0
128 83
128 83 0
128 83
128 83 0
128 83
128 83 0
128 83
128 83 0
128 83
128 83 0
128 83
128 83 0
128 84
128 84 0
128 84
128 84 0
128 84
128 84 0
128 84
128 84 0
128 84
128 84 0
128 84
128 84 0
128 84
128 84 0
128 84
128 84 0
128 84
128 84 0
128 85
128 85 0
128 85
128 85 0
128 85
128 85 0
128 85
128 85 0
128 85
128 85 0
128 85
128 85 0
128 85
128 85 0
128 86
128 86 0
128 86
128 86 0
128 86
128 86 0
128 86
128 86 0
128 86
128 86 0
128 87
128 87 0
128 87
128 87 0
128 87
128 87 0
128 87
128 87 0
128 88
128 88 0
128 88
128 88 0
128 88
128 88 0
128 88
128 88 0
128 89
128 89 0
128 89
128 89 0
128 89
128 89 0
128 89
128 89 0
128 90
128 90 0
128 90
128 90 0
128 90
128 90 0
128 91
128 91 0
128 91
128 91 0
128 91
128 91 0
128 91
128 91 0
128 92
128 92 0

It's basically a lot of that with increasing numbers...

Edit: Which eventually start becoming random...

[Saffith]

Ah, that? That's not from Trace(). It's just some debugging stuff in the current build.

Trace() will only print one number on each line, and it will always be to four decimal places.

[Nimono]

Ah, that? That's not from Trace(). It's just some debugging stuff in the current build.

Trace() will only print one number on each line, and it will always be to four decimal places.

Well then, Trace() is broken, since it's not giving me ANYTHING.

Oh, what about my other problem? I tried changing the item required to use the "Tune of Currents" effect, but the effect STILL doesn't happen. :(

[Saffith]

Well then, Trace() is broken, since it's not giving me ANYTHING.Just to be sure, you have tried putting a call to Trace() somewhere where it can't possibly be missed (like as the first statement in run()) to be absolutely certain whether it works, right?
The thing is, I haven't heard of any problems with it before, and I haven't seen any myself. If you're the only one it's not working for, well, I'm having trouble thinking of a reason that might be.


Oh, what about my other problem? I tried changing the item required to use the "Tune of Currents" effect, but the effect STILL doesn't happen. :(Isn't that the one that works with Link->Warp() but not Link->PitWarp()?
If that's the one, I really think it must just be a bug, or else the function simply hasn't been implemented yet.

[DarkDragon]

Ah, that? That's not from Trace(). It's just some debugging stuff in the current build.



Ouch, that's probably my fault. I'll try to remove it from the next build.

[Nimono]

Just to be sure, you have tried putting a call to Trace() somewhere where it can't possibly be missed (like as the first statement in run()) to be absolutely certain whether it works, right?
The thing is, I haven't heard of any problems with it before, and I haven't seen any myself. If you're the only one it's not working for, well, I'm having trouble thinking of a reason that might be.

Huh? Oh. I put it in the enemy call..... XD

Isn't that the one that works with Link->Warp() but not Link->PitWarp()?
If that's the one, I really think it must just be a bug, or else the function simply hasn't been implemented yet.

I haven't tried Link->Warp() yet...

My responses are in bold.

[DarkDragon]

Are you sure Type is being set to 1 like you think it is? In the code you've posted, Type is set to 0 and then isn't changed anywhere.

[Nimono]

Are you sure Type is being set to 1 like you think it is? In the code you've posted, Type is set to 0 and then isn't changed anywhere.

Yes- I change it in the compiler. And I just now tested it in build 240 (The last one I tested it in, I have a test quest in it.)- It STILL works wrong. Maybe it falters when I change screens?