Forcekill

[Zeblote]

The more you know. All my mods read the variable, ah well

All the method does is read the variable. There's really no reason to change it if you're reading the variable already.

[Ad Bot]

[General]

All the method does is read the variable. There's really no reason to change it if you're reading the variable already.

I know both methods work anyway, it makes no diff.

Except maybe one day the variable gets removed seeing what was quoted in previous post

[Headcrab Zombie]

It won't be removed
Using the method over the variable is just a matter of standard
It's not work breaking a bunch of add-ons over that

[Zeblote]

Except maybe one day the variable gets removed seeing what was quoted in previous post

That'd require an update first

[elm]

Short answer: Because Badspot says it is

Long answer: Whenever you have a variable and a method that point to the same thing, it's (usually) better practice to use the method rather than the variable. Similarly, although %obj.position is a valid field that contains the objects position, you never see it used, instead you see %obj.getPosition().
In languages that support it, you'll usually define the variable as private (only accessible within its class) or protected (only usable with its class or derived classes) and then create a public (usable wherever) method to access that variable

Lol, I always reference the variables and never use the functions. Can you explain to us why it's good practice to use a function that ONLY points to the variable and does nothing else in terms of functionality, then to just reference that variable directly? :)

[-Jetz-]

Lol, I always reference the variables and never use the functions. Can you explain to us why it's good practice to use a function that ONLY points to the variable and does nothing else in terms of functionality, then to just reference that variable directly? :)

A blundering rookie or a dumbass solving a problem with a hacky solution could change the client.name variable. getPlayerName reads a variable stored safely in the engine. On the other hand, using client.name allows the function to be compatible with AI clients, though I don't think that's usually needed for an admin command.

[elm]

getPlayerName reads a variable stored safely in the engine.

I wasn't aware of this, do you have proof or can someone provide proof of this?

[Compy]

looking in the binary, it appears to return a field on the actual object represented in memory. ".name" is just a torquescript-friendly field thats tacked on when they join or something, it doesn't seem to have any direct relation with the actual field on the object. technically they're two different things.

edit: and adam's posts proves this further

[Headcrab Zombie]

I wasn't aware of this, do you have proof or can someone provide proof of this?

You can demonstrate it yourself with some console commands

[elm]

The more you know.

[-Jetz-]

getPlayerName is there for the benefit of stuff like authentication, so it doesn't break when some bonehead changes the name variable. It's also used by the vanilla game in most other places where a name variable is needed, though as said before, this makes them incompatible with AI connections to the server, so you have to imitate it if you want a bot to send a message through the chat without it having a blank name. This isn't that often an issue in Blockland, though I'm all for functions being as versatile and adaptable as possible for the benefit of modders.