Buffer overrun detected

#1 Can you outline the changes you made?

#2 I actually recieved these errors quite frequently while working with the setTimerOn functions where it expects milliseconds to be passed but the docs state seconds ... as such, I was passing in 0.5 and 0.25 values to get 500ms and 250ms and it would randomly throw run-time errors and complain about Visual C++ ...

this may have nothing to do with Shane's problem, but this seemed an appropriate place to mention it (its been mentioned in another thread as well). I assume the schedule() and setTimerOn() functions are linked in some fashion where setTimerOn calls schedule() so the time parameter is identical, so I believe the docs should be updated to reflect the proper parameter value expected.

#3 On a cube trying to get the jitters out I coded this:

function ablock::onCollision( %srcObj, %dstObj, %srcRef, %dstRef, %time, %normal,%contactCount, %contacts )
{     
   if (%dstObj.getImmovable()==0||%dstObj.class="ground")
      {      
      //%v2=(mAbs(%srcObj.getLinearVelocityY())+mAbs(%srcObj.getLinearVelocityX())+mAbs(%srcObj.getAngularVelocity()))/3;         
      %v2=(mAbs(%srcObj.getLinearVelocityY())+mAbs(%srcObj.getLinearVelocityX()))/2;
      %v2=%v2+mAbs(%srcObj.getAngularVelocity());
      
      if (%v2 < 10)
         {  
         if (%dstObj.getAtRest())
            if (checkrotation(%srcObj.getRotation())==1)
               %srcObj.setAtRest();            
         if (checkrotation(%srcObj.getRotation())==1)
            {            
            %srcObj.setRotation(0);
            %srcObj.setAtRest();
            }
         }
      }

Only change I made was to comment the following %v2 lines and uncomment the top one.
I've since changed them back, but it still does it.

#4 I don't know if it is related to your problem but

if (%dstObj.getImmovable()==0||%dstObj.class="ground")

should rather be

if ( (%dstObj.getImmovable()==0) || ( %dstObj.class [b]$=[/b] "ground") )

#5 Michael, is the additional parenthesis absolutely necessary? I see how the "%dstObj.class="ground"" could cause problems but does TorqueScript require or benefit from the additional parenthesis's you added?

#6 I don't really trust torquescript when it comes to operator precedence. I had some problems with this. The parenthesis may not be necessary but they don't do any harm either.

#7 Michael,

I only asked to a) determine if they were necessary and b) determine if this was just 'your' code style or the way it should be. As you said 'should rather be', anyone new to torquescript who see's this post may think it necessary to use them when it may not be. I am familiar with C, C++, PHP and other C-like langauges where precedence is sometimes an issue and parenthesis are required to guarantee the correct order of precedence, but in an 'OR' statement precedence is not really much of an issue. It's either 'A or B', but 'A or B and C' might require some explicit precedence such as '(A) or (B and C)' or 'A or (B and C)'.

Not trying to knock anything you said, just trying to clarify it.

@Michael, oh and, good catch on the single operator ('='), I just looked at the code quickly and focus'd more on the issue and related it to my millsecond vs second parameter value issue which caused a similiar run-time error.

#8 David,

no problem. I don't feel knocked.

#9 I couldn't find any consistency with the code changes. I commented everything and was still getting the error.. So I just re-installed. So far its working ok again. I also made the changes above, because it was obvious now why the code wasn't running when the boxes were settling on the ground.

Wish I could have been more helpful hunting that bug down. =/

Thanks all,
Shane

#10 Shane,

it seems to me that TorqueScript has a few issues when invalid numerics are entered. Such as for example the milliseconds being passed as a float, I've never successfully worked with fractions of milliseconds in C or C++ before ... so I'll assume TorqueScript doesn't do it very well either. Perhaps your issue was not necessarily with the script code you wrote, but perhaps with script code that the editor created -- ie; you set a value to a float when it doesn't "really" accept floats -- such as perhaps in the collision, physics or scene graph sections of the objects edit. However, this may not be the case since as you said, re-installing did the trick -- *shrug*

#11 Its possible though. I had not backed up all of the correct files when I did an uninstall and so I had to restore from an older level file that I had.