llGetGender()

How about llGetSensitivity()?

I'm recommending llGetALife() for everyone here.

llSetGrumpyParams()

er, I forgot the smiley.

1) I want llSetGender too.

2) As money is the only thing motivating Lindens then skip llGetGender and go directly to llGetDemographic. They can run surveys to find out who we say we are and what we think. Couple that with tracking purchasing history (since you bought that steampunk dress, you'll love this 1875 era hat). Heck, couple it with real world purchasing (since you bought that thoroughbred horse how about this Amazon link to the latest book on horses).

please no....

I'd be happy to see it with a simple drop down, on the shape properties. but a scripting option? that takes it out of the realm of the average user, and places it with unknown scripters.... to randomly change at their whim.... regardless of the av's desire. and adding confirmations or dialogs would only complicate it further...

as for that other thing...
you really think LL is gonna share all the data they already mine from you? hah!

I should have added a tongue-in-cheek emoticon to
my post to make that obvious.

(But riffing on your serious answer, a function can always be made to ask permission. More tongue-in-cheek: RLV could implement something
like this for forced sex changes

I've not heard a good reason why pose scripts can't ask the user/controller the animation gender they prefer.. Not only do I NOT have to script around things the lindens can/will do wrong, but it allows the users to adapt to the options presented. I have no objections to answering the questions a furniture maker might want to ask to improve the functionality.. and yes.. feel free to ask me when I'm furry, tiny, neko, and even alternating genders.

The Lindens cant come to grips with Age Verified VS. ADULT and that's NOT something users are supposed to be able to change at whim I don't even wanna see the derivative works where subsequent calls can determine the type of "devices" attached at particular attach points....

Scripters who WANT to depend on it are not going to solve the root problems of people not understanding what this esoteric flag thing is, who set it "wrong", and not being willing to spend hours looking through a forum to figure out how to "fix it".

The RLV api in fact gives "@setdebug_avatarsex:0=force" as an example of @setdebug (" Forces the viewer to change a particular debug setting and set it to < value > ".

What practical effect "@setdebug_avatarsex:0=force" might have beyond me, since the neither changing your avatar's gender in debug settings with this command nor changing it there manually changes your avatar's apparent gender -- only changing it in the appearance window does that. But it is there.

What about this ball?
/13/a9/5351/1.html

Want a full list of it's friends?
https://jira.secondlife.com/browse/SVC-1636

I hate to be a damper on this but this topic has been done to death. However you are welcome to do it again.

How about doing it right?

http://jira.secondlife.com/browse/SVC-1115

damn, posts all the way back to 2003?!? too bad we can't search that far back anymore...

best I could do was this gem from 2005...

default {
    hit_on(integer numBreathing) {
        integer breathing;
        key me = llGetOwner();
        for(breathing= 0; breathing< numBreathing; breathing++)
        {
            key victim = llDetectedKey(breathing);
            if (getSex(victim) == SEX_FEMALE) {
                if(!isCatGirl(victim) {
                    llGiveInventory(victim, "Sexy Cat Girl AV");
                    llStartAnimation("wink");
                }
                if(isPerfectInEveryWay(victim) || isCatGirl(victim) || isDesprate(me))
                {
                    inviteOverToPlace(victim);
                }
                llExchangeCards(victim);
            } else {
                cringAt(victim);
            }
        }
        list victims = getVisitors(house);
        while(breathing = llGetListLength(victims))
        {
            while(breathing--)
            {
                key victim = llList2Key(victims, breathing);
                if (getSex(victim) != SEX_FEMALE)
                {
                    beatUp(victim);
                    victims = llDeleteSubList(victims, breathing, breathing);
                }
            }
            if(llGetListLength(victims) == 0)
            {
                goToClub();
                return;
            }
            sleepWith(victims);
            llSleep(12 * 60 * 60); // 12 hours is enough.
            victims = getVisitors(house);
        }
    }
}

(which settles my mental cabbit debate about least likely offensive pronouns... but not until the very end...)

I just watched a television show about intersexed people yesterday, and it was quite enlightening and interesting. Society teaches us from birth that there are 'boys' and 'girls', yet, due to various genetic anomalies that can and do happen, some people are born outside the black and white of simply male and female. This seems to bother those that are intersexed that society doesn't come to grips with it and recognize that not everyone fits fully into one category or another, and, at the same time, people with smaller brains can't seem to wrap their head around the fact that this is true, and shun those who are different.

The purpose of this thread was two fold, one, to have a dialog about actually getting the function, and what those who would use it might want to see (or not see) within the function so I could carry that information back to the office hour meetings, and secondly, to show how much hell would break loose if the function were to happen.

Unfortunately, the misunderstanding, anger, and hatred that's appeared in this thread happens just as much in the real world, and real people with real lives are affected, sometimes in a negative way. Perhaps our society will come to grips with the situation and begin to work towards making better decisions when it comes to dealing the intersexed child births, and old ways and ideas about dealing with it give way to more sensible thinking.

Depends on which RLV implementation you're using .

"AvatarSex" isn't actually used in the viewer code (anymore) and only ever still gets set when you go into appearance. So when you log on it'll always be set to 0 (which is female). And whenever you go into appearance the viewer will always set it to whatever gender your shape is, regardless of what changed it to manually.

If you're using regular RLV (or Cool SL): @setdebug_avatarsex:1=force would set the AvatarSex debug setting to 1 (=male).

However if you're wearing a female shape and go into appearance then the viewer will reset "AvatarSex" back to 0 (=female).

Which is why in RLVa (Emerald, Imprudence, etc) I don't actually mess with the debug setting at all but merely spoof it. If you never issued @setdebug_avatarsex then it'll return the gender of your shape; if you issued it once then it'll keep returning whatever number you set.

This is a worrisome idea.

What about same sex couples?

If you start scripting pose balls to do special things depending on the gender and exclude the idea that same sex couples may be using your items then you are really just making things harder for people.

No one wants to sit on an dance ball set and have it auto-detect their gender as female though they wish to use the ball as a male.

This works fine in a pure hetero-setting SL, but SL is far from hetero. If product makers included special coding so that these objects could be set to act male/female regardless of the GetGender() return then that would be acceptable, but there is nothing to compel content makers to do this however and i suspect that most will not.

GetGender() if it is going to work needs to work by a flag box check in our profile or something that sets the internal gender regardless of what a persons visual gender indicates.

It wouldn't always work fine even for the hetero dance ball example.

It's not always the case but in general couple animations look best if the tallest avie jumps on "male" and shortest one jumps on "female" regardless of what gender they actually are.

If the girl is taller than the guy and the dance ball would insist on playing "gender-approriate" animations based on llGetGender then the couple's feet wouldn't be anywhere near the same level whereas it might look perfectly fine if they simply reversed animations.

That's why it shouldn't be anything more than an arbitrary and uncontrolled string, so that scripters have to deal with the edge cases: gender not set, gender set unreliably, gender set to something poetic or amusing like "stallion", ... that's what works on MUDs, and that's what my proposal is about.

http://jira.secondlife.com/browse/SVC-1115

Well Briana, even in same sex situations one has to pitch while the other hits... Dance pose balls would have to be scripted for same sex operation anyways I guess. Even with same sex couples, doesn't one lead? Don't know how that works, but, from what you're saying, it's starting to look like you'd need another function... llGetSexualPreference() or something along those lines... Perhaps if a poseball detects two same sex partners, it could prompt for the person who leads.

It's posts like these that make me wish you could mute forum users. So I must be a predator and a sexist because I can see uses for this. Possibly even racist because I could easily think of uses for scripted color-matching of skintone.

Thanks for pointing out all my flaws Nika.

I have a female avatar, but I almost always use "male" AOs, animations, sits, clothes etc. because the masculine body language and styling are much more suited to my personality.

My concern with llGetGender() is that designers will simply assume traditional, conventional alignments of female = feminine and male = masculine in using this code component. That's basically the intent: to automatically provde the "correct" behavior that they believe is appropriate for a man or woman. And unless there's some kind of opt-out feature, I would find myself continually ambushed by animations and sits that were really out-of-character.

For instance, I can imagine an auditorium with seating anims using gender detection. Very convenient for about 95% of the audience, but extremely uncomfortable for me, given that so many animations for SL women are on the extreme end of simpering or prissy.

I'm an admitted minority in this regard, and there's only so far I could expect the SL majority to care, much less cater, to my experience here. But it does have the potential to erode mine, so I'm not jumping for joy over this proposed "improvement."

no, no not really...

I don't think Bri is saying it's not useful, she's saying it's not useful unless it's settable independent of mesh.

then if some scripter decides to code male = lead, any couple can set what they like for automatic decisions...

I'm not so sure about Argents idea... completely free forming it would make it pretty much useless as a tool, especially given the poor matching tools in lsl.

I say simplicity in design, variety in choice. most cultures accept two, regardless of other options. other options make up a minority of cases, even considered together, so they can fit neatly under an umbrella "not listed"...

So long as you don't let 'llGetSubString(llToUpper(gender), 0, 0) == "F"' unless you want to be seen as female, or 'llGetSubString(llToUpper(gender), 0, 0) == "M"' unless you want to be seen as male, you should be OK.

More importantly, it will let people code for 'llGetSubString(llToUpper(role), 0, 0) == "D"' or 'llGetSubString(llToUpper(role), 0, 0) == "S"' if they want to.

Or 'if(llToUpper(species) != "ELF" ...'.

It provides everything llGetGender() would, without tying people down to either of the standard options, and so much more...

Another possibility, based on my proposal, would be for your poseball to do this:

string preferred = llGetAttr(avatar, "pose_style";
if(preferred == "" {
llDialog( what pose would you like )
}

...

listen(...)
{
key avatar = lltAvatarOnSitTarget(); // ...

if(msg == "Male" llSetAttr(uuid, "pose_style", "m";
else if(msg == "Female" llSetAttr(uuid, "pose_style", "f";
else llSetAttr(uuid, "pose_style", "n";
}

so you won't code for man/woman, girl/boy, xx/xy, daughter/son, or any other variation that may feel natural to the person typing it in? and that's just the two most common categories...

No. The only time I've run into anyone using something like that in a MUD/Muck/Moo is when that person wants to let *humans* know what they are, but doesn't want scripts to know about it.