llGetSex()

Again, a dialog box is enough to implement differentiation.



Dialog boxes to the rescue again:
Have a sensor in a specific place in your store, perhaps the door, that pops open a dialog box with the text: "Hello, we're conducting an informal survey of our customers' gender. Please select a gender below." With options for male or female.

If a customer did not want to respond to the survey, they could simply click "ignore".

There are no more practical uses for this because there are too many ways this function could be used to segragate unnecessarily.

I challenge someone to come up with a scenerio in which an llGetGender function couldn't be replaced with a simple dialog.
==Chris

Maintain two versions?

Wont you have to do that even if this function is implemented?

if (llGetGender(user) == MALE) {
    // Do manly things...
} else {
    // Do womanly things...
}

vs.

listen(integer channel, string name, key id, string message) {
    if (channel == SEX_DIALOG_CHAN) {
        if (message == "Male") {
            // Do manly things...
        } else {
            // Do womanly things...
        }
    }
}

Maybe I'm misunderstanding, but I got the impression the solution for maintaining only one version was going to be something like this:

if (llGetGender(user) == MALE){
    // Do manly things...
} else {
    // Do NOT DO womanly things...
}

It'd be simpler.

Isn't that getting a little anal?

No, I dont think I will. I think they will appreciate it when they see it. Hopefully enough to modifiy it themselves and put their own sounds and anims inside.

If it offends people because it makes a girly noise and they prefer their female av's to make manly grunts - to the point where they don't want to use it? I don't want them playing.... I'm here to have fun, not for "customers".



It's about maintenance, organization. Not ease. I'm not making two physical shapes Michi. I'm making one generic object that needs to play the right sound so it can deliver the right kind of presentation.

The dialog is a hack that would take away from the effect. I want the choice of anims and sounds to be behind the scenes so it comes as a surprise.

I'll get more LOL's with this function than I would with a dialog. Plain and simple.

What's next? llGetPouchSize() and llGetBreastSize()? For the sake of the LOL, right?



I'm afraid you're not going to have many with that attitude.

As Christopher said, the difference between llGetSex() and llDialog() would be almost nonexistant as far as coding goes.

Or maybe to get attachments to fit right. Unlike yourself, I don't see how llGetBreastSize could be funny.




The people who wouldn't play the game because of my attitude are EXACTLY the people I don't want to play the game. I'll tell you what though, just in case,

list foo = ["Liam Roark", "Arito Cotton", "Christopher Omega"];
if (llListFindList(foo, (list)player) > -1) {
sound = "loudassfart.wav";
}




llDialog is a hack. The code is different, and the presentation is lacking.

Wow, thanks, where can I purchase one of these?



The code is different, yes, but not drastically so. I fail to see how it could be construed as a hack; llDialog is a great way to present a user with options and retrieve responses without affecting others (see Fran's Frantastic Turbo Jetski).

Presenting consumers with choices will always be better than forcing your choices upon consumers. Why? Different people like things in different ways, as our antics in this thread can prove. You may very well get the three of us (who are listed in your fabulous code above) to purchase your product if you simply provide us with a choice. Not doing so is ensuring that your product has a short lifespan, a limited appeal, and a poorly received launch.

At the risk of sending this thread farther away from topic, it might be worthwhile for you to explain what you're trying to make or create, Jack. Maybe someone could provide an alternate solution or an angle that you haven't explored.

I would see a use for this in welcoming scripts. 'Hello, Sir. Hello Madam.' kind of things.

It doesn't bother me that it doesn't exist, but it would be useful for more than just exclusion.

I just want to get the AV sex. I don't want to prompt them with a dialog. I have to hack it with a dialog at the moment, I would prefer not to do this.



I like the match maker machine that Trimda Hedges created. 20 dialogs and she could eliminate one of them if she had this function. Even though I tried Trimda's matchmaker, I still need llGetSex()




This isn't about choice. It's about presentation. If they really want their girl av to make a grunting noise, they can modify the object.

And again, I'm am not targeting consumers. I'm not making a product for sale, I'm making something fun(hopefully) that will be free and modifiable.



Nope, top secret until I work out the projectile equations. There is no alternate solution.

AV sex is a radio button in the game. If you want it changed to check boxes, start a new thread. All I want to do is load this value into my script without being REDUNDANT and forcing a dialog. I can already check someone's birthday, their dimensions, their ratings, why not their sex?

Because birthday, height, etc, don't have a set of preconceived ways folks should act.

Your use of this function may indeed be benign, Jack, but beyond what *you* want to use it for, think of what others would use it for.

I hate how whenever one of these threads come up, I have to remind people that there simply are not blanket things that women like to do and men like to do. But a llGetSex() would absolutely be used for such reasons.

I've gotten such responses to my initial reaction towards the female sit as, "Well, most women want to sit that way", and "Why not just stand." - Your equivalent response, Jack, would be, "Then change your appearance to male."

I simply don't understand this wide push for hardcoding gender behavior! And that IS what llGetSex() would do, whether you wanted it to or not. We can't give llGetSex() to ONLY Jack Digeridoo.

Yes, it would be another thread - but I have to say the Mars/Venus attitude is rampant here in SL, too. A separation of cultures is occurring along gender lines, and I see that travelling into SL. Targeted marketing tries to do this RL: Someday, as a female, I'm going to log onto a website such as Amazon, and the only things I'm going to be presented with are going to be pink and flowery.

I don't want to see this in SL first.

Yes, height and birthday could be used, too, but there is not nearly as much social divisiveness based on height and age as there is on gender. Complete the sentences:

Women like ____
Short people like ____
People who are 25-30 but not 20-25 like ____

Chances are, most folks had an answer ready for the first, but had to wonder a bit on the second two. Chances also are, that the first answer was something like "Shopping" "Shoes" "Weddings" "Children" "Pink" "Makeup", etc.


The fact of the matter is, the issue with your object could be resolved with minimal effort and without linking all the way up the hierarchy to appearance. Inserting a notecard that was editable, perhaps, with the remark "Put 0 for male, 1 for female" into the notecard. It'd be done. Yes, it'd require a ONE TIME change by the end user, but also, consider this:

You could make ONE object that read in the notecard, and simply stock two versions, that had different notecards in them. Or a different flag set, for that matter. You wouldn't have to maintain two versions. The only difference would be that flag notecard.

Again, I don't have a problem with this feature existing IF it can be overriden without changing appearance. And, as I've said, if it is an adult object, or a voice object, I can see the use, but the problem is, that it wouldn't be restricted to that use, Jack.

And I'm not worried about your use so much, as I am uses that haven't even been conceived yet.

I have a feeling that your object is tied to voice; and I can see why you'd want it, for that. For the sake of other uses though, I still don't think the feature should be hard-linked to gender appearance.

No but all of those affect the way a script acts, and the presentation of the scripter is enhanced by having these features. And presentation is lacking by not having llGetSex.



So remove the PushObject function, and heck, I can rez some pretty weird things so ban the llRezObject function too? And particles are used in every griefing attack so nuke them too. Gimme a break.



Here's a newsflash: We know. You don't need to remind people. Fact is, they are going to do whatever they want and you can't change it. You can either accept it and suddenly you've won. Or keep getting upset when you see it and the battle will never end.



Not suitable for my applications. People here on their 1st day can't edit the contents of a notecard contained in an attachment they just bought. They can't even find the buy button. And when they do, they have no idea why the thing took their money and they got nothing until someone says "check your inventory".



Again, you don't nerf features you file an abuse report if it breaks the TOS. Are your concerns about the TOS Michi, or just about you?

I think the problem here is that we are not talking about conduct per se; the ToS isn't the problem or necessarily being broken. There are a wide variety of activities that do not technically violate the ToS and yet are nonetheless capable of having a negative impact upon the experience of other users. Not violating the ToS is not tantamount to something being automatically "okay" or "approved." Ask any Liason.

Regardless, this isn't so much a ToS concern, anyway. You are talking about engineering new "features" into LSL with the potential to induce or reinforce a social architectural shift in SL culture as a whole. This sort of thing is not undertaken lightly. No matter how useful you feel this function might be, there exist wider concerns about its potential impact.

You know, the thing I find funny about this is that there would have been much less complaining if Jack had originally proposed the command be called llGetSelectedAvatarGender, even if it had the same function.

You guys, just stop. If there's a script that happens to use this command to interfere with you, protest the script. And don't try to say, "Well, that's like saying, don't protest guns, protest the people who use them." It's really, really not. This is NOT designed to descriminate against men or women. It can be used that way, but wrenches can be used to kill people, too, even if they're not designed for it.

0) The issue is not about how the LSL API call is named. To dismiss the concerns expressed as such is pretty disrespectful, actually.

1) Whatever the LSL call is named, there remain the concerns that gender-related functions will have a negative social impact upon SecondLife. If you disagree, say why, rather than the hand-flapping and straw-man rhetorics you have presented.

2) If implemented, it is unlikely the ToS would be applicable to the potential impact of a hypothetical llGetGender() function. The ToS, boiled down, states: "Mean people suck, don't be mean." The ToS is not an architectual document. It is merely a by-product of the social ideals that make up SecondLife, not the bylaws of same.

3) Because of #2, the time to address such a function is now, and the place is here, the user forums, where it can be discussed openly and inclusively. Attempts to shut this discussion down or dismiss it offhand undermine this process.

Jesus what's the big deal? He's asking for a simple function that gets the status of an avatar. Nothing has been taken away. Not everyone has to use it.

I support this feature. More functions and less nerfs is a good thing.

0) I'm not disrespecting the llGetAvatarGender suggestion, I don't care what it's called. I can llGetSex is way easier to type but who cares what the scripters think eh.............

1) gender in SL is a different thread. i could care less if i sit down like a girl. but for what i'm making, i want the user to have a seamless experience. right now, they CAN'T.

2) Yeah and remember half the time people are not being mean they are just misunderstood. I make that mistake a lot. If you don't like how someone uses a function, neg rate it.

3) What you want to address is both interesting and important, and the people who are against this would see more examples of the concept that bothers them. It's always their choice to write the exact same script - without the forced gender and give the public the option. This would give their cause more exposure and educate more people. So if anything, you should be for this function.

What sucks is after all this I'm really bad at math and probably won't be able to figure out how to make this thing anyways. But I still want the function.

So are you saying I better start acting how girls are "supposed" to act, accept it, and then, I've won?

What I'm saying is there will be an overwhelming trend to LOCKED gendered objects if this feature was there. You're right, maybe, that it should be tied in with the individual who creates the object. I'd just like the ability to not have the object sense that attribute - I don't see how that'd take away from YOUR experience.

Allowing it to be selectable for the individual (on how llGetSex reports), is not anal, it's MINOR.

It is, once again, for some unknown reason, people AGAINST the possibility of users having a -choice-, which I just don't understand.

You would still have the choice to script it yourself in a way that does not force gender. Nobody is forcing you not to script your own version. Right now we are forced to use a dialog which takes away from the experience I want to deliver.

i still say *IF* its ever implemented, then IF someone uses it badly, deal with them... its not something thats innately bad.

Yer takin it a lil too far.. yer goin RIAA with SL features and i know ya don't want that michi/chromal. just because soemthing *could* be used for 'piracy' doesn't mean it should be destroyed.. this right now, is jus diggin a hole, its gone too far we needa jus calm down okay?

If we'r gonna have llGetSex() does that mean we'll have llSetSex() too... could make for some interesting events at certain clubs...

Bleh, I was never not-calm.

My stance is largely a conservative one, e.g.: we haven't needed this thus far, we certainly don't need it now.

Social outcry was another reason. People wanting to avoid being pidgeon-holed is understandable and I sympathized. Honestly, though, it's like trying to reverse the Niagra falls with a bucket and a rope, at this point. SL is becoming the AOL/There of MMOs, rather than the hip progressive multiverse ideal envisioned so long ago. I accept the inevitability of that, but still believe The Good Fight is worth fighting a last hurrah before buried under a tidal wave of a "mediocratic" crap.

Another reason might have been the avoidance of feature bloat, especially for trivial things like a gender-API when there are so many outstanding problems with the existing features, as well as more desirable features that are, as of yet, unaddressed. (e.g.: llSetPrimitiveParams() is still broken, sound API remains shackled, no client-side texture script API, no meaningful server script execution resource monitoring API, no meaningful self-governance...)

RIAA tries to shackle rights and abilities we've always had. I was under the impression this discussion was focused upon something that has never been in place. As such, I didn't see the stormtrooperish undertones you are implying were there, nor the similarity to RIAA.

It's all moot, of course. It won't get implemented.

Ahh, you mean you don't have a use or immediate need for it, therefore you don't/won't/can't see why anyone else possibly would/could.

Note that I don't have an immediate use/need for it, either, but I at least realize that I'm not the only person in SL that ever has new and interesting ideas.

WHAT DO YOU MEAN WE?



Incorrect. I've played them all. SL is generations beyond everything else. The only way to catch up is to license the technology from LL at this point.


Please close this thread. It is degenerating into bashing LL. I want llGetSex() if you don't want it, leave it at that, but cut the crap.