Talk:Transforming the Multiplayer SDK into Coop: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| Line 30: | Line 30: | ||
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?—'''[[User:Ts2do|ts2do]]''' <sup>([[User talk:Ts2do|Talk]] | [mailto:tsdodo@gmail.com @])</sup> 13:26, 19 Nov 2005 (PST) | 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?—'''[[User:Ts2do|ts2do]]''' <sup>([[User talk:Ts2do|Talk]] | [mailto:tsdodo@gmail.com @])</sup> 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—'''[[User:Ts2do|ts2do]]''' <sup>([[User talk:Ts2do|Talk]] | [mailto:tsdodo@gmail.com @])</sup> 13:28, 19 Nov 2005 (PST) | |||
Revision as of 14:28, 19 November 2005
How would player restoration work, seeing that the players can change around and stuff in multiplayer?—ts2do (Talk | @) 12:18, 19 Nov 2005 (PST)
You would also run into issues with dedicated servers probably—ts2do (Talk | @) 12:21, 19 Nov 2005 (PST)
@Ts2Do
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.
--Thomas
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)