Add a mechanism to have a text chat conversation with an object
tracked
Simon Linden
This would be useful for SL pets and bots.
I would like to be able to right-click on an object, and select "Chat" or something similar. Then a tab/window would open similar to local, group or ad hoc chat. This would need some form of marking to discriminate it from an avatar chat.
Messages I send in that window would be heard by the object (and all prims) but no others. The object scripts would be able to send messages to that window via llRegionSayTo(). If that window isn't open, the messages would be delivered in the current way llRegionSayTo() text is shown
Log In
Darling Brody
Perhaps something as simple as being able to rename the touch button to chat. then the script can take over by giving you a dialog box etc. We can rename the SIT button, often to Teleport, so being able to rename the other object interactions like Touch, Etc might be useful.
Then you could right-click the object and select "CHAT" which is the renamed TOUCH button, the script can call llDialog() in the touch_start even to allow you to give some input.
I would like it very much if we could set the line length and higher of the llDialog() text input boxes to make them more useful, and be able to have more information in their header too, as that is useful for giving feedback from the last dialog box to be submitted. With this change you can probably implement your chat bot using existing functions.
Sugar Cookie
llOfferChat( key target_resident, integer response_channel, string user_message, string accept_message, integer flags )
This would start a dialog (like all the others) asking the target resident if they'd like to start a chat with the named object with the provided message. If they accept, a new chat tab opens with the object and the object is sent the accept_message on the response_channel. This feedback lets the script know the resident has opened the chat. It can then send the first message.
After that, anything the user types in that new chat tab will get sent to the object on the response_channel where a listen handler can react to it.
Bonus points: Cooldown on using this command again to the same resident.
llSayToChat( key target_resident, integer response_channel, string message )
This is how the object continues to talk to the resident in the open chat. It will return true if the chat message was received by the resident, or false if the resident has closed that chat tab. Sending a blank message string won't add a blank message to the chat, but will return that true/false return value -- this way the script can check if the user is still in the chat.
Back End: his would require a new user-to-obect-on-channel communication type. How radically different that would be from existing communication protocols would have to be determined.
Advantages: By using a dialog to open the chat, it prevents large numbers of objects from spamming a resident's communication window by opening unwanted tabs. Only communications accepted by the resident can open there.
It leverages the existing listen channel system, only needing new functions for the initial opening of the chat, and to chat to a specific resident.
It allows for terminal-like interaction with a script, either for chatbot-like interactions for for typed commands.
By using both resident key and channel number, multiple chats with the same resident can be possible -- if the player agrees to such.
The flags in llOfferChat can be used to add future features, such as flagging if the script will allow the user to add other residents to the chat (using the existing group chat feature) or not. Such a group chat would make translation bots handy for private communications, and potentially allow scripts to act like Discord chat bots to add features to group chats.
Sugar Cookie
Super Bonus Feature: To provide for escape sequences in the message text that create hyperlink-like clickable text in the object's chat messages. When clicked by the resident, it sends a string back to the script. I can think of several ways this could be implemented.
Simplest: Surrounding a bit of text in [[ and ]] turns that text into a link that sends the text itself to the script on the same channel -- simulating the resident typing that string themselves.
Would you like to play a game? [[Yes]] [[No]]
More Complex: Including alternate text and a different response channel to send the selection to that are not displayed.
Would you like to play a game? [[Yes||yes-game||1234]] [[No||no-game||1234]]
This would provide an alternative to button dialogs with different features and use cases, and it would make interactions with the script more streamlined and less prone to typos than a simple terminal interface.
Gwyneth Llewelyn
Hmm. I have a few questions. How exactly would the object
listen
to this 'special chat'? Would it need to open a new type of listener, with new events to handle? A bit like linked messages, which are different from text chat these days, and require their own special handling? Or would this be just a 'special' channel which would only work with that specific prim (like we have PUBLIC_CHANNEL
, DEBUG_CHANNEL
and COMBAT_CHANNEL
, we would now have an OBJECT_CHANNEL
)? That way, it could be processed in the same way as other messages are processed (although I have no idea how to handle that), but without the hassle of setting up message filters as Woolfyy Resident mentioned.Then I guess there would have to be a way of stopping the chat (right-click again, now it has a new entry saying 'Stop Chat'?).
Hmm. And what about
automatically
initiating such a chat without
the need for an avatar to touch the prim? No, wait — we already have that, it's called llInstantMessage
! However, objects cannot receive
instant messages, just send them... so... what you're effectively suggesting is a way to send and
receive IMs?It would actually be cool to simply have objects listen to instant messages as well — that way, we wouldn't need
another
layer of communication, we would just have a setup function such as llListenIM()
and then we'd catch the IMs on the normal listen
event, but pre-filtered, in the sense that the key would be the avatar, and the channel would be OBJECT_CHANNEL
.That would allow existing code to continue to work, while allowing a new way of communication with the object — sending IMs to it.
Gwyneth Llewelyn
All right, that would be the LSL side of it — simple to understand (but I suppose it would be non-trivial to implement), fits into the existing scenarios with little fuss, and works under a different mechanism than text chat — one that is already implemented with the way
llInstantMessage()
works today.The possibility of automatically sending instant messages would also allow, fr instance, attachments on the same avatar to communicate with each other. With some extra tweaking,
llInstantMessage()
could be sent to an object UUID, thus adding yet another way of sending messages between objects across the grid. Currently, the only ways I know to do that is either by using email-to-a-prim (which is prone to failure and hard to debug, since email messages don't report back to the sender if the object did a successful delivery or not) or using HTTP-in and HTTP-out (tricky, too, but it should work; I have never tested it out). Both are orders of magnitude slower than intra-object communication via linked messages, but they are also slower than using 'normal' text chat. llInstantMessage
, however, using a different mechanism, might
be able to deliver messages at a faster rate (and objects sending IMs are already subject to a lot of throttling and restrictions) — although there are some caveats (see PS below).Now there is the UI side of it.
Changing
the text for the touch menu link is trivial — several objects already do that — but I guess that's not quite what you had in mind, but rather a way to signal the object to launch its 'special' communication channel. Thus, 'Sit' and 'Touch' trigger distinct events from 'Chat'/'Stop Chat'. I believe that one way of consistently dealing with this is to request permission from the user to initiate communications, e.g. checking for PERMISSION_CHAT
or something similarly named. When selecting the 'Chat' option for the first time, what the user is doing is effectively to grant those permissions (and, conversely, 'Stop Chat' would revoke them). Once granted, it would happen the same as with the common pose stands (or most of the chairs/couches being sold in SL), which are activated upon sitting. The first
time a resident sits on a pose stand, it requests permissions to animate the avatar, but once granted, the avatar will always be animated, every time it sits down on the same chair.Gwyneth Llewelyn
Note that this is nowadays the 'typical' way of having objects interacting with avatars, and would therefore make sense to replicate for this suggestion, according to the Principle of Least Surprise 😂
---
P.S. I voted this suggestion up because it looks like it's important for the scripting community. Strictly on a personal note, I'm not sure if the actual
implementation
of such a service would not be precisely a filtered stream of message data, using the same queues and mechanisms already in place today. In other words: this would be nothing more than syntactic sugar for the benefit of the programmer writing LSL (the code would possibly be simpler, easier to debug, etc.). It would not
make things magically 'better'.My own proposal to use instant messages for inter-object communication is also very problematic. The instant message queueing system assumes that humans, at their own rhythm, are exchanging messages among themselves, and that objects, at best, can send
some
spam to humans, but that's throttled to the extreme. If objects communicate with other objects at the frequency and speed of linked messages, this risks flooding the system to the point that humans
get excluded from sending IMs to each other — all within the boundaries of the existing limits and throttles. So it's not an alternative, either. On the other hand, adding yet another similar-looking type of communication just for a very specific use case seems like overkill to me — we already have plenty of modes of communication. Do we really need another one?Gwyneth Llewelyn
Woolfyy Resident hmm and where/how would you throttle this down, in order to prevent abuse?
nickvrtis Resident
This would also help with some more flexible input dialogs for scripters. With Natural Language becoming more available, something more flexible than Dialog boxes would be a nice addition.
Kyle Linden
tracked