Use player ID as an alternative to names

[kyle]

I like the epsy/z-man idea the best

use #1 for id's
and escape the # in players name
and then for player#1 it would show up as player_1

Code: Select all

Player name    Mention by name     Mention by ID
Player 1       player_1            #1;
#id=1337;      _id=1337;           #2;
First #1       first__1            #3;
#1             _1                  #4

[Ratchet]

I somewhat saw the solution the same way as Tank Program. While reading responses, my obvious solution to the problem would be to program another command using the same basic code as player_kick, but base it off of the command player_kick_id.

However, I am unsure how difficult that would be and whether or not there would be any potential problems behind doing so.

[kyle]

There are a lot of commands that use this, In fact I believe any command that takes a player name uses the code we are talking about.

[Z-Man]

ID:1 | ID:2 | kick ID or another substring of their name like D:1 or :1
->}ID | ID:1 | kick ID or another substring

Any solution that has substrings as the only way to reference players is doomed. a) There's always combination of player names where there is no unique substring you could use and b) have fun teaching scripts to generate the correct substring.

The additional command solution would work, but it would still be an extra command for every command using player names, and the same for chat commands like /op. I'm not too fond of that.

[Ratchet]

Okay, what are the possiblities of completely disabling the "type player name" feature, and require only a player ID.

IE:
'kick billy' would no longer work, you'd have to use
'kick 3'

That way the player name would make no difference, and there are no possible mixups. Sorry if I'm missing the obvious problem with this solution, I just can't think of any immediate drawbacks.

[kyle]

Read the whole topic -Ratchet-, I think it was pretty obvious way, anyway to reiterate it

In standard armagetron it looks for id first(1,2,3,4....MAX_CLIENTS), then it searched for the player, We broke that in sty+ct so that we could only search for a player. This is because all the ladderlog files print out the usernames. and if a username is 1 the script would call a command and it would go to the user with ID 1 not the user who's name is 1.

and don't say you can put id's on ladderlog for username, because an ID makes a external ladder pointless.

But honestly I think that idea about #1 and escaping the # in a username would be the thing that would brake the least amount of stuff.

[dukevin]

But honestly I think that idea about #1 and escaping the # in a username would be the thing that would brake the least amount of stuff.

I very much agree with kyle on this one.

[Magnie]

You know, I really liked it when you typed in /players in 0.2.8.2 it gave the normal strand. Like when I used the name "Cŷßïrd" it would come out as "cysird" when you typed the command. What are the chances of getting that back? Then you won't need to type the ID #.

( Hope this goes with the topic. )

[dukevin]

But honestly I think that idea about #1 and escaping the # in a username would be the thing that would brake the least amount of stuff.

As I already stated, I too like this idea. But if having another escape sequence isn't favorable as Z-Man said, how about using an existing one, ie. :1 for ID of 1?

[kyle]

You can undo the commit /* */ that was put on here and that would do that.

[Z-Man]

how about using an existing one, ie. :1 for ID of 1?

What do you mean? How is that an existing escape?

[dukevin]

how about using an existing one, ie. :1 for ID of 1?

What do you mean? How is that an existing escape?

I saw a list of escaped characters a while back, off the top of my head I thought : was in it. If not, then my mistake, but the concept still holds; use another escaped character instead of making another (#).

[Z-Man]

The escapes you're thinking about only work the other way, when the screen names are transformed to user names. They're kind of convoluted, only designed to avoid collisions. @ -> \@, space -> _, _ -> \_, % -> \%, \ -> \\, color codes get escaped, unknown characters hexcoded. It would be a bad idea to exploit them.

However: There are simpler escapes for the string input used before the player filter. Most notably, "Playername" gets read as Playername. Instead of demanding an escape for client IDs, we could disable ID lookup if the player name is in quotes. So KICK "2" would kick the player named 2, KICK 2 the player with ID 2. Disadvantage: not as extensible as epsy's suggestion, scripts written for ctsty need rewriting. Advantage: least code change, scripts written for plain code can be left as they are and wont break any more than they already do.