Player Selection

#1 If I recollect correctly..
this information can be found in ../starter.fps/server/scripts/main.cs

I believe it is called spawnPlayer or something like that.

#2 Thanks, I found where I need everything in /server/scripts/game.cs. So I got it working so that it now allows for different players to be selected and that model is used in the world!

#3 Ive got one more problem now that my player selection is working. If I link up with someone else, the game crashes as soon as someone joins the game. I also noticed that there model becomes the same as whatever the server picked for their own player. So like if there is a male and female model, the server picks the male, but the client picks the female, the client will enter the game as the male and both people will crash. I see in Real Wars that you can choose from 3 different models and people can join in with no problem and play as a different player model. Anyone know what would I have to do to fix this problem?

#4 You should be a ble to just search the Realm Wars scripts for "orc" and "elf" and follow the code to see what it does.

#5 Is the client sending his/her player selection to the server? The create/spawn player scripts only run on the server, other methods are used to tell the client what dts object to display. You need to incorporate the model selection into the connection string, so the server knows what model to use, or you could use some querry calls ala commandToClient/commandToServer.

That being said, I don't think it's the source of your crash, are there any error messages?

#6 There isnt any error messages, just a crash when someone tries to join the game

ive looked through Real Wars and set up my data/shapes/player files all the same and included them in server/scripts/game.cs the same way RW does and the same way they check for the player inside createPlayer.

I understand about telling the client what dts to use, maybe I overlooked this and that might be the problem. Where would I find the right place to tell the client what dts to use?

#7 The only error I could find was in TSThread.cc, on the line TSThread::GetPos(); Im like totally lost on that but thats the only thing is gives me as any error.

#8 Did you check in the console (or log files), maybe you have some scripting error that breaks something and thus the crash cause of some function that can't be called, else it might actually be the player choosing thing that you are somehow doing wrong?

I did what you are trying for my game and it is working perfectly, you can choose between different player models and different skins for each model and the selected models and skins appear both on server and client side correctly. i think there are resources avail on how to do this stuff, maybe i'll create a resource to explain how i did it if I get some time.

Suffice to say I did something like this ... I have several player scripts for each type of model .. like girl.cs, alien.cs, boy.cs (basically the default player datablocks but with diferent models in them.

so when i create the player i just have to feed it the correct datablock (playerdata) and all is fine :) , for instance...

datablock PlayerData(GirlPlayer)
{
renderFirstPerson = false;
emap = true;

className = Armor;
shapeFile = "~/data/players/girl/player.dts";
cameraMaxDist = 6;
computeCRC = true;
.......

and then in createpayer (in game.cs) i did something like this...

%playerDataBlock = %model @ "Player";
%player = new Player() {
dataBlock = %playerDataBlock;
client = %this;
scale = "3.5 3.5 3.5";
};
...

note that the %model var holds the model name, in this case "Girl" (thus ALL my playerdata blocks have to be in the form "somethingPlayer" to work. Obviously I send a call to careteplayer with the %model name i wish to use. Here I had some serious problems caue of the way I implemented the whole thing in that all players would look like the server's choise :p but I got around that via client/server messages.

#9 Im implementing my scripts exactly like you have above for the game.cs.
I do have separate scripts for each player type and they are the default player with different models. Still not sure why it crashes though. I checked the log file and nothing really shows except

popDialog(): Invalid control: MainChatHud
*** ENDING MISSION
CDROP: 1471 IPX:CECECECE:CECECECECECE:52942
Exporting server prefs...
Exporting client prefs
Exporting client config
Exporting server prefs
Exporting client prefs
Exporting server prefs
Shutting down the OpenGL display device...
Making the GL rendering context not current...
Deleting the GL rendering context...
Releasing the device context...
Restoring the desktop display settings (1400x1050x32)...
keyboard0 input device unacquired.

thats at the very end of the console.log

i'll keep working at it

#10 Well I tried linking up on a different computer and now I dont crash. Im guessing the other laptop I was using may have had some issues. But the player models are both the same. So like whatever the server picks the client gets no matter what and all the ammo information is only updated on the server side. So now that magically the crashing is gone, how can I make sure the proper model is being used and that each client gets updated properly for their ammo and health, etc..?

#11 Oya, i had this too (the crach thing), my debug version of the build would work but the release version would never work after a build, until i did a "CLEAN" rebuild :-p bagh, i felt soo stupid.

anycase, i have asetup area where the player select his model and skin and enter his name, these values are then saved to pref::player::..... which would obviously give some problems .. your clients having the same selecteion of model than the server.. always. here is what i did, might not be best solution but it works for me. so what i needed to do is make a call to the client to tell it i wanna spawn a player for it, then it replies with a message to the server and send along the model and skin name and from that i could choose the corerct datablock and skin to use when creating the player. thats it :-), this was needed to get the values as they appeared on the client machiones pref:player vars. hope this made sense ..

if i wasnt soooo busy i could write up a proper resource for this but im working on a new version for our website and have to get a demo version of the game ready and is still looking for a publisher and looking at self publishing options, and trying to figure out why i cant see any of my game's servers when i wanna play over internet.

#12 I understand exactly what you are saying with the exception of that I dont know where to actually call the client and tell it to spawn a player. Do I make this function myself or is it built in? And please dont tell me its in game.cs, cause I already have the player creation inside of createPlayer.

The other file ive looked into is clientConnection inside of common/server, this seems to be the place to make $pref::player vars change inside of the onConnect function.

Im just not sure what else to do now. Seems like I have everything I need and ive even looked over another Torque game and all the logic is the exact same, so it seems to make no sense. Works fine for them but not for me. Im sure its something im not doing.

#13 Has anybody stripped out the parts in the RW code yet and made a Player Select rescource ?

#14 Guys, this is not as hard as you are making it. Check this out....


First, set up your client so he can pick any armor he wants. Then assign that armor to a global variable (On the CLIENT) like $playerArmor = "ElfArmor";(NOTE!!!! Make sure the name EXACTLY matches the servers datablock name for that armor, you'll see why in just a minute) Next, in your "joinServerGUI.gui", go to "function JoinServerGui::join(%this)", and change "%conn.setConnectArgs($pref::Player::Name);" to this...

%conn.setConnectArgs($pref::Player::Name, $playerArmor);


Now, what you have done, is let the player decide what armor he wants, and when he logs into a server, it will tell the server exactly what armor the player wants. Now, lets get the server to utilize it....


In "clientConnections.cs" (ServerSide) change this....

function GameConnection::onConnect( %client, %name )
{

to this.....

function GameConnection::onConnect( %client, %name, %armor )
{
     if(%armor)
     {
          %client.armor = %armor;
     }
     else
     {
          %client.armor = "OrcArmor";
     }

That's it. You are done with the login and declaration of the clients armor in one neat package. I set the Orc as a default armor in case no armor is chosen, or if somehow the armor doesn't get sent, or some script kiddie trys to get cute and not send one to see what it will do to the server. You can set it to any armor of your choice.

Now, all you have to do to give the client the armor he chooses when you spawn his player is use his %client.armor variable when you need to know what armor to spawn for him. Here is a modified spawn function to demonstrate....

function GameConnection::createPlayer(%this, %spawnPoint)
{
   if(%this.player > 0)  {
      // The client should not have a player currently
      // assigned.  Assigning a new one could result in
      // a player ghost.
      error( "Attempting to create an angus ghost!" );
   }

   // Create the player object with your players chosen armor...

   %player = new Player()
   {
      dataBlock = %this.armor; //[b]<-- This is where the clients armor is set.[/b]

      client = %this;
   };
   MissionCleanup.add(%player);

   // Player setup...
   %player.setTransform(%spawnPoint);
   %player.setShapeName(%this.name);

   // Update the camera to start with the player
   %this.camera.setTransform(%player.getEyeTransform());

   // Give the client control of the player
   %this.player = %player;
   %this.setControlObject(%player);
}

#15 That's it. Now your server will let the players choose their own armors unless they dont choose, and then it will choose for them. Keep in mind, that for safety's sake, you should make it impossible to send an invalid datablock name to the armor function. If I wanted to exploit the above code, I would just change my scripts so they sent something like "SuperArmor" to the server which could cause it to have some problems. A simple way to do that is use simple names on the client, and then address the proper names at login. Lets say you had three armors, Elf, Wizard, and Orc, you could use those exact names on the client and then alter the clientConnection function like this....

function GameConnection::onConnect( %client, %name, %armor )
{
     switch$(%armor)
     {
          case "Elf":

             %client.armor = "ElfArmor";

          case "Wizard":

             %client.armor = "WizardArmor";

          default:

             %client.armor = "OrcArmor";
     }

Now, what we have done here is to change the armor name to the datablock name via the switch. If the client chooses "Elf" or "Wizard" or "Orc" on his end of the game, then when he logs into the server he will get the correct armor datablock name assigned to him. If he chooses nothing at all, or uses a script to call some unknown Armor like "SuperMan", then he will be defaulted automatically to the Orc. I HIGHLY recommend this type of safty margin for your server because you can ALWAYS count on some jerk out there with nothing better to do, to try and screw up your game in any way he can think of. I don't know what sick perversion it is that causes people to get more joy out of destroying everyone else's fun instead of enjoying a little of their own, but it exists, and if you don't plan ahead for these types of assholes, they will make your game a living hell for everyone that plays it and eventually no one will play it. Just ask the GG guys how much work they had to do to the Tribes 2 code to compensate for the "Asshole Factor" that they didn't plan for ahead of time. People stealing your vehicles for instance. You can bet good money that nobody on the T2 development team ever stole a vehicle from anyone else. It just never occured to them to do so because they were more interested in having fun and creating a game than they were in being jerks to everyone else. But it sure didn't take long before every jerk in the game was ripping off everyone else's vehicals simply because they felt they were too good to wait in line for the station like everyone else did. So Dynamix had to compensate by making it impossible for anyone but the guy who purchased the vehical to get into it, and at first they even warped you to the vehicle to make sure you got it. That not only took some of the stratagy and fun out of the game, but it also created another problem for them that they had to solve as well. When I write my code, I write it as if a pack of those jerks was staring over my shoulder just looking for any kind of flaw they could exploit. That way my code starts safe and solid, and gets better from there.

#16 Ok,

I've tried the Gonzo T. Clown method and I've tried a commandtoClient, commandtoServer method. In both cases Torque either crashes whenever anyone logs into a server or when the second player (who has chosen a different armor type) logs into an existing server. Torque is not returning any useful errors to me through the log, and I'm beginning to tear my hair out.

Does anyone have any other suggestions?

thanks.

#17 Ok,

I've tried the Gonzo T. Clown method and I've tried a commandtoClient, commandtoServer method. In both cases Torque either crashes whenever anyone logs into a server or when the second player (who has chosen a different armor type) logs into an existing server. Torque is not returning any useful errors to me through the log, and I'm beginning to tear my hair out.

Does anyone have any other suggestions?

thanks.

#18 Welp, if its any consolation its happening to me as well..BUT it obviously works in realm wars, and in the GameBeaver release.. so i would imagine what ever you are doing wrong i am too..i'll post when i figure it out.. :)

#19 If one of you wants to post your

function GameConnection::onConnect


I'd be glad to take a look at it. I can't imagine why all of you are having this problem unless there is some flaw in the example code that I have overlooked somehow. There has got to be some simple cause for this as I am not experiencing these problems.

#20 Its thowing an exception here

F32 TSThread::getPos()


so i'm assuming the datablock is to blame.. will investigate further