Script Idea: "2Agent" Client-Side Code

After reading game idea after game idea, especially the card games and games in dire need of an HUD, I think it's about time we pondered solutions to making certain actions "Client Side."

As such, I propose a new line of scriptcode with "2Agent" extensions. For example:

llSetTexture2Agent(key agent, string texture, integer face)
Forces a new rendering call for key agent on given face of prim. This data is rendered locally, and is NOT stored in a prim's actual parameters whatsoever.

llSetTextureAnim2Agent(key agent, *add script spam from llSetTextureAnim here*);
Calls a texture animation to be passed to selected client(s) only.

llSetText2Agent(key agent, string msg, vector color, float alpha)
Sets prim text locally to selected agent(s).

... and so forth. Alternately, a list implementation of this would be grand.

Now for the technical side of this idea. I think, in a general sense, that something like this could be worked into the backend of LSL (since you're just calling a simple direct refresh to a given client). I also don't see this as abusable, since abuse reports are filable with screenshots.

Well... here's to hoping, anyway.

I like this idea, but would like it even more if it was applied only to llSetPrimitiveParams, and the other functions llSetPrimitiveParams doesnt cover (llSetTextureAnim, llSetObjectDesc, etc). This way we dont have to deal with all the clutter of having two copies of *every* llSet function.

I still think setting linked primitive parameters should be slightly higher in the priority list though
==Chris

Agreed. Here's to hoping.

I would rather this only work for attachments. Also a camera attach point would be good.

Anyway this will generate an entirely new industry, on demand only visable by a single user; porn. New way to kill time at the welcome area

Oh, and I forgot to mention that this hinges on local rendering alone, so two copies of each statistic for a prim would not theoretically be stored. Rather, the command would force a local update directly - and should a script or world update call a new, global update to that same stat, it displays normally.

Besides. Storing 2x params like this would kinda suck.

And Strife, I realize that - but then, people are welcome to (ab)use the software to whatever twisted ends they want, so long as they don't take someone down with them. This was essentially my point on screenshots with abuse reports, though. Since you can include a screenshot, should someone set, say, a grief script to display only to player X, the screenshot feature could still hold the griefer accountable.

Proposition 8 is a good solution to this issue.

http://secondlife.com/vote/index.php?get_id=8