Linode Critical Maintenance 01/10/2018Phase 1 is complete. There will be a second round once Linode gets a patch. I have updated the forum thread - please see my post here.
Search the Community
Showing results for tags 'error'.
Found 1 result
I ran into a really odd problem while fixing a bug and thought I would share it. If anyone has any insight into the problem, please share because at face value, my observations make no sense and should be impossible. After updating a script running on a plate used for cooking in CB an unexpected constellation of variable values hits the scripts and causes an error. The error wasn't fatal and I've found a way to fix it in the meantime, so there is no acute problem. The unexpected constellation was caused by a local update that set all variables to 0 while a quest it interacts with still carries a value that indicates a fire has been found, which is no longer true when the local variables were set to 0. One way that fixed the problem was to set the quest value to 0 at the same time that the other variables were set to 0, but before I hit on that, I found the following problem. Careful tracing of console feedback isolated the problem to this section of code: Note the line in commented with ";once a fire is found", second from the top. This is the console feedback from a run which involves activating the plate near a fire: So if the line mentioned above is doing what it is supposed to and detecting that CBFindFireQ.rCBFireRef is 0, the three lines immediately below it should run. But instead it is clear that the else clause is running instead. The only conclusion I can draw from this is that if eval( CBFindFireQ.rCBFireRef == 0 ) is failing for some reason. Now with a single change to the line of code commented with "; once a fire is found": I get the following feedback: This shows that IsFormValid == 0 is getting the job done. "The Error - Invalid fire" line is running and the script auto-corrects the problem. The one significant difference between Reference == 0 and Reference IsFormValid == 0 is that the latter will treat a disabled Reference as 0, while a disabled Reference will often still have a FormID which should be picked up if the value is non-zero. But for some unknown reason, the check is failing. In this particular case, IsFormValid works fine for the situation, so I have a solid fix for this problem. My concern is more of a theoretical nature, since I can't explain how Reference == 0 fails and I use it deliberately in other cases. My question for the local experts is how can Reference == 0 be failing when the console feedback reports the value of the Reference to be 0000 0000? EDIT: It occurred to me that the problem could, conceivably, relate to the use of eval. I ran an explicit test just like the first one, except the key line read: if ( CBFindFireQ.rCBFireRef == 0 ); once a fire is found The results were identical with those from the test where eval is present. That rules out eval as the source of the problem and thus pushes it into something in the scripting language or a lower level.