Script speaking as owner?

Hey

I want to enable a script to speak as if the owner was speaking instead of the containing prim? The purpose is a remote control for 3rd party objects that are listening to chat commands and who would check/filter the owner key or the name of the originator of the chat command.

A friend suggested the use of gestures for realizing it, but on the one hand I have no idea how to play a gesture from a script. On the other hand, the text spoken must be freely configurable by the script, so I had to be able to change the gestures settings by script.

Do you have any idea how to make that possible, so that a script can say something (stored in a string variable) into a channel so that listeners would get the avatars key/name as originator?

I don't believe gestures can be triggered from a script and that llDialog is the only mechanism that a script can use that will 'speak' as an agent.

To make an object speak as the owner is reasonably trivial, Simple rename the object to the owners name when it speaks. The following example code is taken from the Hug script posted here.

SaySomethingNice() 
{ 
    // Switch the objects name to our name 
    string origName = llGetObjectName(); 
    llSetObjectName( ownerName ); 
    llSay( 0, "/me gives " + avTarget + " a hug." ); 
    // Switch the objects name back 
    llSetObjectName( origName ); 
} 

This would make it seem that the owner spoke but would only be their name not their Key. I dont believe there is a way of cloning the key in that manner.
HtH

Or if you are in the same area maybe an llDialog() on channel 0.

Thank you Newgate, that would do for the name.

Still there is the problem lefts, that sometimes the key is checked instead of the name. But the name hack might already be good for most cases.

Resolver: llDialog is no real option, because the chat text would appear on the button and the button would have to be pressed. So not the script would say something, it could only present the ownder a button to do so. On the other hand, better then nothing.

Yes thats true but its the only way to fool a listener that is filtering on your key.

Its not even 'fooling' it because it is you speaking.

Siria Wilder, what is it you are actually trying to do? There may be a better way to approach the problem.

Which methods have the _color_ of the chatted text "normal"? Only llDialog?

I seem to recall that objects would speak in a different color?

The colour is dependant upon the client settings, but yes objects speak in a different colour to Avatars.

lLDialog will generate 'normal' coloured text.

Newgate:

The purpose is a flexible remote control for other scripter's scripts, worn by other people. The other scripts react to chat commandos in 0 or other channels, but will check who originated it, to only react to the proper owners. As long as only the name is checked, your renaming-solution might work, I will check that out for some. But I guess, that if the scripters took care of security, this name hack might be prevented by checking the key of the originator.

hehe... here's one I built earlier: http://slexchange.com/modules.php?name=Marketplace&file=item&ItemID=182010

...and llDialog is the only way I could find to get this to work

I'm not sure I even understand the scenario you're describing but I'd expect that 90% of scripter would have created their scripts keyed only to their owner, i.e.

llListen(Channel, "", llGetOwner(), ""); 

Unless of course they are expecting the system to be used in the manner you are suggesting.

If the objects are explicitly keyed to the owner then the only way will be via the dialog system.

Hi Pale

Yes, your hud is a good example. I am trying a very different approach in organizing the dialogs and their flexibility, but the end result is the same for many purposes. And *sigh* I am already trying to get used to the idea that dialogs have to do the chat on their own instead of triggering my own chat control, which means only one channel per dialog and the chat output displayed in clear text. But, as you and Resolver stated already, it is still better then typing. I just wanted to provide too much convenience and it's hard to come down to what sls allows then.

The most annoying thing is, that I have to drop the idea of own chat commands to emit the menu's chat commands directly. This might sound silly, but would have made sense in my context.

One short OT question: It seems like you allow submenus, but with freely configurable buttons. Do those menu-calling buttons have to use unique names or did you manage to keep track of which menu was clicked onto? If yes, this might become stuff for a new thread.


@Newgate

I follow the same base idea as Pale did with his hud. Going away from learning many different chat-controls for different attachments you wear, or that are attached somewhere else and would react to your commands, if they identified your avatar as the originator of the chat command.

err, may be its just me but why??
Its far easier (to me) to type than to have to click & navigate through half a dozen menu's.

I think one of the reasons you're finding alternatives difficult to find is that being able to impersonate an agent could have huge security implications - hence my HUD device quite clearly states that it will only control products over which you have legitimate rights. A dialog can only impersonate the agent that has it on their own screen.

BTW, the chat output is only displayed if it's on channel 0.

All buttons need to be unique within each menu. The HUD script tracks what menu was last displayed, what 'words' are commands, and what 'words' are menu requests (and the menus they link too). Indeed, the HUD script is only really 'aware' of the current menu as it literally shifts all of its active variables to reflect the requested menu - basically, the HUD script is a very tortured exercise in juggling lists, handling the menus, once displayed, is the easy bit.

But a script has absolutely no control over a dialog once it's launched. The dialog says whatever is on its button on whatever channel it's tied too. Therefore all button pushes are sent on that channel and anything listening on that channel will hear. So, while a 'menu' button can be interpreted by the HUD script to display the new menu it will also trigger the third-party script if it is also one of its own command words.

...I can't even remember the commands to all the gadgets, let alone type them straight and then combine that with also typing people's names - did I mention that the newer version also allows you to, real-time, target and substitute names into the menu buttons?.

To put it quite simply its called GUI Newgate. You know that lovely bit of point and click stuff that Apple developed (and Microsoft copied). People are not comfortable necessarily with typing commands as scripters are ... most programmers work with command line stuff all the time but the regular Joe does not. To have something to click on is often a lot easier, albeit it might be slower, than typing commands. Thats all

Yes I agree GUI's are quite nice for complex/arcane items but I've not foudn anything in SL that warrants it. I think its actually its more to do with laziness. Why remember stuff if I can just click a button.

Just have your script use the dataserver event to establish the owner of the object and set a varaible as OwnerName.

then have your listens setup to listen to OwnerName, and not their UUID (since the dataserver has authenticated the name from the UUID already).

In this way, the objects can even change ownership and be reset to the new owners.

You have overlooked that the whole idea is to be able to control scripted objects to which we do not have access to the script, i.e. we cannot modify the script to do this, instead we are supplying the data to it as it expects it from its owner.

The other problem with your solution would be that I could easily spoof your objects, one of the reasons for the UUID protectionism that Pale mentioned earlier.

Well you've just answered your own question..... GUI's were invented because people are naturally lazy and prefer things made easy for them. Thats why computers started selling well because people could use them "lazily" instead of having to take courses or spend months getting to know command lines.

Also, if people can use menus instead of commands, it makes them more willing to buy an item. Hell, if it comes right down to it, you can include both options ... menus and voice commands .. whats stopping that ... just make sure the person uses the voice commands on the same channel as the llDialog listens...

GUI's were also a breakthrough for disabled people who cannot type or struggle to type. So if you are keen on hitting the majority of your market ... menus are great ... if you want ultimate ease of use for any kind of person ... just use both.

I honestly think that even if you have the capability of using the menu's for even a two-button purpose it is 100% warranted.

Oh .. and I know some great user interface design specialists you can contact who would reiterate everything I have said

Now I can agree that there are some things that use dialogs that really don't need to.

I can give you several reasons I prefer to use Menus over typed commands, however.

The highest on that list is controlling listens. I've never liked just leaving listens out there running, even if they are on a channel other than 0. Sometimes I have things listening to other objects for complex strings, so keeping the listens that aren't needed at the time off is fairly important to me.

The other main one is, at least on my ships, I have so many options on them in regards to remote control, guest modes, flight modes, warp controls, etc....that it would be hard for anyone other than myself to really even remember them. The warp controls alone have a full dialog menu of choices.

I've actually added an updater on the newer vehicles just so I can continue to add options to them as I go, and some of those would be new menu options.

Last main reason for me is, since I build ships (meaning I also fly them alot), both of my hands are normally not on the keyboard since I prefer to use my 'flight mode' (mouselook). Having to move to type in a command would leave my my ship rolling out of control until I finished the command. Granted I type fast...but still....it's just so much more convenient to throttle back, move out of mouselook click 2 or 3 times and then roll back into mouse and go.

As I said, this is probably a more unique condition as not everyone is a vehicle scripter, quite a few vehicle builders just use ones they got from friends/freebies/etc. Hell, a large majority do not get anymore complicated than just typing Start or Stop.

Oh dont get me wrong, I'm one of the strongest advocates of tightly constrained listen's, and well constructed / flowed dialogs. I'm just not an advocate of making a hud just because I can or not using my brain to remember things. The original posting was concerning 'universal remote controls' and to my mind it would seem that if ppl cannot remember what an item is for, or its syntax, then they probably shouldnt be playing with it.

To have an object listen to only your objects, just do

listen(integer channel, string name, key id, string message)
{
if (llGetOwnerKey(id) == llGetOwner()){
dostuff...
}
}

when you set up a llListen(channel, "", NULL_KEY,"";