Split code on several scripts, good practice?

[Voodoo Radek]

Short question: There is any difference in terms of performance to have all the code on a single script, or split it in several?

Background: I am designing a car. I am not still on the scripting stage, but this question just occurred to me. I am wondering if everytime i cross a sim all the script have to be recompiled, getting more delay with more scripts, even if they have less code.

I have a reason to split the code in several scripts. I want to make a car with great details and functionality (functional steering wheel, wipers, damage, belts, speed meter, RPM meter, gear lever, hand brake etc). I am conscious that this could carry more delay while crossing sims, so i was thinking about include function to kill all the bells and whistles when i want to use the car on mainland. That would be easier with fragments of code, but i am not sure if that could worsen the performance if i have all the scripts running.

[Voodoo Radek]

Short question: There is any difference in terms of performance to have all the code on a single script, or split it in several?

Background: I am designing a car. I am not still on the scripting stage, but this question just occurred to me. I am wondering if everytime i cross a sim all the script have to be recompiled, getting more delay with more scripts, even if they have less code.

I have a reason to split the code in several scripts. I want to make a car with great details and functionality (functional steering wheel, wipers, damage, belts, speed meter, RPM meter, gear lever, hand brake etc). I am conscious that this could carry more delay while crossing sims, so i was thinking about include function to kill all the bells and whistles when i want to use the car on mainland. That would be easier with fragments of code, but i am not sure if that could worsen the performance if i have all the scripts running.

[Paul Hexem]

Unless the scripts are using a TON of memory (lots of custom functions, lots of stored variables, long lists, etc), you almost always want to put everything into one script.

 

Besides that, from what I understand, even when a script isn't running, it's still using memory and the sim crossing still has to process it.

[Innula Zenovka]

I would always try to keep everything in one script unless there's a really convincing argument not to.   Others know more about vehicles and sim crossings than do I, but my understanding is certainly that the more scripts in the object, regardless of their size or what they're doing, the worse the crossing is likely to be (and the greater the impact on sims as you leave and enter them).

All that besides, it makes things so much easier to maintain, I find, and, from my own point of view, now that we've got things like llLinkParticleSystem and llSetLinkPrimitiveParamsFast, and new parameters like PRIM_OMEGA,  I would certainly find it easier to script something that controls all the bells and whistles directly from the one script rather than sending link messages all over the place. 

[Yingzi Xue]

There are a few instances where multiple scripts would be beneficial...

• If you have plans for your script to grow over time; additional functionality/features.
• Ease of support; separating code into smaller pieces makes editing it easier, especially if you have long-term products that grow over time.
• Functionality that pauses the main script, like e-mail and instant message.
• Compartmentalization/modulization of functionality, so that a script can be added or taken away for additional features.

The down side of multiple scripts is that each container (either 16k or 64k) also takes up a bit of memory on top of its container size.  Yes, it's small, but it adds up.  Keep in mind, 16k containers take full 16k no matter the size of your script.  64k containers scale according to the actual memory used in the container.

In 2008, I noticed some popular vendor objects had upwards of 10 scripts in them.  Multiply that by 100 vendor objects and you have 1000 scripts in a region.  10 scripts in any object is insane and overkill.

In a few of my own products, many of which have been long lasting and have grown over the years, I've had to offload functionality to a slave script just to be able to fit everything.  I even moved the notecard reader to a separate script to free up some more memory in the main.

Rarely do I use more than one script, only if necessary.  When a project gets so big that you have no choice then there's nothing you can do but offload to a second script.  What I've learned is that if you're designing a project and you know it's going to be big, the best bet is multiple scripts and compartmentalization.  It makes it much easier to come back to after a year or two of not looking at the code.  That said, if your project is way less than 64k, there's really no reason for multiple scripts (excluding the need for scripts in child prims, of course... but use link functions when available to prevent the need for child prim scripts).  As for sim crossings... the more scripts a sim has to poll, the more lag, which will vary depending on script efficiency in the sim you're arriving and various other factors.

[steph Arnott]

I tend to start with several dedicated scripts then as I develop them and my knowledge merge them. I not a programmer so I have to get them working first also I may have one for doing stuff because of throttles.

[Poenald Palen]

Ah, lag is the issue.

EDIT: Sim crossings benifit from the reduction of attachments and I beleive contents load or have to be tracked. The one thing that makes the one script for everything rule sort of break is that you can delete scripts from a script. So, you main script may use a script and delete it if it was temporary, for instance a "Make low lag" button may trip a warning (or send them a copy of the item form inventory, wow a whole car in it's own inventory but maybe UUID may work? beware of perms on this because I don't remember what happens with that part lol) and...forgot what I was saying. Yeah, you can delete scripts after setting the color and all the neato options OR kill the animation bits. This would make a smaller script that is running BUT this spawns a new question I forgot to ask: Is a script with lower kb memory going to cross faster than one with more, also considering less events are listed in the script?

Because you can turn off animations and the parts where it tracks stuff by making a whole entire state change to a lower lag vehicle script within your script, one that executes only what is needed BUT the trade off is a bigger script memory usage wise...so, another question and a few tips that may help

I will share a few (off the top of my head) things that I have noted to do to improve my next gen or vehicles and multiple scripts can be easy to manage and load, makes sense if you are older school BUT there are new functions in LSL that allow you to change prims params from the main prim.

So, one tip (because I am rusty, this is what I am doing lol AND if you are new it may help as well with dreaming up possabillities) is to explore the LSL functions, note the little icons to indicate what is new and what may be a feature that is proposed OR depricated ect: http://wiki.secondlife.com/wiki/Category:LSL_Functions

The wiki also has some efficiency stuff, so you can get more stuff in without bloating the car and ruining the user experience:

http://wiki.secondlife.com/wiki/Good_Building_Practices

http://wiki.secondlife.com/wiki/LSL_Script_Efficiency

Also, breaking out some stuff and putting it into a HUD may help. Paint job textures may be the best example, but is the first one that comes to mind. The user chooses when to attache it, when they choose the paint it sends the UUID's to the car. You can use UUID's for sounds I think, or maybe it was that you can't .....see, I just use the wiki to check stuff because it is not worth it to memorize lsl to me lol. But, either way, you can see this stuff in various different places.

I remember that keeping timers above 5 seconds, closing listens (you put it in variable and true false it BUT easier said than to type the few lines of code it takes and explain why LSL has it done this way lol, so to the wiki to learn that one. One issue is that if you use a HUD you might want to leave it open.

A good thing might be to shut a script off (you can do that) OR even delete it after it is needed AND you can even use a system pin or whatever thingy majic method they have to LOAD a script and use it when the car is, lets say parked in a garage or at a station or area. This loading by specific call works for rezzers I think, because mono will share some resources for multiple instances of the same script in different vehicles (or it used to, this is from like 3-5 years ago lol) so...yeah, there are some interesting things you can find around on the wiki and learning about the script. Just look up functions to do with loading scripts, because you may be able to load it while you need it, delete it and then carry on (mostly this may work for paint, riims (load them via UUID swap for instance, which is laggy to use as animation BUT a one time use or once in a while? not to bad at all) and...yeah, I am rambling but this stuff is maybe useful so I will leave it.

It may take hours, but there are some interesting tricks to be found reading up on those functions. prim link parameters are one place to start, but then again texture animations may work as well and the neat trick with multiple mesh parts being made visable is really neat, all the info in the wiki there.

[Voodoo Radek]

Thanks for answering guys!

---

Innula Zenovka wrote:

I would always try to keep everything in one script unless there's a really convincing argument not to.   Others know more about vehicles and sim crossings than do I, but my understanding is certainly that the more scripts in the object, regardless of their size or what they're doing, the worse the crossing is likely to be (and the greater the impact on sims as you leave and enter them).

My only arguments to do this way, is that on my not very extensive SL scripting adventure i have gotten used to that; this is, programming small functions on each child prim. This is not a very convincing argument, nor the more efficient way to go, so i want to try to learn to command child prims with a single script this time.

The other one is that i think it would be a good idea be able to kill the unnecessary functionalities in laggy circumstances, or if need to cross sims, because i have also experienced that each script, complex or not, delay crossing or even crash you.

I think the best way to make it will be to make two separate modules with at least two scripts, one for the basic car functionality (physics, sound, particles) and other/s with the extra functionality.. And add a function in the main that let me get ride of the extra script. If i were able to program in a efficient way that option would be no needed, but i am not confident with my programming skills, so i think that's my best option as i want to cross sim as naked as possible :].

---

Yingzi Xue wrote:

That said, if your project is way less than 64k, there's really no reason for multiple scripts (excluding the need for scripts in child prims, of course... but use link functions when available to prevent the need for child prim scripts).

I am gonna need to control a lot of child prims, and my experience with llSetLinkPrimitiveParamsFast is not that extensive. Let's see if i can handle this.

---

Poenald Palen wrote:

I will share a few (off the top of my head) things that I have noted to do to improve my next gen or vehicles and multiple scripts can be easy to manage and load, makes sense if you are older school BUT there are new functions in LSL that allow you to change prims params from the main prim.

I don't work with LSL often, but i like to check out new functions from time to time. I cannot wait for the new ribbon particle for skids ;]. I also knew about the good building practices, it's helping me a lot to build good LoD and Physics configuration for my model. I will have to take a look to the LSL script efficiency. That method to load a script also catched my eye.

[steph Arnott]

OK, i am out of my depth here so i leave you all to it.

[revochen Mayne]

Greetings! 

 

I almost tend to keep scripts separated and modulary, dependng on its purpose and figured its good to do so on complex system. So i have a script for the menu, another for the vehicle including user input, maybe another for shared functions like float text, sound or particles and so on. That way you will have a few small scripts with less code instead of one single script with hundred lines of code, duzends of events and maybe also a few different states (which is quite annoying when you have a timer and need it to handle different tasks).

I also figured that those scripts may run smoother, especially if you need to run different tasks simultanously and LSL doesnt support multi-threading as its a procedural programming language. Just think about sending an email via llEmail which has a delay of 20 seconds and will freeze your script for that time. So no user input or other task may process then and it makes much sense to out-source this function into a separate script and use communication via llMessageLinked for data exchange if necessary.  

[PeterCanessa Oh]

The fewer scripts the better.  For modular development use an external editor that lets you 'include' several functions into a single script.  You do, however, have to consider several use-cases; for instance:

• The necessary driving functions - steering, speedometer, rev-meter, gears, brakes, etc.  Keep them all together in an "Engine on" script.  Yeah, so some of them aren't really necessary but this is how you make your cars stand out from the crowd.  Indulge yourself and your customers a bit, you want your cars to be great :-)
• Bells and whistles - seat belts, wipers, horn, damage, etc.  Consider splitting to an optional 'Extras' script that people can choose to use if they have no problems with sim crossings or to delete if they do.
• Engine off - repainting/styling, engine mods, etc. that in RL wouldn't be done while driving.  Split out to a 'Workshop' script.  Even include a Workshop object to futher improve the 'customer experience' for your vehicles.  (NB: when using this script there's no issue with sim crossings and all that because they aren't going anywhere!)

 

[LepreKhaun]

---

Voodoo Radek wrote:

...

I think the best way to make it will be to make two separate modules with at least two scripts, one for the basic car functionality (physics, sound, particles) and other/s with the extra functionality.. And add a function in the main that let me get ride of the extra script. If 

i were able to program in a efficient way that option would be no needed, but i am not confident with my programming skills, so i think that's my best option as i want to cross sim as naked as possible :].

...

---

If you were going with just two scripts, a main vehicle script and a secondary "bells & whistles" one, you might get by with judicious use of llSetScriptState() https://wiki.secondlife.com/wiki/LlSetScriptState .

 

The caveat with that approach though is losing state within the secondary script with the first sim crossing. In other words, it'll be reset to square one when it's restarted again. If that isn't a problem though (and I don't see why it should be), that would be the approach to explore.

[Innula Zenovka]

---

Voodoo Radek wrote:

I am gonna need to control a lot of child prims, and my experience with

llSetLinkPrimitiveParamsFast is not that extensive.

 Let's see if i can handle this.

---

You will find plenty of people here very willing to help you with this. That's what the forum is for.

[Qie Niangao]

I quite like Peter's suggestion of a kind of "garage" or "pit stop" script that does all the administrative/configuration functions on the vehicle that have nothing to do with real operation. (Unfortunately, many SL users have the absurdly immersion-killing habit of repainting and reconfiguring their vehicles on the side of the road, so it may take some customer "re-education" to adjust their expectations about this.)

Otherwise, yeah, for anything that crosses sim borders, keep the script count to the absolute minimum. It may help slightly to set script state to not running, as LepreKhaun suggests, but I'm not 100% sure what gets transferred between sims when a script isn't running... perhaps nothing more than an asset handle, inasmuch as no state is preserved. (See in particular an ex-Linden's comment to SVC-26.)

One other script-count problem that often arises for vehicles in particular is the lack of any -LinkSound() function, so if one wants (changing) spatial sound to be heard from separate sources, one needs a script in each emitter.

[Voodoo Radek]

This car is going to be mostly for personal and friends use as i don't plan to sell it, but i like the workshop idea a lot: i am very passionate about mechanic! Above all, this project is an excuse fulfill my desire of a particular car i have dreamt about since kid. Also it's a motivation to improve my modeling and scripting skills. Thanks guys, i didn't expected this response. Definitely i will collect and further investigate all the tips you give me.

[revochen Mayne]

I'm not much experienced if it comes to vehicles, but....

 

---

PeterCanessa Oh wrote:

rev-meter

 

---

...made me curious. What is it for?

[Rolig Loon]

It's another name for a tachometer.  It measures (or pretends to show) engine speed.

[Madelaine McMasters]

---

Rolig Loon wrote:

It's another name for a tachometer.  It measures (or pretends to show) engine speed.

---

Where I come from a "rev-meter" is the version control system that tells everybody else that it takes me 10x more edits to get my code working than for them.

That's why I cut the red wire.

[PeterCanessa Oh]

It's for measuring priests of course.  Doesn't every car have one? (Perhaps not, I've never had to learn to drive so I wouldn't know).

[revochen Mayne]

---

Madelaine McMasters wrote:

---

Rolig Loon wrote:

It's another name for a tachometer.  It measures (or pretends to show) engine speed.

---

Where I come from a "rev-meter" is the version control system that tells everybody else that it takes me 10x more edits to get my code working than for them.

That's why I cut the red wire.

---

Honestly, thats what i thought too!

[Poenald Palen]

---

Qie Niangao wrote:

I quite like Peter's suggestion of a kind of "garage" or "pit stop" script that does all the administrative/configuration functions on the vehicle that have nothing to do with real operation. (Unfortunately, many SL users have the absurdly immersion-killing habit of repainting and reconfiguring their vehicles on the side of the road, so it may take some customer "re-education" to adjust their expectations about this.)

Otherwise, yeah, for anything that crosses sim borders, keep the script count to the absolute minimum. It may help slightly to set script state to not running, as LepreKhaun suggests, but I'm not 100% sure what gets transferred between sims when a script isn't running... perhaps nothing more than an asset handle, inasmuch as no state is preserved. (See in particular an ex-Linden's

comment

to SVC-26.)

One other script-count problem that often arises for vehicles in particular is the lack of any -LinkSound() function, so if one wants (changing) spatial sound to be heard from separate sources, one needs a script in each emitter.

---

Colliding and sending a message, you can maybe even use volume detect and make it non phsyical and put i up on a garage door or something. But what about at the tracks? A HUD. You unload all the stuff into a HUD and then have it send a stream of stuff for the listen to handle making changes that you want, you can even load textures by UUID (perms are an issue, but allows user customization) and then detache the HUD when driving. Another method I have seen is using a notecard, notecards can (or could be) sent to a vehicle via collision and I remember inadvertently driving across my door mat and wondered if my car could get the card, it could. I had seen this at race track way back as well (magsl or something like that, way way long ago) and they you changed the settings. The old racers island formula one cars had cards in them to. Obviously, if you put the card into a HUD then if the car loses the info it had you can just use the HUD and the card to send it again. The issue is making mistakes on the notecard, so pretty buttons and hodling info and presets in prim descriptions on the HUD might be a good idea, I think child prims on HUDs don't get the desc. reset when they are detached, but I could be wrong.

Another method may be to store multiple vehicles in a HUD, you click it and it rez's a hard coded, no extra settings and fancy bits changing code in and then detach the HUD. The hud may end up needing 100's of combo's though lol. But, you click the options, click Rez and you get that combo rez'd with the lightest car code you can possibly make with all the stuff in it. Maybe even  server vend it, but the HDU should be detached after done anyway to help with sim crossings.

 

[Qie Niangao]

On the track? Hmmm.  Assuming the car is driven by the HUD-wearer, it doesn't much matter whether the functions are in the car or in the HUD, either way they'll affect sim performance and add chaos to sim crossings. Indeed, Mainland drivers soon learn to strip off all scripted attachments before touring, and that includes any vehicle HUDs. [ETA: Oh, now I see you did say "detach when driving" so we're thinking in the same direction already.] But yeah, for ease of removal, a HUD certainly could be useful, keeping in mind that the inter-object communications (just a listener) is some overhead -- but surely better than keeping resident all the UI control logic all the time.

In fact, the "pit stop" scenario might be a good application both for llAttachToAvatarTemp of a dynamically-rezzed HUD and for llRemoteLoadScriptPin() for the vehicle-side scripts.