Is this possible?

I've a bunch of ideas and things I want to do/make/script/build/etc. in SL. I've build a rudimentary knowledge of clothing, texturing, and building. But I only have a minimal understanding of scripting. So I have a couple questions to see if an idea I have is even feasible..

1. Can a script pick up the identity of the last Avatar you clicked on, or have the camera trained on? Or, can a script inject selections in your pie-menu (or create a second ring of options) when you right-click on someone?

2. I know that a script listening on channel 0 is bad, but does listening on another channel also create appreciable lag if say a whole club of patrons was listening to the same channel? If so, is it possible to somehow 'ping' a script attached to another avatar to start it listening?

3. Is it possible to display a list of options (possibly up to a couple hundred) that can be selected by the player and stored?

ugh.. so many more questions, but I think I'll stop myself here since these are some of the larger functions I would like to use.

1. Yes to clicked, sort of for focused on. detecting camera focus requires tracking people's cameras which in turn requires permission to track their camera. Difficult to do for a lot of people.

2. It's better on an off channel but still not good. Even a listen that doesn't hear anything uses up more processing time on the server than most scripts without listens. the only option for pinging the script better than the listen itself would be collisions. Shooting your patrons however is not a great idea and physics is also not the friendliest thing for the server. Unless you can reliably get your patrons to run into something when their attachment needs to start listening, just listen all the time. It's about the only option.

3. No, not at the same time. You can use llDialog to display 12 at a time, and then create a series of dialogs with next and previous buttons, but llDialog is pretty clunk. I wouldn't recommend using a string of 20 or however many it would take for a couple hundred options. There is also the option of using a hud with a couple hundred buttons. Any single object can be as many as 255 prims. We can't currently put text on a prim though we can make it hover over a prim with llSetText which might work. Or you could make a couple hundred button textures if they're static buttons. Or if the button labels are 5 or possible 10 letters or less you could use a stripped down version of xytext to put words on a prim using letter and number textures.

#1
YES llDetectedKey and some bit of control, this can be ezly done to a point (which equals about 250 av's at a time with the 16kb list mem give or take)

#2
YES all listens cause lag, the thing with using other channels than 0 for chat is that it would be directed to only that channel, so the effect is (alot) less

AV's can only hear chat on channel 0 unless you relay a llDialog or instant message (which delays the scripts for either 1 or 2 seconds)

You can ping anything, if its setup for the ping, random joe attachment #87 may not comply with your script... theres something to be said about some standards there... but theres none atm (so unless you wrote the script it probally wouldnt respond to your ping)

#3
There are a few ways of doing this, chat commands (ie /99 stop) altho this is tedious for the user, secondly is llDialog which can display 12 pushbutton options at the same time

Neither of these is redundant, meaning each time the script loads it has to set all the settings again (its good for UI tho)

for settings that save you use a notecard and LSL functions that read the card ... if you were to save 1 option per line you could get upto 256 options (0-255) in one notecard, that wouldnt change unless the user decided to


script loading tho doesnt mean every time you attach it,or rez it, just whenever the script is totally reset

Thank you for the replies. There are some interesting hurdles to get over, but they're not insurmountable if I'm reading things correctly.

1. Sounds like the camera detection isn't that trustworthy, and since SL doens't have a 'target' like a traditional MMO, I'll have to do something with context menus, or just use a text command line.

2. It seems a listen will have to be the way to do it, if the context menus don't work.

3. Seems I'm just going to have to have a notecard that the user will have to edit. Not the slickest solution, but it may work better overall. But that does raise another question.


New questions:

1a. Is it possible to have a script attached to me, influence/add-to the right-click context menus?

1b. Or better yet, is it possible for a script attached to someone else to influence/add-to the context menu I get when I right-click on them?

3a. Can a line of text from a notecard be parsed?
(i.e. can I turn: "Red Yellow Blue Black White" into:

Red
Yellow
Blue
Black
White

)


Essentially, I'd like to make an attachment that will convey information about the owner to another player. Ideally, it would be good if the person recieving the information didn't need to have anything special to interact with the attachment, (and didn't have to click on the attachment directly).

Ideal Example:

You meet Joe Smith
Right-Click on him and your context menu has a new option (or a second ring with options).
You choose the appropriate option
A Notecard is *generated* based on the one edited by Joe in the attachment and handed to you.


I want to do this because I came from some text-based environments that had functions that I thought were very handy which are nonexistant in SL. This would be the ideal framework to build some of these functions from.

no the pie menu is pretty set, you can change text for sit and pay (maby some others) but thats about it

yes, if you can figure out a effecent (prefebally) way to communicate data betwen mutiple entitys usually this is done with some client / server setup

yes you can using one of many string functions, list functions or the mix of the 2

and No you cannot write data into notecards via script, you can atho save data temporarily in the script (it will persist as long as it doesnt reset, there are ways around this invoving outside servers)

hehe, good idea.

1(a,b). A script can change the name of some of the existing right click context menus (sit, touch) but only for the object it's in. You can't do this for an avatar but possibly for an attachment on them. Only touch on an attachment and I'm not sure the replaced text will stay replaced on an attachment.

3a. Yes, you can parse text using the list functions.

llDumpList2String(llParseString2List(space_seperated_string, [" "], []), "\n";

would parse your string of colors assuming your string of colors is stored in the variable space_seperated_string above.


NOTE: You can't write to a notecard, only read, so generating a notecard to be sent to someone isn't an option.

Hmm, ok, I could have sworn I was handed a generated notecard at one point.

1a,b. Drat. Then either the person requesting the info will have to have an attachment of their own, or will have to know the command to request the info (/55 info Joe Smith)

I was hoping that someone with no knowledge of this attachment would be able to interact with it (and thereby learn of it's existance). But that looks like it won't be the case.


4. If there is no way to generate a Notecard, then is there a way to send text to the requesting player that can't be overheard?



Btw, Thank you for all the advice. I have dabbled in programming and scripting other languages, and I always learn best when I have a project in mind. Knowing the limitations I have to work within will save me a lot of dead-ending.

It might help if you stated "this is the end result I'm trying to achieve", if you can do that without disclosing more information about your project than you're comfortable with. That way, people here could recommend the best solution(s) for what you need to do.

> 4. If there is no way to generate a Notecard, then is there a way to send text to the requesting player that can't be overheard?

Yes. You can send an Instant Message to any avatar in the game, and that text will be visible only to the addressed player.

1a,b - One kludgy way around this would be to have the attachment be a large invisible box that completely encloses the avatar. Then someone "touching the avatar" would touch the box, which could then do whatever's needed. However, this might mean that no one is able to interact with the avatar in normal ways any more, i.e. right clicking may not bring up the regular avatar-specific pie menu. And that's probably not desirable, so I guess this isn't a very good idea. Never mind

You *can* have floating text above the av's head that says "touch my ass and something cool will happen"... Again, not sure if that's viable for you or not - how 'stealth' does this need to be?

Like I said, there are probably many ways to solve the problem, and you might get better suggestions if we knew what the problem was that you were trying to solve.

Well, the gist of it is in the Ideal Example I stated above.

Essentially, I want to allow players to set a list of items/options/whatever in an attachment, that another player can access freely. A goofy example would be to list your favorite colors. The player would write Red Yellow Blue Black White in a notecard in the attachment. Then someone who is interested in learning this, would retrieve this information. Preferably without neccesarily notifying the wearer, but ideally that would be an option. I want it to be as transparent to the wearer, and easy for the viewer as possible.

Any advice is greatly appreciated, But I think we're getting into the coding at this point and I can't, and shouldn't, ask any of you to write this for me. But I love talking theory ad infinitum.

Listens seem to be the only viable (albeit laggy) solution, I think. It can be hard to click on an attachment, especially if the attachment is small, and the avatar is moving a lot (say dancing), in a laggy environment (like a club). You could trigger it off of collisions, but then anyone who bumped into the wearer would receive this information.