Message Boards

The "raw input" mouse code does indeed require Windows 2000 or above. Although I made attempts to detect if the user had an older version of Windows and disable the feature, ultimately I do not have a Windows 98 system to do testing. I can look at the detection code in the future. Ultimately though, I think our documentation needs an update.

Note that these apply to Odamex 0.7 and may change in future versions!

rate ("Bandwidth" in the Network Options menu)
Sets the maximum bandwidth the client can receive, measured in kilobytes per second. The default value is 200, though setting it higher to 750 will allow for faster in-game downloading if the server allows it.

cl_unlag ("Adjust weapons for lag" in the Network Options menu)
Allows the client to enable or disable backwards reconciliation ("unlagged") for hitscan weapons. Enabled by default, this setting allows a player to aim directly at enemies when firing hitscan weapons such as the shotgun and chaingun.

It works as follows:

• Every gametic (there are 35 per second), the server records the position of every player.
• When the server sees that a player with round-trip latency of X milliseconds pressed the fire button, it temporarily moves all other players to the position they were in X milliseconds ago.
• The server determines if the shot hit anyone.
• Players are moved back to their current position.

cl_updaterate ("Position update freq" in the Network Options menu)
Indicates the frequency of position updates a client wishes to receive. The default value of 1 indicates they wish to receive an update every gametic while a value of 2 indicates an update every 2 gametics. More frequent updates lead to greater accuracy at the expense of more bandwidth usage.

cl_interp ("Interpolation time" in the Network Options menu)
Allows a client to smooth the movement of enemy players due to network jitter in the connection between that particular client and the server. This smoothness comes at the expense of increased visual latency.

If the most recently received position update is N, the default value of 1 will display players at position update N - 1. Similarly, a value of 2 will display players at position update N - 2.

Network jitter causes the client to not always receive position updates in a timely manner. If a client displayed position update N - 1 last gametic and has yet to receive a new position update from the server, it can display position N, maintaining accurate, smooth movement even when there is jitter or small latency spikes.

cl_predictlocalplayer
Allows the client to enable or disable client-side prediction of a client's player position. This prediction, enabled by default, allows the client to immediately move its player position based on controller input instead of waiting for confirmation of a new position from the server. This is much more responsive compared to the alternative, which does not change the player position (and in turn the rendered view of the world) until the the client's round-trip latency time to the server has passed.

Although prediction allows for immediate visual feedback, it can also be incorrect. This is often the result of collision with other players or being thrust by weapon damage. When the prediction is incorrect, the client considers the server to be authoritative about the real position of the client's player.

Although most players would find it difficult to play with this CVAR disabled, it is immensely useful in diagnosing recordings of games for debugging purposes.

cl_prednudge ("Smooth collisions" in the Network Options menu)
Sets the amount of interpolation between a client's mispredicted player position and the corrected player position from the server. Valid values range from 0.05 to 1.0. The client can choose how they want to trade off between smoothness and accuracy when their player position is mispredicted (see cl_predictplayerposition for further background information). A value of 0.05 will nudge the player towards the correct position gradually and as smoothly as possible where as a value of 1.0 will instantly jerk the player to the correct position to be as accurate as possible.

cl_predictweapons

cl_predictsectors

cl_predictpickup

I am fairly certain that this is an issue related to Odamex and Odasrv using the Windows API QueryPerformanceCounter to provide timing functionality.

The following article gives a brief overview of using that API for games: http://msdn.microsoft.com/en-us/library/windows/desktop/ee417693%28v=vs.85%29.aspx

Of particular note, the article provides links to two additional articles detailing issues with AMD dual-core CPUs and Windows XP. You can try the work-arounds provided in those links. Alternatively, we can look into using an alternative timing function in a special binary for you (if possible).

You should try installing the X11 library development package (probably libx11-dev).

Those node builders all seem to have their own extended node formats to get around vanilla Doom limitations. PrBoom+ has code to handle DeePBSP and glBSP nodes as well so it's not surprising that Odamex can't handle them (it only has code for vanilla Doom format nodes).

Are there any ports that successfully handle the test map? PrBoom+, Eternity, and ZDoom 1.23 all appear to have similar code for R_PointInSubsector. If any of those ports can handle the map, then I can probably assume that the NODES lump of the map isn't being correctly parsed by Odamex prior to trying to call R_PointInSubsector the first time.

If you don't mind uploading the map and posting a link, we'll gladly take a look at exactly what's causing the crash. We can't really tell much from your description but I'm sure a debugger will make easy work of it.