Locked: A Gender var (notice the caps) in BYOND Discussion

ID:260660
 
Nov 29 2008, 8:12 pm
Personally, it seems like whenever I want to use somethings gender, I usually want it capitalized, while the BYOND versions are all lowercase. Specifically, the statpanel.
"Gender: male" just looks bad, in my opinion. I realize that there are several ways of dealing with it, such as using copytext and uppertext, but do I really want the game to be copying and uppercasing text every single tick of the Stat proc? Or is it really worth creating my own dummy var for it?

I'm suggesting that there be two gender vars, a lowercase one "gender" and an uppercase one "Gender". Anyways, maybe it's too much for such a minor thing, but it can't hurt to put out there.
#1 Nov 29 2008, 9:29 pm
Or you could make your own Gender variable, and use copytext() and uppertext() upon New() or Login() of a mob to do it yourself.
#2 Nov 29 2008, 9:43 pm
 
stat("Gender: ", "[uppertext(copytext(gender,1,2))copytext(gender,2)]")

#3 Nov 29 2008, 9:47 pm
 
var/list/Gender=list("neuter"="Neuter","male"="Male","female"="Female","plural"="Plural")

mob
    Stat()
        statpanel("Info","Gender: [Gender[gender]]")
#4 Nov 30 2008, 2:03 am
This is probably off topic, but is it not possible to distinguish your gender from the sprites or your earlier selection of what gender you should be?

(as in: why bother displaying the value of the player's gender?)
#5 Nov 30 2008, 4:26 am
 
mob
    var
        Gender
    proc
        UpdateGender()
            Gender = copytext(uppertext(gender), 1, 2) + copytext(gender, 2)
    Login()
        . = ..()
        UpdateGender()


-01000100010101000100000100110011001100000011000100110001-
#6 Nov 30 2008, 7:15 am
No offense, but this request is ridiculous.

Chessmaster_19 wrote:
Or is it really worth creating my own dummy var for it?

Where's the sense in this... uh, so it is worth creating a built-in var for it? No, it isn't, at all. It'd be useless for most people, whoever needs it should simply define it on their own, it's simple and there is no problem with it. Implementing such already easily-doable features to built-in DM, more so 'personal' requests would just add feature bloat.
#7 Nov 30 2008, 7:35 am
In response to Android Data (#5)
Android Data wrote:
-01000100010101000100000100110011001100000011000100110001-

DTA3011

Nice signature.
#8 Nov 30 2008, 7:37 am
In response to Xooxer (#3)
Xooxer wrote:
> var/list/Gender=list("neuter"="Neuter","male"="Male","female"="Female","plural"="Plural")
> 
> mob
>   Stat()
>       statpanel("Info","Gender: [Gender[gender]]")
>

Sacrifice a list to save some strings?
By the way, is there a string limit?
#9 Nov 30 2008, 7:50 am
In response to CaptFalcon33035 (#8)
CaptFalcon33035 wrote:
Sacrifice a list to save some strings?

Yeah, he likes doing that with everything.

By the way, is there a string limit?

Yes, ~32k like most limits. But note DM strings are automatically cached, so having, say, multiple vars set to an identical string only counts as one string, opposed to numerous copies, since every var just holds a reference to the single cached version (this is also why you can directly compare strings with the == operator).
#10 Nov 30 2008, 2:37 pm
In response to Kaioken (#9)
It's actually 65535 for those limits, not ~32k.
#11 Dec 1 2008, 3:01 am
In response to Nadrew (#10)
Oh, that's right, got confused with something else, probably meant to say 64. Oops!
#12 Dec 1 2008, 6:53 am
In response to CaptFalcon33035 (#8)
CaptFalcon33035 wrote:
Sacrifice a list to save some strings?

No, sacrifice a list to save processing.

By the way, is there a string limit?

Of course. Everything is a trade-off. Not having the gender capitalized is unacceptable, copytext() requires a process hit every 8/10ths of a second for every mob in the world, unless you pre-compute the values, which would also require a list. Might as well capitalize the names yourself in the code and use a list to serve them to the mobs without unnecessary overhead.
#13 Dec 1 2008, 6:57 am
In response to Kaioken (#9)
Kaioken wrote:
CaptFalcon33035 wrote:
Sacrifice a list to save some strings?

Yeah, he likes doing that with everything.

I like to focus on solutions that fit the context of the problem, not some idealized solution for a perfect project where everything has to be maxed out in efficiency. Your advice is often way overkill, or simply not applicable to the problem at hand. Your recent argument with PiF about for() vs while(1) was a perfect example of fixing what's not broke. You like to do that with everything.
#14 Dec 1 2008, 8:32 am
In response to Xooxer (#13)
Xooxer wrote:
CaptFalcon33035 wrote:
Sacrifice a list <s>to save</s> and some strings? (fixed)

Yeah, he likes doing that with everything.

I like to focus on solutions that fit the context of the problem, not some idealized solution for a perfect project where everything has to be maxed out in efficiency.

Is that so? You've just said yourself: "No, sacrifice a list to save processing." On the other hand, I prefer a solution using a simple switch(), which is only a little bit slower but doesn't constantly take up resources from the game on the background.

Your advice is often way overkill, or simply not applicable to the problem at hand.

That's right, insisting to take resources permanently, even when the code could only actually be used seldom, just to save some very short extra processing time is definitely not overkill, ho ho.

Your recent argument with PiF about for() vs while(1) was a perfect example of fixing what's not broke.

If I'm correct in identifying what you're referring to, that wasn't an argument. What was broke, or more accurately wrong was something Pop said, so I (and Hobnob as well) promptly corrected it. I know you're against correcting things, but oh well.
#15 Dec 1 2008, 9:01 am
In response to Kaioken (#14)
Kaioken wrote:
I know you're against correcting things, but oh well.

It's these kind of comments that prompt me to lock threads. (Flame-Bait)

Seriously, can you two please take these arguments to the pager? They really don't need to be on a public forum.