Incomprehensible error -- source?

I have 2 scripts in an onject, both vomiting out the following at apparently random moments.. i cannot consistently create conditions in which it happens.

[CHAT OUTPUT]
System.Reflection.TargetParameterCountException: Number of parameter does not match expected count.
at System.Reflection.Binder.ConvertArgs (System.Reflection.Binder binder, System.Object[] args, System.Reflection.ParameterInfo[] pinfo, System.Globalization.CultureInfo culture) [0x00000]
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000]
at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000]
at LindenLab.SecondLife.LslUserScript.OnEvent (ScriptEvent evt) [0x00000]
at LindenLab.SecondLife.Script.Run (ScriptEvent evt) [0x00000]

[/CHAT OUTPUT]

the only thing in common between the two is an if tree that may be "iffy" XD

the if tree is (in one script) in a listen event, checking to see if the speaker is llGetOwner, pilot or copilot (keys passed in linkmessage

in the other script it is in both a collision event and a sensor, checking the same thing.

the possible iffyness is that the owner could be the pilot or copilot key in question, and the tree looks like this:

  collision(integer numb)
        {
            
            integer i=0;
            
            for (i = 0; i < numb; i++)
            {

            key test=llDetectedKey(i);

            if(test==llGetOwner())
            {
                llSensorRemove();
                llSensorRepeat("","",AGENT,5.6,PI,1.0);
            }

             else if(test==pilot||test==copilot)
            {
                llSensorRemove();
                llSensorRepeat("","",AGENT,5.6,PI,1.0);
                }
        }
        
        }

i suspected for a moment that a NULL_KEY in pilot or copilot might have something to do with it, but... i'm always owner in all cases so far, so the if should never be getting to 2nd branch..

halp?

I'm not 100% sure what would be causing it (as it could depend on part of the script which you've not posted). However, in your llSensorRepeat commands, try setting the key parameter (the 2nd one) to NULL_KEY instead of an empty string.

I would expect that to show up as a compiler error, rather than run-time, but then I haven't been using Mono much.

thanks for that insight! that would be a second thing in common between the two scripts... a null string as wild card in both the listen (1 script) and the sensor (other script). Never was a problem in LSL, had not even occurred to me that it might be in mono.

popping in to make that change now, but who knows how long it'll be before i can confirm or deny... as i said the problem does not seem to come forth from any specific action, in fact the script will work just fine numerous times before this happens, out of nowhere.

we shall see!

thanks again.

This is a Mono bug.

http://jira.secondlife.com/browse/SVC-2975

It's supposedly fixed in 1.25, you might try beating on the scripts on beta to see if, um, nothing happens.

Thank you!!

yes this is definitely my case, and having read the jira i can say how i'm setting it off, too...

linkmessage queue overflowing (vehicle).

so basically nothing i can do until new servercode hits.. though it is an incentive to find a way to direct my linkmessages other than link_set. not easy, as i used the single message to whole set to guarantee synbchronised reactions from multiple links... but good to know it's nothing i'm doing "wrong" per se.

again, thanks!

Another workaround, if the scripts will fit, might be to try running under old LSL for now…