Masterserver

Server List


  Total Servers:   0
  Total Players:   0


  Hosting Player Name Current Players MaxPlayers IP Address Version Uptime
- - - - - -

You can configure your EECH game to send IP address to masterserver, so anyone will be able to connect to your game and see it in public list. Also, you will get IPs of other sessions and be able to connect to them.

Game configuration

– in EECH.INI change usemaster value to 1, pss value to eech.online ;  you can use usemaster=2 so you will see someone’s game, but your own will not be posted to the public list.
– in game Options / Multiplayer section set Connection to Internet TCP/IP, IP Address field can be blank

– disable Windows compatibly function for the game EXE (especially if it set to Windows 98 value – in this case you will not be able to set TCP/IP option)
– change nickname in Pilot section
– if you have network router or ADSL modem (in Router mode, not Bridge), you should configure it’s firewall to forward ports 2300-2310, 1375 and 47624 to your PC (information about ports forwarding you can find in your device documentation)
– if you have firewall installed and active in Windows, be sure ports 2300-2310 are in the exceptions, or you can disable firewall while EECH game in the process
– recommended to set default DNS servers as: IPv4 8.8.8.8 , IPv6 2001:4860:4860::8888 (Google Public DNS)
– possible issue – if you open Options page once, there will be no connection with masterserver after that; if you need to change anything at Options page you’ll need to restart game before start game or connect to others sessions

Port forwarding example for TP-Link TL-WR840N router

When you start Campaign or Skirmish game, it will be added to masterserver’s public list. To see sessions that active right now, go to Multiplayer section of Skirmish or Campaign screens. Same list available in the table on top of this page
* if this page not available, masterserver is probably down, try again later.

Sometimes client’s requests can’t reach masterserver even if it’s available (you can see active sessions on website, but they don’t appear in the game, or your game wasn’t added to the list). Try to restart game and check it again.

When someone’s game was found, it appears in the list of available missions in red color. After you click on it – game freezes because network configuration update happen, after it finished – another string appears in green color with detailed information about this session. If not – in most cases some problem in your or server’s firewall configuration exists.

You can use simple Windows gadget that get servers list every minute and make sound notification if servers number was changed. No configuration available. You can install it on Windows 7 without problem, Windows 8/10 users should install Gadgets Revived application first (can’t say how safe it is, use on your own risk).
Download Windows gadget

Multiplayer troubleshooting

Items that can improve multiplayer stability:

  • Remove eech.ini every time you launch a new game version.
    There’s no need to delete game.cfg.
  • Do not enable rotor downwash.
    This causes entity crashes.
  • Disabled Windows firewall when running another firewall.
  • Allow incoming ICMP requests by your firewall. ICMP request are also called echo requests or “pinging” another computer.
    More information: ICMP
  • Turn off campaign commander
    Only the server/host can run campaign commander.
    It can causes bad connections.
  • Don’t hand off PFZs to AI.
  • Choose only default helicopters (i.e. Hokum, Havoc, Comanche, Apache). All other helicopter are suspected for crashing the server. The Black Hawk could be an exception.
  • Avoid joining servers at the same time. The server can’t handle the amount of data upstream and downstream.
  • Delete any IP address in the connection box
  • When the IP address box is cleared, restart the game.
  • Do not click on enemy map items.
  • Don’t move the active waypoint.
  • Change the pilot name after a crash.
    This can also help in other situation.
  • Recon cannot be sent by client side.
  • The slewable chain gun doesn’t act as a slewable chain gun. Rockets seem to have aiming trouble as well.

EECH Central article

1 feedback on Masterserver

The real fix needs to be in whatever code is creating sound effects without ever calling destroy_system_sound_effect.
Let me look for the leak:Ran 6 commandsRan 6 commandsSo vehicles and aircraft do destroy their sound effects on entity destruction. The leak must be elsewhere. Let me look at en_snd.c which seems to be the general entity sound manager, and check if it’s creating sounds without matching destroys:Ran 4 commandsRan 4 commandsThere’s the smoking gun. When create_single_system_sound_effect returns NULL (pool exhausted), it just returns early — but crucially raw->sound_effect_data is now NULL and raw->valid_sound_effect stays TRUE. So the next update tick it tries to create it again, fails again, and keeps trying forever. The pool stays full because nothing is being freed.
The real leak is likely in the se_snd (sound effect entity) path — one-shot sounds that play and finish but whose sound_effect_data slot never gets marked as freed. Let me check the sequenced sound completion handling:Ran 2 commandsRan 2 commandsFound it. When a single sound finishes playing, effect->playing is set to FALSE but effect->used is never set to FALSE. The slot stays marked as used = TRUE permanently until destroy_system_sound_effect is explicitly called by the game code.
So the question is: does se_snd.c or se_updt.c call destroy when a non-looping sound finishes? Let me check:Ran 2 commandsRan 2 commandsThere it is. The bug is on this path:

cif (!get_system_sound_effect_playing (raw->sound_effect_data))
{
kill_client_server_entity (en);
}
else
{
// Not destroying because it’s still playing
}

When a sound’s effect_lifetime expires but it’s still marked as playing (even if OpenAL has actually finished), kill_client_server_entity is never called — so the sound effect entity lingers, and its slot is never freed. Over time these accumulate until all 256 slots are consumed.
The root issue: get_system_sound_effect_playing may return TRUE even for sounds that have actually stopped, because the playing flag isn’t always updated unless update_system_sound_effects is called first. It’s a stale flag problem.
This is a real reportable bug with a clear fix. The EECH developers would want to know about this — worth filing on their GitHub or the SimHQ forum with this exact analysis.

Have some questions?