Difference between revisions of "Talk:Transforming the Multiplayer SDK into Coop"
|Line 99:||Line 99:|
Revision as of 16:41, 12 February 2006
Well, as far as I know, the player's restoration is not included in the SDK: somewhere in the code, Valve says something like "the players move across transitions another way"'. So I don't know the way they go across transitions, anyway I just know they are restored the same way as entities are.
Regarding the problem of Dedicated Servers, as I said in the article, the clients cannot be restored properly. Knowing that each player has an edict, I could have the following scheme:
- host-player ( edict: 1 )
- client1 ( edict: 2 )
Now if those players go across a transition, I get this:
- the host-player won't have any problem
- the client will.
My "hack" is the following: I basically ask the server "is there any existing player with the edict #2 ?". If the answer is "YES", it would mean there already is a player on the map. If there is an existing player, I tell the server not to override it as this existing player would be the former one ( coming from the transition ). The very last step is to teleport the client to his previous position.
I know this explaination must not be clear... but it is actually hard to explain it... I am not a good teacher.
Yes but if it's dedicated, edict 1 is a random client...players cannot go over transitions easily because the server already handles player ents; I think it'd be a better idea to disregard player transitioning altogether and focus on moving everything else to the new map...which this article proposes to work, correct?—ts2do (Talk | @) 13:26, 19 Nov 2005 (PST)
Also, your idea to block the motd from showing up...that would only work for the player 1? an idea would be to have an ent in the map that says if it's a continued map—ts2do (Talk | @) 13:28, 19 Nov 2005 (PST)
Okay, I will try to fix the problem for Dedicated Servers. Thanks for the information.
Concerning the MOTD, if you look at the code, you will probably notice that my code reffers to the pPlayer entity defined by CHL2MP_Player *pPlayer. I believe the CientActive() function is called for every player. I have tryed with a friend and he noticed the MOTD stuff was working. If it doesn't work for you, tell me.
@Ts2Do: I have fixed the bug you told me about.
I have updated the condition. Now it simply checks if the crossing player whether is a client or the host-player. The condition now is:
if ( bTransition && IsClient() ) g_pGameRules->GetPlayerSpawnSpot( this ); else if ( !bTransition ) g_pGameRules->GetPlayerSpawnSpot( this );
I think that you should make the changelevel trigger to wait for all the players to be standing in its zone and trigger it just then. What do you think?
@Garstyciuks I thought about that though, I eventually dropped the idea because of AFK players. The main topic was: "if a player is AFK, how to know it?"
Now I think of this: we could care of each player's ABS Velocity. If the ABS Velocity is equal to zero, we could run a timer and if the time reaches a specific value, then we set the player to "AFK". What do you think about it ? Yours.
That's a good idea. Anyways, you could make what you said and then, if the players won't like it, they might suggest something better.
@Garstyciuks I suggest we create a server variable wich woud define the "AFK Time Value" in seconds. If the value is set to zero (0), the server won't deal with AFK Players. What do you think about that idea?
Well, I think I will host an online website dealing with half-Life 2 coop. Does anyone know how to host a WIKI website onine? Yours.
In my playing around wiht this code (that i appricate) I found an issue that needs addressing. When using the weapon_slam and then going through a level transition the laser effects and light effects have a tendancy to move to the origin if you transition again. The clearest exxample is slams in the satchel version do not blink if you go thorugh a transition. Then if you transition abck the blicking dots are now at origin. Lasers don't dissapear, but the endpoints of the beams move to the origin in the same situation. A simple function make all slams effects clear and then reapply on level loading should do it, but thats a little beyond me right now. TY if you can get round to fixing this. Angry Beaver 16:41, 12 Feb 2006 (PST)