Linking multiple prims, each with different scripts.

[Iniq]

Attaching objects, each with its own script, the prime object's script takes over. Is it possible to make the scripts in different linked objects perform independently without combing the scripts into one script, using a menu to choose between the different scripts?

For instance, when I link an object with its own script to another object with a 'Sit' script, the script in the newly linked object is diverted to this 'Sit' script found in the first object, so I sit instead.

Edited February 10, 2020 by Iniq

[Qie Niangao]

The devil is in the details. For example, this should be relatively easy if you're writing these scripts from scratch. It may be considerably more difficult or even impossible if these are black box, no-mod scripts.

Starting from your example, suppose they're both "sit" scripts. That means they'd both have an event handler for CHANGED_LINK and if both scripts are in "Running" status, they'll both get the event. If you have a controller script that keeps them both in "Not Running" status until somebody selects from a menu, that selection would need to happen before somebody sat down because there's no way for a script to fake the event for sitting down. (Well... actually, there kinda is a way in this particular case that might work for some sit scripts, but this is a fluke of the example.)

Those may be all the wrong details, so let's start the interrogation with: Are you writing all the scripts? And is it really about a pair of sit scripts that should behave differently when their objects are linked as one? When and how is it decided which script should do what (if it's really by menu, when does it appear and how does the user know which one she wants to activate, if it's really just that one is active and the other isn't)? Are there just two scripts involved, and just one linking event? Does the user link the objects in the editor or is that linking done by a script? Will one of these scripts be in the root prim?

[Iniq]

2 hours ago, Qie Niangao said:

The devil is in the details. For example, this should be relatively easy if you're writing these scripts from scratch. It may be considerably more difficult or even impossible if these are black box, no-mod scripts.

Starting from your example, suppose they're both "sit" scripts. That means they'd both have an event handler for CHANGED_LINK and if both scripts are in "Running" status, they'll both get the event. If you have a controller script that keeps them both in "Not Running" status until somebody selects from a menu, that selection would need to happen before somebody sat down because there's no way for a script to fake the event for sitting down. (Well... actually, there kinda is a way in this particular case that might work for some sit scripts, but this is a fluke of the example.)

Those may be all the wrong details, so let's start the interrogation with: Are you writing all the scripts? And is it really about a pair of sit scripts that should behave differently when their objects are linked as one? When and how is it decided which script should do what (if it's really by menu, when does it appear and how does the user know which one she wants to activate, if it's really just that one is active and the other isn't)? Are there just two scripts involved, and just one linking event? Does the user link the objects in the editor or is that linking done by a script? Will one of these scripts be in the root prim?

WOAH!

I'm no scripter, but SL is ruled by scripts. The editor, as simple and compact as it is, is very useful for customizing the average resident's experience, which is after all the real magic of SL. I enjoy linking copy/mod scripted objects in ways that suit my satisfaction. So for example, let's say I want to build, or customize a scripted SkyPlatform with a seasonal texture changer, then link several other scripted objects such as a cottage, furnishings, landscaping, along with other mood enhancing particle scripts, making the whole rezzable as a single modular unit.

From what you described at the start, I'm thinking a third party commercial menu system must be employed to parse out the various scripts. Has there been any such universal menu system made available that could handle such an application for us DIYs? 

 

Edited February 10, 2020 by Iniq

[Qie Niangao]

58 minutes ago, Iniq said:

From what you described at the start, I'm thinking a third party commercial menu system must be employed to parse out the various scripts. Has there been any such universal menu system made available that could handle such an application for us DIYs? 

Almost the opposite: I'm saying that such a universal system could never exist, but that for specific applications what you're trying to do probably can be done. And there may be a class of similar applications for which that solution could be generalized, but there are a host of "gotchas" that could crop up to constrain its applicability.

I guess, based on the example, it's possible everything would just keep working as intended when new items are linked in, with no need for any script changes at all. Items that respond to touch would still respond to touch either anywhere (if the script is in what's linked as the root prim) or on the scripted prim. On the other hand, some scripts are written assuming they'll be in the root prim, and there's only one of those per linkset, so they'd need to be replaced (or augmented, for certain particular scripts).

Similarly for example, many "object animation" scripts assume they're moving stuff relative to a particular root prim; if relinked with a different root, those scripts might move things in crazy ways or refuse to move them at all -- although it's also possible to make scripts (using more complex geometric calculations) that move things relative to an arbitrary named prim whether it's linked as root or not. That's the power of being able to write the scripts from scratch -- or at least see inside and modify them.

[Iniq]

4 hours ago, Qie Niangao said:

some scripts are written assuming they'll be in the root prim

Got me thinking.

Some scripts I think are written to involve the entirety, including linked objects, while some to a specific name as you pointed out. So, the one written for the root, and to reach all that's linked would be the rogue. Here's where poseballs come in opposed to AVsitter. A good example of a scripter taking the holistic approach, concerning multiple scripts, is the BBS boats, whose scripter whom know btw, not know, but having received his name from the owner of BBX. Those boats are a bundle of many linked scripted prims that use a proprietary menu system to access each.

So what of these poseballs that everyone seems not to like, but other scripts not related to sitting aren't helped. One thing I've run into, are scripted objects that are supposed to be copy/mod, but aren't.

Edited February 10, 2020 by Iniq

[Qie Niangao]

Not sure I'm being very helpful at this point, but a couple tangential observations: It's dreadfully easy to make "packaging" errors with products that end up giving them the wrong permissions; I've done it myself, many times, just passing out stuff that turned out less permissive than intended. There's also a sorta convention that objects can be considered "Copy+Mod" even with no-mod scripts inside, in case that's what you were referring to.

The other thing is that AVsitter is kind of a special case in that its important scripts are all available free, open source, and with permissive licensing, so they can be modified if necessary. It's also special in that it has some utilities for when the sit scripts don't reside in the root prim. I've never used them, but I guess they must be useful, and they were coincidentally what I was thinking of when I noted that some scripts might not need to be replaced when the root link changes but rather might be "augmented, for certain particular scripts."

[Iniq]

4 hours ago, Qie Niangao said:

Not sure I'm being very helpful at this point, but a couple tangential observations: It's dreadfully easy to make "packaging" errors with products that end up giving them the wrong permissions; I've done it myself, many times, just passing out stuff that turned out less permissive than intended. There's also a sorta convention that objects can be considered "Copy+Mod" even with no-mod scripts inside, in case that's what you were referring to.

The other thing is that AVsitter is kind of a special case in that its important scripts are all available free, open source, and with permissive licensing, so they can be modified if necessary. It's also special in that it has some utilities for when the sit scripts don't reside in the root prim. I've never used them, but I guess they must be useful, and they were coincidentally what I was thinking of when I noted that some scripts might not need to be replaced when the root link changes but rather might be "augmented, for certain particular scripts."

I edited out the TOS comment. It should be noted whether or not script is modifiable. In RL, we purchase stuff making it our own, to modify, and give away if we so desire, apart from special licensing. Here is how I would imagine it should be, here in SL:

(for personal use only, always Copy)

• Copy/X-Trans/ScriptMod
• Copy/X-Trans/X-ScriptMod

(for gifting when desired, always X-Copy/Trans, unless giving away as charity, otherwise we're stealing)

• X-Copy/Trans/ScriptMod
• X-Copy/Trans/X-ScriptMod

(priced for distributors, or given as charity, always Copy/Trans)

• Copy/Trans/ScriptMod
• Copy/Trans/X-ScriptMod

Everything in our possession should be required by LL to be modifiable, excluding scripts. We should be allowed to modify anything in our inventory, and transfer without copy, with Copy/Trans/ScriptMod optional permissions.

These be my personal opinions only.

 

 

 

Edited February 10, 2020 by Iniq

[Mollymews]

there are some use cases where No-Modify is a necessary component of the item

some are: game tokens, store credit vouchers, custom class racing vehicles, breedables, collectibles

[Iniq]

wow.. this all gets complicated, but for the day in, day out SL consumer, perhaps should help out their inventory specifically. I think it might greatly increase the value of inventories to encourage investing in

Edited February 10, 2020 by Iniq