Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
That does not detect the host. It just detects the first person that is playing. Example player 2 is host player 1 is playing. The above will think that player 1 is the host when player 2 is actually the host.
That does not detect the host. It just detects the first person that is playing. Example player 2 is host player 1 is playing. The above will think that player 1 is the host when player 2 is actually the host.
There is no such thing as a "host player" so it is impossible to detect one. This is a fallacy that came about because the game tries to enforce that every host server created is automatically joined by a client originating on the same system (the behaviour shown when you host on BattleNet using the game client itself). Host robots only run the server and decouple this relationship that the game tries to force.
Basically every human player in a session is a peer. There is no distinguishing features between them as far as connectivity goes. Sure some clients may be running on the same system as the server but in the end they are still a client communicating with the server exactly the same as all other clients (probably even through the same TCP/IP layer).
It is possible to detect the player with the lowest server side latency. This is what the fake "host detection" system actually do. When a session starts, the player with the shortest latency starts first and so will execute synchronization natives first allowing a variable to be synchronized based on his state. Using GetLocalPlayer you can get which player the client is representing and synchronize that with all clients. The result is the player which began the session first (lowest client to server latency) is stored in a variable.
In the traditional hosting constraints enforced by the game client this will mostly return the player who's client is also the server since he is physically at the server (nearly no latency). However this is not always the case as people on a LAN with faster computers might be able to communicate to the server faster than his bottle-necked system can communicate to itself. If his system is really overloaded (CPU bottleneck) it is possible that even a highly remote system will load before he does and so be counted as host. This means even with the traditional contact of hosting the results can be wrong.
For this reason there are only 3 reasonable solutions.
1. Assign a fixed slot as a master slot. This slot has power above all other slots to do things like game setup. The person who creates a server can place himself in this slot for full control.
2. Democracy rules. Treat everyone equally and use majority vote to dictate settings.
3. Use a custom server to synchronize external values into the session. The server itself may have some awareness of ownership and concepts like "hosting player" which it can then pass into the session in the form of synchronized integer values. These can then be used to promote the specified player to master over the session.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.