• 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!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.

Help Me How to detect host

Status
Not open for further replies.
Level 4
Joined
Mar 13, 2014
Messages
93
  • Detects Host
  • Events
    • Unit - Player 1 Enter chat string -deathmatch as an exact match
    • Or - Any (Conditions) are true
    • If Player 1 Is A Computer
      • Actions
        • Turn ON Player 2 Host
  • Actions
    • Set Game Mode To Death Match
 
Level 18
Joined
May 11, 2012
Messages
2,103
  • For each (Integer TempInt) from 1 to (how many players there are in your map), do (Actions)
    • Loop - Actions
      • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        • If - Conditions
          • ((Player(TempInt)) controller) Equal to User
          • ((Player(TempInt)) slot status) Equal to Is playing
        • Then - Actions
          • Set MainPlayer = (Player(TempInt))
          • Skip remaining actions
        • Else - Actions
Use this trig in Init trigger (if you have one) and just refer to that player variable.
 

Dr Super Good

Spell Reviewer
Level 64
Joined
Jan 18, 2005
Messages
27,258
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.
 
Status
Not open for further replies.
Top