Jump to content

There are still people who stick scripts in every prims.


Kyrah Abattoir
 Share

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

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

Recommended Posts

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

ziC6UyN.gif

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

Edited by CoffeeDujour
Link to comment
Share on other sites

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 by Wulfie Reanimator
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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

 

  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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 by Rachel1206
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by Kyrah Abattoir
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

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

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...