#1 - Proposal for @tpto IM command

[KittyBarnett]

This proposes an extension to the RLVa IM command set, introducing @tpto as a force teleport command that allows the sender to teleport the recipient to a specified location.

This functionality mirrors the existing @tpto:=force command but integrates it into IMs, allowing unscripted forced teleports (as permitted by other restrictions and when the sender has been added as an exception to the relevant behaviour)

[DarlCat]

So to my eyes the proposal nor the PR note address this, but would this in theory allow object llInstantMessage calls to the agent based on object owner ID be run? If so this could be great for use cases like keeping leash continuity across teleports without side-channel comms to handle the teleport destination coordination.

[KittyBarnett]

So to my eyes the proposal nor the PR note address this, but would this in theory allow object llInstantMessage calls to the agent based on object owner ID be run? If so this could be great for use cases like keeping leash continuity across teleports without side-channel comms to handle the teleport destination coordination.

As currently proposed, no, it wouldn't. But it's an interesting idea though.

Can you elaborate who would be teleporting whom though? The intented problem I wanted to solve with this is that when the Dominant has a destination in mind they can send the s/type ahead, then request a teleport. Or the Dominant can send them somewhere, without having to teleport there themselves, then offer a teleport, and teleporting back to wherever they were.

[DarlCat]

That intended problem and solution is valid! Upon reading this RFC however I saw a use pattern where a leash holder item could store the UUID of the submissive resident or residents it's connected to, and when the dominant wearing that leash holder item teleports that could be detected with the changed event's CHANGED_TELEPORT flag and an llInstantMessage could be sent to the leashed submissive's viewers which would, by way of the leash holder wearer's UUID being an accepttp entry, it would be acted upon since the owner of the object would be readily available information.

To my knowledge this would be the first time that RLVa accepts commands directly from objects owned by another agent than itself, but I see it as having little difference in practice when compared to the accepttp exception as it currently exists. It just allows that effect to be automated and work without being a thought for either party involved.

Alternatives to this idea right now involve the leash holder item and collar item having their own direct communication with each other, often involving external servers as a dependency and raised barriers of entry to more integrated experiences.

[KittyBarnett]

That intended problem and solution is valid! Upon reading this RFC however I saw a use pattern where a leash holder item could store the UUID of the submissive resident or residents it's connected to, and when the dominant wearing that leash holder item teleports that could be detected with the changed event's CHANGED_TELEPORT flag and an llInstantMessage could be sent to the leashed submissive's viewers which would, by way of the leash holder wearer's UUID being an accepttp entry, it would be acted upon since the owner of the object would be readily available information.

Ohhhh, I get it now, so it's not dependent on the Dominant even using RLV(a), it's their leashholder that would do the work. I do like it!

To my knowledge this would be the first time that RLVa accepts commands directly from objects owned by another agent than itself, but I see it as having little difference in practice when compared to the accepttp exception as it currently exists. It just allows that effect to be automated and work without being a thought for either party involved.

Yes, and for that reason I'll make it its own separate proposal. And thinking it through will help with some of the issues that I can foresee already, but I think they can be mitigated as well.

---

Thank you so much for your comments, this is exactly what I was secretly hoping doing it this way could accomplish where one idea just inspires another and everyone can talk it through and you end with something even better in the end! 🙂

[ChloeConstantine]

I won't comment on the use of llInstantMessage until (or if) that turns up as a proposal. As DarlCat has stated, it is the dom's leashholder that does all the work - that's what I do for the few devices that have my new leash script.

On the proposal as written: don't forget about @tplure which I think would add to those who can force TP the sub.

I can't imagine it ever being used, but should the IM @tpto also accept global coordinate?

If you're going to add an SLURL in the IM-based @tptp, then I think it would be good to also add one in the llOwnerSay version of the command.

[KittyBarnett]

On the proposal as written: don't forget about @tplure which I think would add to those who can force TP the sub.

In my mind, this replaces someone teleporting someone somewhere and then sending a teleport offer to the user... if they're an @accepttp exception (or if the user has @accepttp=n set) then they'll never see the teleport offer and get auto-teleported over.

Assuming of course that they're either not @tplure restricted, or the sender is a @tplure exception.

But it's @accepttp that's ultimately responsible for getting auto-teleported?

That does bring up another question though; because I initially saw it as a shortcut for a teleport + offer teleport combination, it made sense in my mind to have @tplure=n (without the sender being a @tplure exception) block the teleport.

But that doesn't really make much sense when you take a step back... so:
(1) test for @tplure (or exception) and have it functionally equivalent to a teleport offer
(2) test for @tploc because that's how the @tpto=force command checks it

It probably has to be (2) though (which means that that sittp and tplocal come into play).

I can't imagine it ever being used, but should the IM @tpto also accept global coordinate?

There's not really any work in doing it, but I agree it wouldn't really be used.

If you're going to add an SLURL in the IM-based @tptp, then I think it would be good to also add one in the llOwnerSay version of the command.

I'm not sure I was going to do SLurls, and was going to do the Region/X/Y/Z which @tpto supports to, but that's a good ask that won't really require much work at all, and people get SLurls from everywhere so it might make things easier.