Difference between revisions of "Talk:Valve Developer And Community Tidbits"

From Valve Developer Community
Jump to: navigation, search
 
 
Line 1: Line 1:
 
This page needs cleaning up, but I completly forgot all the wiki syntax [[User:^Ben|^Ben]] 12:05, 12 Dec 2005 (PST)
 
This page needs cleaning up, but I completly forgot all the wiki syntax [[User:^Ben|^Ben]] 12:05, 12 Dec 2005 (PST)
 +
 +
This is from Jorge Rodriguez, I am just waiting on permission from him to post this.
 +
 +
==Transfering Values from Client to Server==
 +
This is great information from Jorge Rodriguez, this is information about the way Source was designed for client to server communication and how it is not built for that purpose, and ways you should work within the limits of the design.
 +
 +
Unfortunately, Half-Life and Half-Life 2 were designed so that network
 +
variables are only transferred from server to client, and not the other
 +
way around. There are only two ways of getting data from the client to
 +
the server:
 +
 +
- Console commands
 +
- Player movement parameters
 +
 +
Console commands are things such as +attack and kill that the player can
 +
type into his console, but which are usually just bound to a key or UI
 +
event. Player movement parameters are things such as the current viewing
 +
angles and other things directly associated with player movement, and
 +
changing those only works in player movement code.
 +
 +
There are a couple reasons that there's no client to server automatic
 +
data propogation, but this is not by mistake, it is by design. I can
 +
think of these reasons:
 +
 +
1) Ensure that everything the client can do is accessible to the user
 +
through the console
 +
2) Ensure that the client's upstream data quantity remains small
 +
3) Simplify the networking model by only allowing data to move in one
 +
direction
 +
 +
and I'm sure Valve had others in mind when they designed the network
 +
model. But in any case, this is how you would do what you want. You
 +
create a ConCommand on the server like this:
 +
 +
void CC_SpellType()
 +
{
 +
  CBasePlayer* pPlayer = ToBasePlayer( UTIL_GetCommandClient() );
 +
  if ( !pPlayer )
 +
      return;
 +
 +
  if (engine->Cmd_Argc() == 1)
 +
      return;
 +
 +
  int iSpellType = atoi(engine->Cmd_Argv( 1 ));
 +
 +
  // Do some data checking on iSpellType here to make sure the value
 +
is legal, and finally...
 +
 +
  pPlayer->m_bCurrentSpellType = iSpellType;
 +
}
 +
 +
ConCommand spelltype("spelltype", CC_SpellType, "Change the spell
 +
type.", 0);
 +
 +
Then, have the client fire off the command "spelltype 2" or "spelltype
 +
1" or whatever you want it to be. It can be bound to a key, or it can be
 +
triggered by the UI, or by some game event, or hell it can be wherever
 +
you want it to be.
 +
 +
If there are only two possibilities for spell types, you might consider
 +
removing the parameter from the above command and naming it something
 +
like "togglespelltype", and have it automatically switch back and forth.
 +
In any case, the model here is that the client requests for a spell type
 +
change, and then the server replies by either denying or accepting the
 +
request.

Latest revision as of 21:18, 10 April 2006

This page needs cleaning up, but I completly forgot all the wiki syntax ^Ben 12:05, 12 Dec 2005 (PST)

This is from Jorge Rodriguez, I am just waiting on permission from him to post this.

Transfering Values from Client to Server

This is great information from Jorge Rodriguez, this is information about the way Source was designed for client to server communication and how it is not built for that purpose, and ways you should work within the limits of the design.

Unfortunately, Half-Life and Half-Life 2 were designed so that network variables are only transferred from server to client, and not the other way around. There are only two ways of getting data from the client to the server:

- Console commands - Player movement parameters

Console commands are things such as +attack and kill that the player can type into his console, but which are usually just bound to a key or UI event. Player movement parameters are things such as the current viewing angles and other things directly associated with player movement, and changing those only works in player movement code.

There are a couple reasons that there's no client to server automatic data propogation, but this is not by mistake, it is by design. I can think of these reasons:

1) Ensure that everything the client can do is accessible to the user through the console 2) Ensure that the client's upstream data quantity remains small 3) Simplify the networking model by only allowing data to move in one direction

and I'm sure Valve had others in mind when they designed the network model. But in any case, this is how you would do what you want. You create a ConCommand on the server like this:

void CC_SpellType()
{
  CBasePlayer* pPlayer = ToBasePlayer( UTIL_GetCommandClient() );
  if ( !pPlayer )
      return;

  if (engine->Cmd_Argc() == 1)
      return;

  int iSpellType = atoi(engine->Cmd_Argv( 1 ));

  // Do some data checking on iSpellType here to make sure the value
is legal, and finally...

  pPlayer->m_bCurrentSpellType = iSpellType;
}
ConCommand spelltype("spelltype", CC_SpellType, "Change the spell
type.", 0);

Then, have the client fire off the command "spelltype 2" or "spelltype 1" or whatever you want it to be. It can be bound to a key, or it can be triggered by the UI, or by some game event, or hell it can be wherever you want it to be.

If there are only two possibilities for spell types, you might consider removing the parameter from the above command and naming it something like "togglespelltype", and have it automatically switch back and forth. In any case, the model here is that the client requests for a spell type change, and then the server replies by either denying or accepting the request.