Jump to content
ChinRey

Multiple versions of a script or one big "masterscripts"?

You are about to reply to a thread that has been inactive for 71 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I think I need some advice on this.

I'm working on a setup script for a modular road system, one with texture changer, resizer and a few other options - pretty standard stuff,

The problem is that although most of the functions are the same for all modules, there are some thathave to be handled differently and some that aren't relevant for all. The straight modules need separate resizer function for width and length and automatic and manual texture repeat adjustments. The crossroads and T-junctions need to have fixed texture repeats, the Y-junctions and curves need fixed width/length ratios etc., etc.

The question is, should I write different setup scripts for the different modules or one big script with lots of if's and else's to handle the differences?

I know there's not a definite answers to this but does anybody have any general guidelines?

Share this post


Link to post
Share on other sites

rather than if this if that conditionals in a super large script  then my suggestion is to go with states, each state being a module

the state modules can access the common functions while keeping module specific code in their own code blocks

  • Like 2

Share this post


Link to post
Share on other sites
2 hours ago, ChinRey said:

The question is, should I write different setup scripts for the different modules or one big script with lots of if's and else's to handle the differences?

I'd always go for smallest individual scripts dedicated to the task in hand. They're

Simpler to code

Simpler to debug, especially five years on

Easier to adapt to slightly different requirements

There was a fourth advantage but it got away from me as I was correcting a typo.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
2 hours ago, Mollymews said:

rather than if this if that conditionals in a super large script  then my suggestion is to go with states, each state being a module

That's a very interesting idea. I don't think it's a good option in this particular case but definitely something to keep in mind for similar cases.

 

21 minutes ago, Profaitchikenz Haiku said:

I'd always go for smallest individual scripts dedicated to the task in hand.

I should have mentioned that the script as it is now, made to work for a single module, is 381 lines. Half of the lines are for a user defined function that handles messages from the various menus and that function only needs a few changes for the other modules. A consolidated script would probably be about 600 lines. Also, there are more than 50 modules.

Edited by ChinRey

Share this post


Link to post
Share on other sites

Now you tell us... @)

 

One option then is a generic script that reads either the prim name or description in order to adapt the behaviour to a specific case. The advantage here is that by a simple tweak to the prim name or description you get variation in the behaviour.

  • Like 1

Share this post


Link to post
Share on other sites

Prof has made some solid points. It's debatable whether a single large script is a more efficient use of system resources, but it's almost certain that it's more complicated to write, debug, and maintain than a set of separate related scripts.  Once written, the large script may be fantastic but only useful for that one project. The answer to your question, then, may come down to analyzing whether it is a good use of your time to do all the extra work of writing, debugging, and documenting a huge script for one use.  I have written a few monsters that justified the effort because they were likely to be needed for a long time in a single setting. I have written other projects with  modular scripts because I could foresee more use for the modules in different projects down the line if I kept them separate.  

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
3 hours ago, Profaitchikenz Haiku said:

Now you tell us... @)

Yes, sorry. ;)

But in any case, I do believe this is something that is worth discussing in general, not only for this specific project.

 

3 hours ago, Profaitchikenz Haiku said:

One option then is a generic script that reads either the prim name or description in order to adapt the behaviour to a specific case.

That was my original plan, except I'm using creation date as the unique identifier for the modules. I had second thoughts about it though and now I'm not so sure if that's the best aproach.

 

1 hour ago, Rolig Loon said:

It's debatable whether a single large script is a more efficient use of system resources

That's definitely an interesting question in general although hardly relevant for this case. I do assume people have the sense to clear the scripts after they've laid the roads down. Even if they don't care about simulator load, it should still be annoying enough with all those clickable objects scattered all voer the land. Oh and btw, yes, the script does include a self desctruct mechanism.

 

1 hour ago, Rolig Loon said:

it is a good use of your time to do all the extra work of writing, debugging, and documenting a huge script for one use.

The question is also whether separate scripts really saves time. In this case that would mean a total of 15,000-20,000 lines and even if it's mostly copy-and-paste, there are a lot of things that can go wrong.

Edited by ChinRey

Share this post


Link to post
Share on other sites

There's an overlap here with another thread discussing multiple scripts in a linkset, this might be a good case for having the common-function script plus an individual script, so there are going to be two scripts in every prim. The common function script is passed a link-message request and replies with a link-message answer. More sophisticated but perhaps more laggy is a server in a prim in the region where the operations are happening. The server gets llregionSayTo messages, and replies to the particular querying prim using llRegionSayTo for the Id it heard the message on.

 

Of the two, I spent more time sorting out problems on the server approach, but once sorted, it means changes to the common functions only involve updating a single prim's content, one or more scripts in several score rezzed prims would be a real pain to update.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, ChinRey said:

The question is also whether separate scripts really saves time. In this case that would mean a total of 15,000-20,000 lines and even if it's mostly copy-and-paste, there are a lot of things that can go wrong.

That's a good point, and it focuses on a different facet of my concern for how much your own scripting time and energy are worth.  My earlier point was aimed at looking ahead to future projects.  If I am scripting for a large complicated project, part of my mind is asking "What parts of this will I be able to scavenge for future projects?" .  I hate to spend a lot of effort writing a script that will be used only once, unless there's a possibility that I can lift modules or at least functions that will be useful later.  Over the long haul, there's value on remaining flexible today.

  • Like 1

Share this post


Link to post
Share on other sites

@ChinReyif you use the fast config trick I posted earlier you can probably get away with a master script with a few "flags" to change its behavior.

But i'm more questioning the benefit of having scripts at all in a modular road system.

Share this post


Link to post
Share on other sites

thinking about this a bit from the pov of when I have used kits to build roads and paths

what I would really like as the road builder is when I have fitted all the pieces together (some linked, some not linked) then there is a HUD from which I can pick the textures, and the HUD regionsays what the texture is and all the pieces change to that texture. Then when I am happy I can use the HUD to instruct Finish! and the scripts in all the pieces delete themselves

for this to work then each piece has its own script written for its specific shape

Share this post


Link to post
Share on other sites
3 hours ago, Kyrah Abattoir said:

But i'm more questioning the benefit of having scripts at all in a modular road system.

If it's worth doing, it's worth overdoing. :P

But seriously, you may be right. It's a question of maths though, or rather how SL'ers tend to hate even fairly simple calculations. Look at this module for example:

bilde.thumb.png.fd9ccc65c01aa2a8f9c84b266fff22dd.png

It's a y-junction with the two branches at 60 degrees relative to each others. To fit the other modules seamlessly it needs to be exactly 1.732 times as long and 1.25 times as wide as the actual road width. Considering how much the average SL'er - and especially the average SL builder - seem to hate even trying to do the simplest calculations I think it would put many off if they had to do that manually.

This is not a regular SL road system, I see no point in making something yet another one of those. It's for making road networks that are far more "organic" and realistic and blend much better into the landscape than what we usually see in SL. That makes everything a lot more complicated and I'd like to automatize at least some of the work.

Share this post


Link to post
Share on other sites
3 hours ago, Mollymews said:

what I would really like as the road builder is when I have fitted all the pieces together (some linked, some not linked) then there is a HUD from which I can pick the textures, and the HUD regionsays what the texture is and all the pieces change to that texture. Then when I am happy I can use the HUD to instruct Finish! and the scripts in all the pieces delete themselves

Oh yes, that would be lovely. I'd also love to have the modules snap into place automatically. But now we're not only talking about a big script project but a HUGE one!

Share this post


Link to post
Share on other sites

The only problem i see is from a grid health standpoint, users almost never hit the "delete script" button, because this brings permanence and commitment to choices.

  • Sad 1

Share this post


Link to post
Share on other sites
5 hours ago, Kyrah Abattoir said:

The only problem i see is from a grid health standpoint, users almost never hit the "delete script" button, because this brings permanence and commitment to choices.

i quite like how some rezzers do this.  Set the text property of the rezzed prim. To minimize obstructing the view when assembling the road pieces then put a single char full stop.dot, which only gets removed, set to "", when Delete scripts command is applied

Share this post


Link to post
Share on other sites

@MollymewsThat's a good approach yes.

I understand the necessity in this case, due to the potentially complex math involved to allign the pieces.

It is slightly concerning how few of SL residents are actually able to use the built-in tools to their full potential.

  • Like 2

Share this post


Link to post
Share on other sites

I have 3 optione to do a masterscript:

- I make - for example 10 - modules and include the one that I need for a specific version of a script.
- I add 10 functions to the script and call only the one that is needed for the specific version. The other 9 unused functions will be optimized and automatic removed from the code.
- I use the preprocessor
   #IFDEF type1
      ... code for type1 here
   #ENDIF

I can do all this because I use LSLForge for scripting. It's a big change to Install Eclipse and add LSLForge and some extras and script offline, but for me it was worth it.

You can probably use the include function of the Firestorm preprocessor for similar results. I don't use it though so can't tell you much about.

Advantage - 1 script to maintain and update. If you never maintain and never update you can stick to many specialized scripts of course.

Using states has a big disadvantage: you need to code the event handler for every state. Alot of ballast and a nightmare if you make changes. May be an option for simple scripts though.

Of course you need to find a balance. Before making overcomplicated super monster scripts it's better to modularize and run more than one script. I am totally unscrupulous to use multiple scripts if I have to. There are more important things than saving cpu cycles. (like my time and my ability to maintain the code and my mental health) 😎

 

Share this post


Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 71 days.

Please take a moment to consider if this thread is worth bumping.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...