Changing player names - Axe Software Forums

  Axe Software Forums
  Quest Developer Forum
  Changing player names

Author Topic:   Changing player names

Gwerradon posted 27-05-2003 00:36 BST
i want to make a command called /join blue, or /join red, and i want this to change the players name to '<name> (blue team)' How do i do this? just so it adds an extra bit to the players name.
if not, i want it so it just changes the name to Blue Team. thanks. (this will be run in QuestNet)
gamer1962 posted 29-05-2003 05:26 BST
Assuming your variable Name is set with the player name you can do something like
set string <Name; #name# (Blue team)>
You can ask the question of what team to join and interchange the blue and the red of course, If the variable name already contained "John" and you used the command suggested above the variable name would contain "John (blue team)" when everit was printed
I think Im Back posted 29-05-2003 19:57 BST
No, no, no. In questnet, the easiest way to do things like this are with player properties. Think of player's as objects, sure the player may have an alias of John, but it is actually named player1. The 1 on the end is assigned according to the questnet user ID this is called with the numeric variable %userid%. Now that you know this, to give player properties, in this example a name, you simply...
property <player%userid%; alias=$capfirst(john)$>
In all of my code I have player properties assigned that override the default quest alias tags and default, this is useful for making code readable by everyone and useful for implementing an online coding language within the game.
That was off subject but back to the point, in questnet, variables are out. Variables are no longer used to determine player attributes and properties, these are easiest done through object/player properties as shown above. Variables are still very useful, but it becomes ridiculous trying to have variables for each player, when it's much easier and more efficient to have objects hold the properties which can then be read by commands. By more efficient I mean, it doesn't leave a ton of random strings around when players aren't currently playing.
I don't know, hope that explained something.

Author	Topic: Changing player names
Gwerradon	posted 27-05-2003 00:36 BST i want to make a command called /join blue, or /join red, and i want this to change the players name to '<name> (blue team)' How do i do this? just so it adds an extra bit to the players name. if not, i want it so it just changes the name to Blue Team. thanks. (this will be run in QuestNet)
gamer1962	posted 29-05-2003 05:26 BST Assuming your variable Name is set with the player name you can do something like set string <Name; #name# (Blue team)> You can ask the question of what team to join and interchange the blue and the red of course, If the variable name already contained "John" and you used the command suggested above the variable name would contain "John (blue team)" when everit was printed
I think Im Back	posted 29-05-2003 19:57 BST No, no, no. In questnet, the easiest way to do things like this are with player properties. Think of player's as objects, sure the player may have an alias of John, but it is actually named player1. The 1 on the end is assigned according to the questnet user ID this is called with the numeric variable %userid%. Now that you know this, to give player properties, in this example a name, you simply... property <player%userid%; alias=$capfirst(john)$> In all of my code I have player properties assigned that override the default quest alias tags and default, this is useful for making code readable by everyone and useful for implementing an online coding language within the game. That was off subject but back to the point, in questnet, variables are out. Variables are no longer used to determine player attributes and properties, these are easiest done through object/player properties as shown above. Variables are still very useful, but it becomes ridiculous trying to have variables for each player, when it's much easier and more efficient to have objects hold the properties which can then be read by commands. By more efficient I mean, it doesn't leave a ton of random strings around when players aren't currently playing. I don't know, hope that explained something.