Just wanted to post a quick note on the news that the Havok™ team has deployed another 11 fixes to 559 Early Adopter regions. Looking at the list of fixes, I don’t see anything that will specifically affect C:SI, though I’m hoping those of you in-world can see if they had any secondary benefits. It’s possible that some of the things regarding energy could be peripherally related to some of the problems we’ve seen.
I also want to take this opportunity to point out for the benefit of those not following the comments to the C:SI Weapons Breaking thread that Darien Caldwell had some insights that, if correct, could mean that the issue is not necessarily related to Havok™ 4 (unless they picked up the problem from base simulator code) :
Something just occurred to me, I have seen a Math Error like this before, when attempting to use llSetColor on a face that didn’t exist. Why this causes a Math Error, I don’t know.
If the issue is occurring when drawing the weapon, perhaps it has to do with the call to llSetAlpha and the face parameter? Or trying to set alpha on a linked prim that doesn’t exist? Some wild guesses.
There was some additional speculation in the comments to that post, and at this point I am beginning to suspect that it’s related to setting alpha on prims with a possible notecard corruption issue as a contributing factor. I have yet to be able to verify that, though, so I’m asking everyone who sees this issue to please report it with :
- The name of the weapon that has the problem (this may turn out to be significant)
- The region you were in
- The time it occurred
- Anything else you think may be relevant.
I won’t be likely to get in-world tonight to test the new Havok™ stuff, but I encourage anyone who notices any problems (or new physics goodness) to report it here or on the Official C:SI Forums.
8 Comments
Hmm, I would be inclined to agree with that as a possibility, but drawing the sword usually causes the entire weapon to appear at once, which isn’t something that would use individual faces or specify specific prims…
It would make sense if it broke while color customizing or the sheath itself when drawing, but I’m confused how that would cause a math error on the weapon itself.
However, on the sheath it only causes certain prims to be hidden or shown. We can’t know whether it’s coming from the weapon or the sheath, because the script error lists “Person Name – Math Error” rather than “Object Name – Math Error”, which is completely asinine.
Yeah the first time I saw the math error robby I was fairly confused myself when it stated “Atrus Westland – Math Error” Felt like the game was ridiculing my mathematical skill. Not that they’re all that great but still, It was completely retarded I thought.
It is a pretty odd choice for any developer to make, I think. I can’t imagine a circumstance where I would have chosen to spit out a debug message that would seem to indicate that the user had a math error, when clearly it’s a scripted object that is having the problem.
I wonder if maybe the error is happening when the execution has entered a system call (or some LSL VM equivalent) and as a result they only know the user but not the script it came from. This is just a wild guess since I have no idea how any of the server code is implemented.
Colin’s last blog post..Go Board Updates
Ok, well I just created a script that divides by zero. When it is sitting on the ground, it says “Object: Math Error”, but when I attach it to myself, it says “Colin Kiernan: Math Error”. In a way doing this makes sense, since if everyone is wearing the same AO, for example, it would be hard to figure out which one was having the error. Ideally, it should probably print out “Colin Kiernan: Object: Math Error”.
Colin’s last blog post..Go Board Updates
I’m sure there must be a reason behind it, but like you, I can only speculate about how the server code works.
Regardless of the reason, it’s a very poor way to handle errors, and I should think that LL devs would do everything they could do to return valid and useful information.
To my way of thinking, even if it’s amazingly difficult to tie the error back to the object (or up the stack, etc), errors are by definition an edge case and would justify the effort.
Hmmm… That kind of, sort of, almost makes sense, Colin.
But still doesn’t tell me anything useful. It’s just a very poorly done error message
I just realized, though, that neither are the C:SI customers who’ve experienced the problem. For instance, they never told me exactly what “my weapon broke” means. Did it quit working? Did it turn blue and refuse to block? Did it fail to draw or sheath? I guess I don’t really know, as they symptoms have yet to be described.