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

[ChinRey]

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?

[Mollymews]

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

[Profaitchikenz Haiku]

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.

[ChinRey]

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 April 28, 2020 by ChinRey

[Profaitchikenz Haiku]

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.

[Rolig Loon]

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.  

[ChinRey]

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 April 28, 2020 by ChinRey

[Profaitchikenz Haiku]

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.

[Rolig Loon]

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.

[Kyrah Abattoir]

@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.

[Mollymews]

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

[ChinRey]

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.

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:

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.

[ChinRey]

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!

[Kyrah Abattoir]

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.

[Mollymews]

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

[Kyrah Abattoir]

@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.

[Nova Convair]

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) 😎