When I first start my script, I can call SkinfoFromVital asking for vitalHealthMax and get a correct answer. However, eventually, the answer coming back is suddenly a not-possible number, eg: 3014. There seems to be some correlation with endurance spells dropping off (or maybe getting cast?).

I have seen this bug for at least a year or so, which points to it having nothing to do with the new Decal or ToD. (I've seen it for a long time, I've just been too lazy to post a bug report. :-) )

I see the problem on multiple computers, on (obviously, since it's been over a year) different versions of Decal, Skunkworks, AC, etc.

Or am I just missing something here? :-)

Thanks.

If you can nail it down to specific repro steps that I can use to duplicate the bug here, that would be great.

Failing that, the next best thing would be a capture file containing an example of the bug in action. Instructions for making a capture file can be found in the Support section of the SkunkWorks docs. Ideally the capture file should be from a short session, just long enough to demonstrate the bug.

I wouldn't necessarily rule out ToD-related issues as a possible cause. A number of new spell types were introduced with ToD, which entailed changes in my spell-tracking code. That was about a year ago now, so that would fit with your observations.

I'll see what I can do about getting better repro steps and/or more information along the lines you specified.

FWIW: I'm am about 100% positive I was seeing this before ToD, so my estimation that it's been a year may be low - maybe it's been two years. :-)

Thanks.

I have a msg capture file and it's a little over 2 and a half meg. :-(

I actually had the problem on one char immediately, but had forgotten to turn on the capture. :-(

I'll zip and email you the file per the instructions in the SW docs.

Sent.

Some more random notes:

*) I'm not sure if the invalid number is always the same when it happens

*) However, once it happens, the script keeps getting the same bad number

*) Once it starts happening, stopping the script and starting it again does not clear the problem

*) Logging off a char, then back on that same char seems to clear the problem

Relogging is the general cure-all for inventory and stat bugs, because it refreshes everything from current server-side info. Restarting your script doesn't reset any state in SkunkWorks itself, just in your script.

I'll take a look at this when I get a chance. It may be a few days as I'm going to be on the road until about mid-week.

I'm not seeing any obviously bogus data here. Buffed max health values range from 154 to 184.

However I'm also noticing that this file doesn't end with an OnEnd3D event. Are you sure this is from a complete session? I.e. you logged out of the game and quit back to Windows before zipping up the capture file?

Well, the values SHOULD have been up to 180-something, but I was getting something over 1,000 back from SkinfoFromVital().

I don't know about that session - maybe I hit F4 as soon as I was seeing the behavior so as not to increase the size of the file. Regardless, I was seeing the "wrong" behavior, so I stopped the capture one way or another.

Unfortunately, it's not just a matter of stopping the capture one way or another. It has to be stopped in such a way that the capture file gets properly flushed to disk, and for that you need a normal logout event, so that the plugin's Terminate method gets called.

It's also possible that my test script isn't checking the same thing your code is checking. If you want to post a sample of the code you're using to check healthMax, I can try using that in my test case to see if that makes a difference.

The pertinent code is quite simple. Here's one of them:

var skMyInfo;
skMyInfo = skapi.SkinfoFromVital( vitalHealthMax );

I then check on skMyInfo.lvlCur to get the max current health and make decisions (eg: whether to play a noise at the user) based on where
skapi.healthCur is.

I''l see about getting another capture where I exit it "more correctly".

Thanks.

I just sent a new capture file. This session was terminated with the script calling logoff() and a normal exit from the "enter" screen. The script was terminated by me hitting the "stop" button on the SW GUI console.

Thanks.

OK, I found the bug (which was indeed a direct result of the code I added for the ToD preorder gems).

Your capture file also demonstrated an unrelated bug in keeping track of fellowship members.

Fixes for both of these will be in the next release, whenever that may be. (I'm kind of tied up right now with a bunch of RL stuff.)

Thanks for putting in the effort to nail this down.

Great news! I'm glad to hear that you were able to nail this down!

I'm eagerly awaiting the next release (whenever that might happen to be). :-)

Thanks!

Fixed in 3.5.491.