There are still people who stick scripts in every prims.

[Kyrah Abattoir]

This is grossly inefficient and hasn't been necessary since at least 2007.

It is now 2020 why are people still doing it?

 

[Wulfie Reanimator]

I put my main script in the root and the other 19 into a microscopic mesh triangle where people won't find it.

[Profaitchikenz Haiku]

Some people are slow to change, others learned by seeing how 2006-style freebies worked and because most modern stuff is no-mod they rarely get a chance to look at a better way of doing things. Still others just don't care, "lag? what lag? I see no lag"

[Da5id Weatherwax]

I totally agree that it's unnecessary most of the places you see it, but there are valid design and use reasons to separate functionality out into a separate prim.

Some places where I've made that choice  recently:

• A "control panel" child prim where it makes sense to manage its appearance and handle interactions locally.
• Where the main script has to deal with an arbitrary number of functionally-identical children - making those children able to report their presence and status, able to respond to both directed and broadcast commands from the main script, it makes sense for those children to be individually (but identically) scripted.
• If you have to separate functionality into multiple scripts anyway, for memory or efficiency reasons, no reason to not put the subordinate script(s) where they have their effects if that happens not to be the root.

In most cases, the places where multiple scripts makes sense is when the design takes a modular approach, either because it is the best way to make something work or it makes considerations of future maintenance easier to deal with.

[Coffee Pancake]

There are a couple of edge cases where multiple scripts and linked messages is the only way to accomplish the task at hand, synchronicity of changes across multiple parts of a linkset for example.

If you find yourself needing to do this, then it's probably fair to say you're off in the woods and should be reconsidering the entire project, because unless your actual goal is itself an edgecase, there is almost always a better way that does not involve this rabbit hole.

[Wulfie Reanimator]

1 hour ago, CoffeeDujour said:

There are a couple of edge cases where multiple scripts and linked messages is the only way to accomplish the task at hand, synchronicity of changes across multiple parts of a linkset for example.

If you find yourself needing to do this, then it's probably fair to say you're off in the woods and should be reconsidering the entire project, because unless your actual goal is itself an edgecase, there is almost always a better way that does not involve this rabbit hole.

What kind of edge-case, out of curiosity? The one you vaguely mentioned is 1) not synchronous, 2) prone to lost messages, and 3) at least partially doable with SLPPF unless the changes are script-related. (I assume so.) The kinds of situations I can think of are gun-related and we have workarounds for the workarounds!

[Coffee Pancake]

I was needing to code something that changed face colour on a grid of regular prims so it could be seen from the world map and changes would appear synchronized when viewed in person.

It's a stack of edge cases ... a pixel grid display, prim based (not mesh) and viewable from the world map.

[Wulfie Reanimator]

10 hours ago, CoffeeDujour said:

I was needing to code something that changed face colour on a grid of regular prims so it could be seen from the world map and changes would appear synchronized when viewed in person.

It's a stack of edge cases ... a pixel grid display, prim based (not mesh) and viewable from the world map.

Why couldn't you do that with a single script and llSetLinkPrimitiveParamsFast?

[Coffee Pancake]

42 minutes ago, Wulfie Reanimator said:

Why couldn't you do that with a single script and llSetLinkPrimitiveParamsFast?

8x8 grid, 64 pixels, must be made from cut prims (as mesh face colours do not show on world map). llSetLinkPrimitiveParamsFast can't set all of the parts at the exact same time which is required for it to look right (the changes appear sequentially), so each sub part requires a frame buffer script to store the changes, and then apply them on a signal.

Making this kind of display, this way, in SL, is dumb .. but as I said .. edge case!

Edited April 24, 2020 by CoffeeDujour

[Wulfie Reanimator]

4 hours ago, CoffeeDujour said:

8x8 grid, 64 pixels, must be made from cut prims (as mesh face colours do not show on world map). llSetLinkPrimitiveParamsFast can't set all of the parts at the exact same time which is required for it to look right (the changes appear sequentially), so each sub part requires a frame buffer script to store the changes, and then apply them on a signal.

https://puu.sh/FBIlB/7d0b8bbb9a.mp4

Script: http://puu.sh/FBImq/0187dc0d22.txt

More accurate replica: (Is that Game Of Life, by the way?)

https://puu.sh/FBJpk/1d03d4f060.mp4

Script: http://puu.sh/FBJpT/7282c81f96.txt

Edited April 24, 2020 by Wulfie Reanimator

[Mollymews]

another edge case

animations that are no-modify, so we can't rename them, and we don't want to have to use a notecard listing to separate them into groups

dance animations in one prim, cycling every 30 seconds

gesture animations in another prim, cycling on some other time

[Qie Niangao]

Couple more edge cases:

Stuff for which the Lindens never got 'round to making link-specific calls, notably sound (and I'm not thinking of others at the moment). It's cool that sounds can be heard from the specific emitting link, especially in vehicles, but there's no way to do that from the root prim. 

If it's necessary to message between scripts, there's probably some small advantage for the sender to direct the message to the intended recipient by specifying a link containing only the target script, rather than all the scripts having to wake up and decide if each message is for them. (I think for a while OpenCollar had a version that did this, but it so messed up folks trying to use the scripts for their own builds that I think they abandoned it. That's all hearsay so take it with a grain of salt -- and for that matter, this whole approach of link-based message dispatching is something I don't think I've ever used myself.)

 

[Coffee Pancake]

15 hours ago, Wulfie Reanimator said:

PRIM_LINK_TARGET

Well, would you look at that ... PRIM_LINK_TARGET ... thanks !

[Scaler Rexen]

I believe that most people are not script/code savvy that purchase scripts off marketplace that handle only a single feature they're looking to have in their product. 99% of the time I inspect something I'll see a naming scheme like "Texture Menu1" "Texture Menu2" "Change Color1" "Change Color2" "Rotate slow" "chat commands". 

[Rachel1206]

On 4/24/2020 at 2:36 PM, Qie Niangao said:

Couple more edge cases:

Has any else noticed this:

llSetLinkTextureAnim behaves a little different compared to llSetTextureAnim, at least I observed this on making light ray casts, where I chose to reverse back to llSetTextureAnim with extra scripts in prims in order to get best moving light ray casts.

 

[Rachel1206]

Older widget based large scripts (COPY, TRANSFER, NO MOD)  solutions as found on MP often:

• use script injection into prims for functionality
• taking over touch based operations, enforcing usage of scripts in prims to change user input

Clearly those solutions should be updated, especial if a large consumer base. Fact remains, they are in wide use and most often by ppl, who are not programmers, but looking for widgets helping them accomplish their work.

I would also argue that the clever llSetLinkPrimitiveParamsFast functions by no means are easy to use for a person with no programming background. Hence ppl revert back to the easier scripting functions, where the price is extra scripts in prims.

Edited April 26, 2020 by Rachel1206

[Wulfie Reanimator]

1 hour ago, Rachel1206 said:

Has any else noticed this:

llSetLinkTextureAnim behaves a little different compared to llSetTextureAnim, at least I observed this on making light ray casts, where I chose to reverse back to llSetTextureAnim with extra scripts in prims in order to get best moving light ray casts.

What do you mean by "light ray casts?" I have a couple guesses, but not sure.

[Rachel1206]

The rays you see above as light propagation, made artificial to mimic the optical effects of the head lamp glass and dust/fog in in the air.

[Kyrah Abattoir]

On 4/25/2020 at 7:45 PM, Scaler Rexen said:

I believe that most people are not script/code savvy that purchase scripts off marketplace that handle only a single feature they're looking to have in their product. 99% of the time I inspect something I'll see a naming scheme like "Texture Menu1" "Texture Menu2" "Change Color1" "Change Color2" "Rotate slow" "chat commands". 

I'd rather buy something unscripted than something cobbled together by someone who can't script.

I mean how do you even provide tech support then?

Edited April 26, 2020 by Kyrah Abattoir

[Coffee Pancake]

Cobbled together isn't always bad .. in SL terms it tends to mean 'it does the thing, mostly ok'.

Takes a skilled scripter to over engineer something that should just be 'core functionality' into a '2 dozen script based system'.

[Ruthven Ravenhurst]

Sensors. I have a gargoyle statue that breathes  fire at people targeted from a sensor. The sensor needs to come from the mouth. The sensor range/arc/direction can be customized via script, and resides in a sphere shape to visualize the sensor by matching the dimple and size of the sphere to arc and range. The rotation of the sphere determines the direction of the sensor.

Thinking on it now, this could be done with llGetAgentList on a timer and setting a box shaped area rather than a pointed sensor that can easily be tricked (imagining someone walking along the wall under a camera to stay out of the camera's view).

[Kyrah Abattoir]

My rant is about people who cram scripts in every prims, just because you need a couple scripts to target specific prims doesn't mean you are in that category...

I'm staring at an 8 prim pose blanket here with 56 scripts.