Add llMessageLinkedScript( integer link, string script_name, integer num, string str, key id );
tracked
Woolfyy Resident
Same as llMessageLinked() but addressing directly the named script to stop losing time extra checking each script with link_message(). That way it would open the path to structured / modular programming and better architectured / readable scripts, in spite of overloading scripts with things having nothing to do with each other and having spaghetti programmers always bragging because they are lacking memory.
Log In
Ratany Resident
That's what the integers are for. Script names can change, so what's the point.
You could add another integer as parameter, or another string that can be set to anything, including the script name. You can already transfer a list that contains the information which script has send the message. If I needed that, I'd use an integer because that saves memory and is faster to compare than a string.
If you're creating convoluted code that's difficult to read and unmaintainable, adding more parameters and functions will be counter productive. I would downvote this.
Spidey Linden
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
Tapple Gao
I have a vehicle script I've been working on for 12 years. It started out as a single script, with control event setting vehicle parameters. I have expanded it a lot since then. It now includes AI (control keys simulateed by another script, 7 vehicle mode controlers (ground, swim, fly, each with a physical and nonphysical option, plus attached mode), security features for restricting it to moving within a user-defined area.
It ran beyond the capabilities of one script a long time ago. The most obvious way to split it was at the control boundary: put all the code that takes user control and modifies that into one script (pilot for manual, autopilot for not), and put the different vehicle modes (ground vs flying vs attached) into seperate scripts. However, after using that for a while and comparing that with the old script, I realized I'd lost something important:
input responsiveness.
Just having a link message on the critical path from control event to vehicle parameters made the vehicle harder to steer due to input responsiveness. And people use it for racing. So, I redesigned the scripts again, and went with a design I still dislike: I duplicated the pilot script (input handling) into all 3 motion scripts (ground, flying, attached). I got back input responsiveness, but, now with duplicated code (and now I get to deal with obscure bugs with multiple scripts having llTakeControls active at once)
The script was actually better when it was split: I could use dedicated timers in each script at optimal frequencies for each one, and they don't actually share a lot of state. However, link messages are NOT a great way to split scripts:
- They do cause delay, usually 1 sim frame between send and wakeup, which is bad for vehicles
- They broadcast to every script in the prim. This is ok for some uses, but it's not great when there are 20 or so scripts in the prim, and every link message causes 20 script wakeups
- They require serializing to string at the sender, and parsing from string at the sender, which adds unnecessary cpu usage
We really need a better way to send one message to one other script in the prim. It should ideally be:
- immediate. It is processed as soon as it is called, or, at latest, immediately when the current script ends its active event. No putting it in a queue until the next frame, unless the script would be pre-empted anyway
- synchronous. It would be best if the remote call was an rpc, and did not resume the calling script until the callee script finished. The callee script could possibly even return a value to the caller, making it a remote function and not a remote procedure. This would make it possible to share functions between scripts
- typed, so I can pass things other than strings. I'd like to pass a list and get back a list, without serializing/parsing in the middle, since that's the only typed variable type in LSL
something like:
// sender
list returnValue = llRPC(string scriptName, integer fn, list params);
// receiver
RPC(integer fn, list params) {
if (fn == ECHO) {
llRPCResponse(params);
}
}
Link messages can stay; they are good for shared state updates to all scripts in the prim. But, splitting scripts to deal with exhausted memory needs a finer grained control like a remote procedure call, that addresses the issues with link messages
Woolfyy Resident
Tapple Gao On my side for now I "trick" splitting scripts in between prims.
Moreover i have a "micro controller way approach" with gates and "micro code" attached to some scripts, for example including data not to have to lose time loading notecards, the whole being managed by supervisor scripts that can be cascading.
I splitted the llmessage into INT split with flags + 2 different sized integers UUID for different uses including controlling several related objects + STRING for multi use extra parameters either command line style or data csv style, compressed or not depending on use .. and the whole is configured / optimized, depending on use and debug or not debug mode features, thx to Firestorm's preprocessor features.
So, at the end, being able to address directly scripts would simplify my whole infrastructure ... knowing that it is also a long time that all can't fit into one script on my side and anyway i don't want it to fit into a bulk spaghetti script as i want to have my modules to keep being modular and easy to configure depending on the build in which i implement features or not.
And for sure we do rolling releases of our code over the years, that we want to keep being clean and readable for multi use. It is not done for a one shot / simple use case as most "scripters for hire" do.
RestrainedRaptor Resident
I guess what you're really after is a link message equivalent of message filtering that exists for chat channels, provided by
llListen
Peter Stindberg
I don't see an issue here. Linkmessage-events - if
not
queried - cost no script time. There are an awful amount of events occuring for any given script at any time, and they cost no script time if the script simply ignores them.If
they are queried, it's also a non-issue if some thought has been given to the proper usage of the string/key parameter fields, to filter out and quickly skip over unwanted/3rd-party link messages.However, the idea is not
totally
without merit, if you are operating in a modifyable object and share the linkset with 3rd party scripts you have no control or trust over. But as Bavid mentions, the script name is probably the worst choice for targeting.If something like this would be implemented, a PIN similar to
llSetRemoteScriptAccessPin
would be a suitable way. With a unique PIN, settable by the receiver script, the script name/version is irrelevant.In scenarios like the above (3rd party scripts in the linkset and data-integrity/secrey concerns), I use LSD with protected keys as messaging basis. But of course, the same could be achieved with link-messages and encrypted strings.
Woolfyy Resident
Peter Stindberg The idea is much simpler : when you have several scripts into an inventory or you don't want to check where the hell is the script, the idea is to simply send it directly to the right script.
Otherwise you need to do a protocol to filter a message on all the scripts to which the message could be sent and it needs the server to check each script until the right one is found. And this is time consuming + technical cost.
Moreover the aim is also to structure scripts in spite of doing spaghetti programming, which means addressing scripts considered as modules.
UPDATE: Let's imagine that you have 30 scripts in a build (for reasons needing them to be split that way), then the idea is to address each one directly and individually with the correct parameters without having to use one prim for each to do the same.
Bavid Dailey
Peter Stindberg
The problem of using LSD, is that if you're using it as a 'permanent' database, you will come to begrudge using it for other things. Overloading makes for conflicts.
Bleuhazenfurfle Resident
Peter Stindberg: If the script has no linked_message handler, then no event is scheduled, and indeed it has negligible cost. But, I can't think of the last time I had more than one script in an object, without each and every one of them having a linked_message handler.
And if there's a handler, then the event needs to be constructed, queued, the script scheduled, and invoked, and all that even if the handler is empty, and before the first line of the handlers code gets evaluated (ie. before any such filtering is possible) — I see people frequently forgetting that there
is
cost to invoking a handler, probably because it's nigh impossible to measure.The ability to not queue the event at all, is actually a good one, and the same reason there are calls to add filtering for the changed event — it's a rather significant performance hit if your colour cycling shoelaces simply want to know when the shoes they're attached to get transferred to a new owner. (And yes, of course there is an alternative way to handle that, it's called an example — because I just know
someone
will want to argue the point.)A pin is horrible for security, it's only 32-bit. That's pretty uselessly small for actual security, if the attacker has even a little time on their hands. For that, the only real option is encrypting or signing your messages (I sometimes do this by computing a SHA hash of the message payload, and passing it through the key parameter of link_message). This could be improved by whacking the script with a large delay in the event an incorrect pin is used (though there are no examples I can think of off hand, of a command having a variable delay — that might not even be possible in the current system), or even halting it entirely with a debug channel error, but that's nothing a bot couldn't bypass quite easily. (So now you're making up even more cryptic limits, and the whole thing goes to hell in a handbasket.)
Being able to address the target script directly bypasses the need to encrypt, and allows for the use of a one-time session token negotiation (which must be kept secret). Many of us do this all the time with llRegionSayTo, for example. Not to mention avoiding a whole heap of excess events being queued and processed.
As for addressing a script by name, I don't like that either. It's fine for optimisation, but not authentication. Would much rather use the scripts UUID. And yes, the UUID will change at times such as when the script is recompiled, but that's the
right
time for it to change anyhow. So, you authenticate, and if the script passes validation, you remember it's UUID, and send your messages direct henceforth, is how I would see this being useful. (There is one more issue here… More than one script having the same UUID… Which is where a URI would help, but I can't think of a suitably stable one off-hand that meets the requirements above.)Woolfyy Resident
Bleuhazenfurfle Resident I was initially thinking about UUID but the last time i proposed it into another feedback the idea got closed directly by LL .. so i suppose they are quite hermetic to UUID use ... but maybe i am wrong :-)
Update: My idea is that it can be targeting one OR multiple scripts too inside a build. The linked prim number is also a way to either limit or open reach. If i remember, one day you talked about micro controllers, so in the idea it has some similar approaches to electronics with micro code and gates. Making it be a powerful toy for those who master it.
Bavid Dailey
Must be a better way than drecting to scriptname; i name my scripts with versions for one thing. Suggest adding a way to assign a URI to a script, association to be controlled by the programmer, and using that as the second parameter above.
Woolfyy Resident
Bavid Dailey To explain it in a simple way : when you do a function you don't call a function each time adding its release number. You have a name for the function (imagine the same for a module) and you set the release number etc. into its comments.
As for UUID it changes all the time / adding extra fields it will be never done by LL as it is too complex to add on their side.
So ... the easiest stable way naming something in an inventory inside a build (not related to C/M authorizations when it is about linked prims) keeps being its name.
BTW the initial idea is not to add modules (though it could work if C/M) but to use already existing ones ... as i said it is first for modules not updates, to better architecture programming.
Bavid Dailey
Woolfyy Resident
No a URI used as a label, it's not the URI of the script, so it does not change as the script is recreated - that's the point.
To restate :
- script is assigned a developer managed URI , which it can assert as its 'identity'
- the proposed extension directs link messages only to a supplied URI
Woolfyy Resident
Bavid Dailey anyway let's see what LL will do .. my feeling is that if they have any field or renaming to do it will go nowhere as it is too much of an architecture change on their side, reason why on all my proposals I (try to) stay within what is already existing ...