Skip to content

#1 - Proposal for @tpto IM command #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

KittyBarnett
Copy link
Owner

@KittyBarnett KittyBarnett commented Feb 10, 2025

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)

@KittyBarnett KittyBarnett changed the title Draft proposal for @tpto IM command #1 - Draft proposal for @tpto IM command Feb 11, 2025
@KittyBarnett KittyBarnett changed the title #1 - Draft proposal for @tpto IM command #1 - Proposal for @tpto IM command Feb 13, 2025
@DarlCat
Copy link

DarlCat commented Feb 20, 2025

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
Copy link
Owner Author

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
Copy link

DarlCat commented Feb 21, 2025

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
Copy link
Owner Author

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
Copy link

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
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants