LSL Protocol/Restrained Life Relay/gender

!gender

Not yet implemented

Description

meta command to pass the gender of the relay wearer to the device using the relay.

Effect

When receiving this meta-command, the relay must send a special acknowledgment that contains the gender of the wearer (to be set via a menu, or a chat command, or a notecard). The valid genders are: "neuter", "male", "female", "hermaphrodite".

Motivation

There is currently no easy way to know the gender of the avatars interacting with a device, short of asking their player via a menu. It would be easier if the players could give the gender of their avatar to their relay once and for all (either via a notecard setting, a chat command or a menu button: it's up to the relay maker to decide how the gender is to be set), then have the devices automatically adapt their actions and/or emotes to it.

Henri Beauchamp 00:21, 7 April 2009 (UTC)

Discussion

Please explain how !gender differs from the optional !vision extension. On !vision you wrote that you "agree 100%" that a relay should only be "providing gated access to viewer RLV commands". --Maike Short 16:04, 8 April 2009 (UTC)

!gender is an ***information*** passed from the relay to the device using it so that the latter can adapt its behaviour to the avatar interacting with it (just like !version, excepted that !gender is an information about the avatar while !version is about the relay itself). On the other hand !vision is an ***action*** that should not be performed by the relay at all in the first place, but by a RLV blind fold. !gender makes no assumption whatsoever about the form or attachment point of the relay, unlike !vision. Henri Beauchamp 22:05, 12 April 2009 (UTC)

I fail to see the why the it makes a difference whether it is a query or an action command in how it is related to the RLV . It is an additional command which require additional code unless it is optional. Of course it is possible to not implement !gender in the relay but create its own gender-query object like you proposed for !vision. This has the huge advantage that it can be used outside the BDSM community, too. Don't get me wrong: I am not against optional extensions like !gender. I think they are important to get specified so that different relays and world objects can work together. Otherwise we risk incompatible proprietary and perhaps even a fork. But I consider it very strange that you write on the vision page that you don't want anything that is not RLV related and then propose something which is exactly that (not RLV related) yourself. --Maike Short 00:11, 13 April 2009 (UTC)

There is currently NO way to know the actual gender of an avatar (and no, @getdebug_avatarsex does *NOT* work and I can't see how it would work in a near future since it would require server side changes: it is otherwise impossible to keep the gender over sessions). This is why the only solution left for now is for every and each BDSM device to ask it to its user. Alas, since many scripters are just too lazy, they would rather assume that the gender is female and go with it for their emotes (quite frustrating for male avatar players). Other devices are badly scripted and only allow such a setting via an option menu that the user cannot access easily. All of this is VERY user unfriendly. Since most modern BDSM devices now support RestrainedLife relays, the relay is a good place to offer automatic gender determination via a meta command (which will in turn encourage BDSM device makers to use it and make all their devices actually take gender into account). !gender does *NOT* duplicate a (working) function provided by normal RestrainedLife functions (unlike !vision, which is duplicating the function of a blindfold and makes assumptions on the relay itself), beside, should another RestrainedLife function be implemented later to change and keep the gender of the avatar in a reliable way, it would be a simple task for the relay to use that function in order to return the proper gender with !gender, thus keeping the backward compatibility with devices using !gender. As for non-BDSM devices: it is not our problem. We are speaking about RestrainedLife relays, here. Henri Beauchamp 07:59, 16 April 2009 (UTC)

 

Can this be done with @getdebug_avatarsex and @setdebug_avatarsex? --Maike Short 16:04, 8 April 2009 (UTC)

No, because @getdebug_avatarsex actually does not work properly at all (and @setdebug_avatarsex is not remembered over sessions either) and is actually only related with the shape used by your avatar (and mind you, my avatar is male, but I used a female shape for it. And I also saw "boyish" female Avs using male shapes)... Plus, "old" RestrainedLife viewers do not implement @getdebug. Henri Beauchamp 22:05, 12 April 2009 (UTC)

 

If the protocol is extended to read the gender, there should be a way to set it, too. The relay can of course refuse that, but it should be specified in the protocol right from the beginning, so that we don't need a later hacky extension. --Maike Short 05:24, 8 April 2009 (UTC)

No, the idea is simply for the device using the relay to get the information needed to adapt its emotes and/or sounds, and/or accessories (think of dildos and their different use for females and males...) to the gender of the avatar interacting with it, not to force some sex change (which sould be an ***action*** and should not be performed by the relay itself). Henri Beauchamp 22:05, 12 April 2009 (UTC)

I'd like to have a specification which is likely to stay consistent and compatible with future enhancements. We cannot see into the future obviously but some future requirements are predictable with a higher probability. If there is an extension to read the gender it is very likely that people want to set it, too. Especially keeping in mind that @setdebug_avatarsex does exist. We do not need to think about the details and all its problems until there is actually demand for it. But "!getgender" may be a better name than just "!gender". If we stick with !gender it may be a good idea to add: "If '!gender' is followed by a '/' the relay must reject it with 'ko' for now." --Maike Short 21:27, 13 April 2009 (UTC)

No. See my arguments above and below about setting the gender via the relay. Henri Beauchamp 07:59, 16 April 2009 (UTC)

Yes. It's useful and something that people ask us about on a regular basis. Absolutely Yes. --Ilana Debevec 03:19, 17 April 2009 (UTC)

absolutely SUPPORT having the device CHANGE THE SEX in the relay. Ever heard of 'transformation machines'??? Having a RLV enabled transformation machine that not only changes the sex of the victim, but could force wear the contents of a folder (shape, skin and 'attachments') and have them restricted on detaching/attaching anything would be a RP godsend... FEMALE > MALE, MALE > FEMALE, etc... and while we're at it, extend this to the 'species' I hear about... MALE HUMAN > FEMALE FURRY, etc... opens up a whole new dimension of RP here... I vote AYE! --Ilana Debevec 01:04, 14 April 2009 (UTC)

Transformation devices are only a niche in BDSM furniture. In any case, such transformations must be achieved via RestrainedLife commands (this is the whole point of the #RLV redirection of items given to the avatar, and yes it will be implemented officially in a near future). If you want (working) RestrainedLife commands to be implemented to allow to change and keep the gender (and species or whatnot), please, ask Marine for them, but is is *NOT* the task of the relay to change gender (or species or whatever): the relay is only there to pass @commands to the viewer, not to duplicate what can be done with them. Beside, even after a gender change (and yes, I do role-play a lot myself in this domain), the player might still want to see its avatar addressed with its original gender (since changing the appearance of your body does not result in changing your mind and personality), so !gender won't have to report a different gender in that case. Henri Beauchamp 07:59, 16 April 2009 (UTC)

 

First of all, People out there are using RLV for more than BDSM, shoot, BDSM is a Niche if you get right down to it. Secondly, transformation devices are NOT NECESSARILY BDSM. It's a fetish. I just took a quick glance at the groups with "transformation" and found about 50 reasonable sized ones (85 total, but some were quite strange, "Nader for President", now THAT'S a niche) with an eyeball membership total of 4,000 to 5,000... I'll take that 'niche'.Ilana Debevec 03:33, 17 April 2009 (UTC)

"ko" should be mentioned as valid response. --Maike Short 16:04, 8 April 2009 (UTC)

"ko" is the normal reply for any meta command that is not recognized by the relay. I know that most relays are not coded properly and never send "ko" for unrecognized and/or invalid commands... Mine does. Henri Beauchamp 22:05, 12 April 2009 (UTC)

It is still a good idea to list it as valid reply. There are relays out there which respond to !version with ko in some cases and world objects which whisper in public chat that your relay is too old because (integer) "ko" == 0. I expect similar problems with !gender if it is not spelled out that ko is allowed. And yes, I consider to let my relay default to ko, unless the user picked a gender. --Maike Short 00:11, 13 April 2009 (UTC)

I suggest instead to make it clearer in the specs that any unimplemented meta command must be replied to with "ko" by the relays. This will at least make it clear for every relay maker and will cover any future extensions of the set of meta commands. As for buggy relays and devices, it is up to their maker to fix the bugs: the specifications must not be amended/tweaked in order to make buggy stuff compatible with them. Henri Beauchamp 07:59, 16 April 2009 (UTC)

I disagree that relays are buggy because they ignore unknown meta commands without replaying with "ko". The spec says: "Notice that acknowledgments do not apply to the list of commands but to one command only. Therefore a list of N commands gives N acknowledgment messages in return (at most).". Note the "at most" part. Forcing relays to always replay with "ko" is a change to the specification not just making something clearer. It may be a good idea to do this, but this needs a discussion (not on this page but on its own). I further disagree that a new version of any kind of specification should totally ignore existing content. It would not be helpful to lure world object creators into depending on the "ko" when none of the commonly used relays send it. As I said it may be worth to require it for the next version of the relay spec, but this needs a hint that relays implementing an older version might not send it. Anyway, to get back to the point: I still think it is a good idea to add a hint that apart from the replies in the closed list, "ko" may occur for two reasons: 1) Even if my relay supports !gender I may want to reject it because I don't have the information, yet. 2) The target group of the spec are not people who are experienced in paying attention to every word while working with specifications so spelling things out does help. --Maike Short 18:12, 16 April 2009 (UTC)

LOL !! How outrageously dishonest... Trying to bend the words and meanings so to make them match your buggy relay "features" will not do it, I'm afraid. From day one, the specifications have been:

 o Messages from Relay to in-world object (4 tokens) :
    + message  ::= <cmd_name>,<object_uuid>,<command>,<reply> (cmd_name is equal to the one in the incoming message)
    + reply  ::= ok or ko or ping or <protocol_version> or <implementation_version>
    + protocol_version  ::= integer (it is the version of the specification, not of the script) 

There is no mention anywhere of ignoring a bad command and not sending "ko". Either the command is accepted and it's "ok", or it got a special reply and it's sent instead of "ok" (a "special reply" may also be a lack of reply, when explicitly specified for a command: !who is an example of command without a reply: this is why you can see "at most" in your citation), or it's not accepted/valid and it's "ko". Period. Henri Beauchamp 08:58, 17 April 2009 (UTC)

I fail to see how the specification of the format of message send from the relay to in-world objects imposes an requirement on when they are to be sent. In most cases specification are written to make things compatible. Therefore it is common practice to include an reference implementation to clarify things that might be in doubt (although I don't think there is doubt about ko not being required). Marine did provide an sample code with the very first relay spec you referred to (which did not have !who by the way). This sample code did show the exact same behavior that almost all relays still show today. To summarize: The spec does not require a "ko" response for unknown meta commands and almost all relays do not send it. Requiring this "ko" for unimplemented meta commands may be change that is worthwhile. But it needs discussion and be clearly marked as a change. There is an other reason for this approach: It is much nicer and more helpful to approach people with "we want to change this" than "your stuff is buggy because you don't share my interpretation of something that is not obviously spelled out in the spec". Oh, and please stop insulting me. --Maike Short 20:10, 17 April 2009 (UTC)

With Satomi's relay there is now one of commonly used relays that does send "ko" on unknown commands. --Maike Short 21:09, 18 April 2009 (UTC)

Would it make sense to have an additional reply for the grammatical gender beside that biological one? For example: "hermaphrodite/she". --Maike Short 01:12, 13 April 2009 (UTC)

Yes, it would. You could be a hermaphrodite but lean female.. so perhaps hermaphrodite/female, hermaphrodite/male, hermaphrodite/neuter --Ilana Debevec 03:33, 17 April 2009 (UTC)

It does not make sense to me, since grammatical conventions already exist (hermaphrodite = shi). Henri Beauchamp 07:59, 16 April 2009 (UTC)

My dictionary translates hermaphrodite into a word that simply means "having both sex". So it is unknown whether the male or the female part is dominating. --Maike Short 18:12, 16 April 2009 (UTC)

Had you frequented the MUCKs, MUXes, MUSHes and MUDs, you had known that their players have already well known and accepted conventions for herms (he/she = shi or sie or hir...). See also [1] Henri Beauchamp 08:54, 17 April 2009 (UTC)

There is no such pronoun in my native language, neither in the old days of MUDs, nor in current MMORPG, nor in the real world. We do have a suffix for nouns (like teacher, building worker, friend) referring to females, too. In English the amount of nouns that end in "man" or "woman" is very small and there are often neural forms like "police officer". So I can see why the development of the form "shi" does make sense in English. Unfortunately this does not help me we don't have something similar and the issue with the suffixes for nouns remains, too. --Maike Short 20:10, 17 April 2009 (UTC)

@gender is "just" a debug setting like any other... It is an integer variable that can hold any value, not just 0 or 1. I guess "hermaphrodite" and "shemale" can fit. Hehe. That's why I don't see why a !gender metacommand is necessary. It has nothing to do with this spec I think. Marine Kelley 18:16, 14 April 2009 (UTC)

Marine, @getdebug_avatarsex does not work... It is always reset on each login, and cannot be changed permanently with @setdebug. It would require server side changes, and this is beyond us. That is why we need !gender. Of course, you could add a persistent AvatarGender debug setting to RLV and have it retrieved and set with new @getgender and @setgender commands... This would make !gender pointless for all but "old" RL viewers. Another possibility would be to make AvatarGender a backup of AvatarSex (i.e. each time @setdebug_avatarsex is used, it changes both, and on login, AvaratGender is copied to AvatarSex in order to have @getdebug_avatarsex working properly) Henri Beauchamp 07:59, 16 April 2009 (UTC)

 

It'd be a useful command, and I like the idea of both get and set, because someone will want to do both sooner or later and I think it is wrong to try to limit extensions just because you don't like them. If they get community support, then add in extensions, particularly as they are all optional. I'd discussed this idea in IM with Maike and I think the ideal solution is to allow extensions using the !x- convention... and then list them all. That way a toy builder can use them or not, but at least we all know what's out there and have a standard way to do the same thing, even if the standard is optional. --Chloe1982 Constantine 15:22, 15 April 2009 (UTC)

The "x-" prefix Chloe mentioned is inspired by the internet message format used in e-mails, usenet and http headers for experimental header not officially defined. --Maike Short 06:00, 16 April 2009 (UTC)