6 replies to this topic

[Mitchfork]

this->Y and this->PosY(), executed inside a combodata script, return incorrect values when on layers other than 0.  It looks like on layer 1 it's 0, on layer 2 it's 176, and on other layers its other arbitrary incorrect values.

 

this->X, this->PosX(), and this->Pos all seem to return correctly.

 

[Mitchfork]

I thought about making a new topic, but it's probably related.  I found that there are many more combodata attributes that are bugged on layers. 

 

D[0] and D[1] do not return correctly, and neither do the Attributes[] fields.  I'm sure there are other variables that are affected by this.

After further testing - the bug description is incorrect here.  It has nothing to do with layers - there are just certain combo positions on screen that return bad values. For example:

 

Tracing D[1] from combo position 100 always returns 0.

Tracing D[1] from combo position 116 returns the correct value.

 

I was testing this out by putting combos on different layers at different combo positions - which is why I thought that this was a layer issue. But moving my test combo around on screen confirms that it's a position issue with multiple combodata fields.

Edited by Mitchfork, 06 February 2021 - 03:11 PM.

[Mitchfork]

....And after repeated testing that's not even consistent.  The "good" and "bad" locations have changed on me - I think there's something pretty weird going on here.

[Timelord]

....And after repeated testing that's not even consistent.  The "good" and "bad" locations have changed on me - I think there's something pretty weird going on here.

 

Please send the scripts in question so that I can see how you are using InitD[], so that I can debug the issue.

 

In the interim, regarding Pos(), PosX(), and PosY(), please try these builds and LMK if they fix things, or if they make anything worse:

 

http://timelord.inso...c-dev/2.55/89P/

[Mitchfork]

Zoria, I'll send you a PM with the quest file and a little write up of which script in particular I'm using to test.  I think I've made some more discoveries that may narrow it down...

 

I'm not actually using combodata->InitD[] as such, I'm just using the settings as input variables to the script as you would normally do.

 

If I completely close ZC, then open up the file, all combos will report their InitD settings correctly.  If I leave the screen or reset using F9, it seems like the values will then reset to 0.  I use F9 a lot in script testing to reload the file... so it seems like this might be a ZC player bug?  I dunno.

 

I can't test out that build currently but I'll try it out as soon as I can.

[Timelord]

Zoria, I'll send you a PM with the quest file and a little write up of which script in particular I'm using to test.  I think I've made some more discoveries that may narrow it down...

 

I'm not actually using combodata->InitD[] as such, I'm just using the settings as input variables to the script as you would normally do.

 

If I completely close ZC, then open up the file, all combos will report their InitD settings correctly.  If I leave the screen or reset using F9, it seems like the values will then reset to 0.  I use F9 a lot in script testing to reload the file... so it seems like this might be a ZC player bug?  I dunno.

 

I can't test out that build currently but I'll try it out as soon as I can.

 

Please do. I have applied patches to fix combodata scripts not properly clearing on quest exit that may have fixed that issue in A87-A89.

[Mitchfork]

Zoria, I tried this in the new build you posted.  It appears that the PosY() bug was fixed, but the variables clearing to 0 on screen exit/reset is still happening.