3 replies to this topic

[Aevin]

I'm having a quest-wide problem where f->Vx and f->Vy stop functioning. This happens after my scripts grab ffc's that were formerly used by ghosted enemies. The enemies die, are cleared, then I use something like RunFFCScript() to grab one of the newly-freed ffc's and run a script. Velocity simply won't function for those ffc's anymore. Here's the steps I've taken to troubleshoot:

• Wrote a custom function to clear all Misc and InitD variables before grabbing the ffc
• Verified my ghost.zh setup
• Searched my global script for anything that could be setting ffc positions or velocity on a frame-by-frame basis
• Traced velocity values at multiple different points to ensure they were getting set properly and not cleared by anything
• Manually set x and y values to make sure they weren't getting set to the same position every frame
• Traced the x and y values at various points to ensure they were set correctly
• Traced something to ensure the stationary flag wasn't getting set

The pattern is obvious. I can grab any ffc never used by ghost, and velocity works fine. But if a ghosted enemy dies and I try to use its ffc for something else, velocity stops working, in spite of the fact I can't see any information on the ffc that differs from a "fresh" one. I can't rely on any given ffc I grab for use having functioning velocity anywhere in the quest.

 

Any idea what's going on here?

 

Edit: After a bit more investigation, I've found what's happening, but not why it's happening. The ffc I'm grabbing is getting linked to ffc 1. That is to say, f->Link = 1, which is usually motionless. But why the heck would killing a ghosted enemy result in this happening?

[Aevin]

Here's an update. I found the core of the issue, and it's a zscript bug.

 

ffc->Link uses zero as it's "none" value, where it shouldn't link to any of the ffc's from 1-32. However, setting those values is clamped from 1-32. So, if you try to set f->Link = 0, it will instead set the value to 1. I tested this with several different ffc numbers, and also in a completely different quest.

 

Putting this in the global loop:

 

ffc f = Screen->LoadFFC(14);

Trace(f->Link);

f->Link = 0;

Trace->f->Link;

 

prints this to allegro.log:

 

0,1,1,1 ...

 

ghost.zh, or some other script, is trying to clear the ->Link variable, which makes it permanently stuck above zero.

 

The workaround is to instead link the ffc to itself, by doing something like this:

 

int GetFFCNumber(ffc this){

     for(int i = 1; i <= 32; i++){

          ffc f = Screen->LoadFFC(i);

          if(f == this)

               return i;

     }

}

 

Then, in your ffc script:

this->Link = GetFFCNumber(this);

[Gleeok]

Fixed it. It was just a simple oversight in ZScript.

Thanks for tracing it to ffc-&gt;Link, otherwise it would have been much more difficult to track down.

[Timelord]

I fixed it on my end. It'll be in my next update on Git.