Two scripts taking controls = vehicle parameters reset on border crossing

Due to code size limitations, I am forced to split an aircraft's control processing between two scripts. When I have both scripts take control, everything works fine...

Until I go over a sim border. Then the aircraft turns into a brick!

I am only setting vehicle parameters in one script. The other handles only auxiliary things that don't require changing parameters. I would have done this with link messages, but the frequency of control updates would result in a flood of link messages. When that happens, events have a way of not firing, so that isn't feasible.

Huns, are you already using link messages as a method of communication between scripts?

If not, I'd advise you to send the control() parameters via linkMessage. I did something similar once when creating bumper cars for LindenWorld. It worked quite reliably.

However, if you're planning on using link messages to communicate between scripts, don't count on the reliability of sent messages getting through.

Also, if you plan on putting a conditional chain in the control() event, you can put the llMessageLinked() in a conditional only fitting certain constraints, which would lessen the load on the message passing interface.

control(key controller, integer levels, integer edges)
{
    if(edges & levels) // Key pressed
    {
        // Handle here...
    }
    else if(edges & ~levels) // Key released)
    {
        llMessageLinked(llGetLinkNumber(),edges,(string)levels,"HANDLE_CONTROL"); // Send to another script...
    }
    else if(levels) // Key being held down.
    {
        llMessageLinked(llGetLinkNumber(),edges,(string)levels,"HANDLE_CONTROL");
    }
}

How horrible would it be if a control request was dropped? Would it devastate the user, or simply be a minor annoyance? Are you *absolutely* sure it isnt feasable?

Gah. Note to self: Perform link_message() reliability testing this weekend

Uh oh.

Two scripts trying to set vehicle parameters?! I don't know why I didn't consider that scenario when I implemented vehicles, but I missed it.

As currently implemented splitting vehicle behavior between two scripts, or putting two complete vehicle scripts on a single object will result in undefined behavior -- at best merely broken, at worst unstable and chaotic.

This is a bug ==> I agree that ideally the vehicle parameters should be settable from any script, but the current implementation makes that difficult to achieve (I'm going to have to ponder this one).

Andrew,

Setting vehicle parameters from two scripts on the same object IS an issue, but it's NOT what I'm running into here. The problem I'm having right now is that capturing controls from two separate scripts - even if the second one doesn't have a control() event! - hoses the vehicle system on the first script on border crossing.

Script 1:

1. Sets up the vehicle system
   
2. Takes control
   
3. Has a control() event that sets linear and angular motors
   
4. Has a lot of logic that changes vehicle parameters at certain times outside the control() event, such as changing friction timescale, etc. - since this HAS to be done from the same script that sets up the vehicle and changes the motors during use, these things CANNOT be moved to another script
   
5. Is so close to full memory usage that adding a single line of code can cause a stack heap collision
   

Script 2:

1. Performs a lot of auxiliary functions and has some free space to play with
   
2. Takes control
   
3. Has a control() event that DOES NOT interact with the vehicle system in any way, but can initiate a link message that will be acted on by the first script
   

When I do llTakeControls() in Script 2, even if the control() event is commented out, the vehicle will operate normally - but then as soon as it crosses a border, it drops out of the sky, crashes into the ground, and skids around. It seems very likely that this is causing the vehicle parameters to reset. The first script's control() event is still running, as I can tell because it is still sending link messages that only get sent while it's running.

A while ago I tried moving the vehicle setup to one script and having the control() event in the other (again, to free up space), but it looks like each script talks to the vehicle system as a separate entity. So yeah, that IS an issue, and it's one I've been thinking about reporting, but it isn't what is giving me trouble right now. The resetting of the parameters during border crossing is a separate issue, and I think it is probably a bit easier to resolve.


Christopher,

I have found that the probability of an event firing is inversely proportional to how busy a sim is, in terms of object count and presence of avatars. Flooding link messages will decrease the probability that all events, whether related to control (as under your scheme) or not, will fire. It would also put additional load on the script execution system that I would like to avoid if at all possible. I have thought about using conditionals as you have suggested, but in this particular circumstance, the space savings would be negligible.

There is a lot of code in the main control() event. Most of the code blocks here have to change a vehicle parameter, which means they HAVE to live in the same script that does vehicle setup. There is, however, one fairly large block of code that DOES NOT change a vehicle parameter - it just sends link messages if certain very specific control sequences arrive. So it doesn't really need to live in the main vehicle script. Since it's fairly large, it is worth it to me to move it to another script.

Inexplicably, the problem has changed. Now, instead of the aircraft parameters getting reset, the control() event in the first script isn't firing any more. The control() event in the second script still fires though.

edit: I believe the point at which things break is the llTakeControls() that gets called when the run_time_permissions() event fires. If I comment that out, the aircraft doesn't break when I cross a border. (But then the secondary control() event doesn't get called so that isn't really a fix.)

Hmm... I was doing a permissions experiment a few days ago involving automaticly-given permissions.

When your granted permissions automaticly, if you llRequestPermissions() doesnt trigger the run_time_permissions() event. Try relocating the llRequestPermissions() and llTakeControls() outside of the run_time_permissions() event.

Can you rephrase that? I can't parse the first sentence in your second paragraph.

Also why would I have llRequestPermissions() inside the run_time_permissions() event?

Anyway. The problem is not with the granting of permissions, it's with one of the control() events failing to fire *after* the vehicle has crossed a sim. So it *does* raise run_time_permissions(). I know that for sure because I commented that event out of the second script, and it didn't take controls. When it was NOT commented out, it DID take controls.

Anyway, I managed to circumvent my problem by shortening some text messages in my primary control script. That allowed me enough room to move some stuff back in there. But it is only a temporary fix. I want to do something really cool with the flight model but I can't do it the way things are because my code and data segments are too fat.

I really hope this can be addressed soon.

This doesn't have to do with the fact that permissions are only granted in a linked set to either:

a) to the root prim only

or

b) to the first llRequestPermissions() caller

haven't tested which one

??