Frequently Asked Questions
EECS doesn’t find the IWAD.
Put the IWAD (for example,
doom2.wad) in the
user/wads folder. By default
this will be
C:\Program Files\Eternity Engine\user\wads.
Client hangs in the full-screen console before connecting.
You might need to enter a password. Be sure to read the text in the console to make sure it’s not asking you to input a password.
A weird box pops up in the browser when clicking on server links.
It’s asking you if you want to launch Eternity, which you do.
Clicking on server links doesn’t work on Vista.
- Uninstall Eternity using the uninstaller
- Reinstall Eternity to
Whatever you do, do not ask mikehail about this. Not even once.
Clicking on server links doesn’t work on Linux.
The server links use the
eternity:// protocol, and there’s no 100% sure way
to set protocol handlers in Linux. If you’re using Firefox or you have Gnome
libs installed, you can try the instructions
Personally, I launch EECS from the command-line like:
eternity -csjoin eternity://master.totaltrash.org/servers/totaltrash/ctf.
We plan to fix this as well.
Blood spawned from shots doesn’t seem to match up with damage.
EECS has a
predict_shots option that predicts shot collision and spawns
bullet puffs or blood instantly instead of waiting for the server. While this
feels more “crisp”, it can be inaccurate, possibly resulting in the feeling
that too much blood gushes out of your opponent when you shoot them. You can
no to disable this, but while shot results will be
accurate, they will be lagged.
After alt-tabbing to a different application, part of the EE screen is frozen.
This is likely an SDL bug, and it only shows up in Windows Vista and Windows 7
with Desktop Video Acceleration disabled. To work around it, use EE’s GL-in-2D
i_videodriveridto 1 (SDL GL2D)
Using VSYNC on some video drivers will cause mouse input to be lagged. To avoid this, disable VSYNC in your video driver’s configuration.
Mouse gets slightly “stuck”
The mouse may be sampled unevenly due to Doom’s 35Hz framerate cap, and this
may result in the mouse feeling like it’s “stuck” turning or moving. To avoid
EE supports TTF fonts, and adding them is as simple as copying the font file
arial.ttf) to the
EECS has both clientside and serverside buffers designed to improve smoothness, however, the tradeoff is increased latency.
Clientside packet buffer
The client has an optional packet buffer that buffers messages received from
the server. Players can enable the packet buffer using
they can set the size using
packet_buffer_size A size of
0 causes the
buffer to adapt to your latency and packet loss. Other sizes specify how many
TICs of messages to buffer. Again, be aware that the larger the buffer, the
more latency is artifically added to your connection.
Serverside command buffer
The server has an optional command buffer that buffers commands received from
every client. This is enabled/disabled using the
option in the server configuration file. The buffer is adaptive; size cannot
be set manually.
show_netstats command can help players get an idea of their connection
quality. To enable them, type
show_netstats yes into the console.
The 1st number is the number of TICs it takes for a message to arrive from the server to the client.
The 2nd number is the current number of TICs that are buffered in the clientside packet buffer.
The 3rd number is the number of your commands the server has buffered in the serverside command buffer.
The 4th number is the percentage of packets that successfully arrive at the server the first time they’re sent. If this number is less than 100%, it doesn’t mean information is being lost; packets that are lost are always resent. However, resending adds to your latency.
One of our design assumptions was “bandwidth is cheap”. If you are using a modem or your internet download bandwidth is less than 256kbps (that’s 256 kilobits per second, or 32kB/s is the max you see while - for example - downloading in your browser) you will almost certainly have serious problems playing EECS.
To be specific, a player’s minimum position requires at least 32 bytes. We have to add 16 bytes to that for sequencing and identification (position for which player at which TIC), for a grand total of 48 bytes. Assuming a 16 player server, you are receiving 15 positions every TIC, so 525 positions per TIC. 48 * 525 is 25.2kB/s, or 201.6kbps.
This is a best-case scenario, because we’re assuming there are only 15 other actors (players, monsters, plasma balls, etc.). Cooperative games will requires more bandwidth, especially WADs with a huge amount of monsters. Additionally we are only calculating bandwidth used by position messages. While they are certainly the lion’s share of messages, there are over 30 messages overall; in particular moving platforms will send a large amount of (small) messages.
We plan to be more flexible in this area in the future. Other ports (Odamex and ZDaemon that we’re aware of) allow you to specify your update rate so you have the option of reducing your incoming bandwidth 50%-67%, but you pay a high price in accuracy. Because of our focus on competition, we always err on the side of accuracy, however we recognize that not all players are competitive and may not mind or even notice the difference. On the other hand, we also plan to optionally use more bandwidth to alleviate some of the negative effects of packet loss.