Message Boards

 Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Dr. Sean

Pages: [1] 2 3 ... 5
My best guess is that you're running a build that isn't compatible with your system architecture like a 64-bit build on a 32-bit system. Also, it looks like the most recent Odamex version that drdteam offers is 0.8.1:

You'll need Odamex 0.8.3 to connect to servers so you will want to compile the binary from the source. We have pretty good instructions here:
By building the binary yourself, you'll be assured that the binary is compatible with your system architecture.

Good luck!

Technical Support / Re: Win9x support...sure...

« on: September 07, 2014, 11:46:31 »
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.

General Discussion / Re: idk im bored

« on: August 20, 2014, 21:43:24 »
What is your username and what does it mean?
Dr. Sean
I'm known among a group of friends for making problems go away and they started calling me 'doctor'. When we started playing Doom together, the name stuck.

What was the first doom you ever played? (Doom, Doom 2, Final Doom, Doom64, Doom3)
Shareware Doom v1.1, waaaaay back in early 1994.

What was the first (unofficial) source port you ever played and when?
A group of friends and I were talking about old games from childhood/teen years while at work and Doom came up in the discussion. Some bragging ensued and egos had to be put to into check with some DM so I set everyone's computer up with Chocolate Doom and we ran around killing each other. But given that this was an office and real work had to be done on occasion, a client/server port was necessary so that players could join or leave at any time. The next day, I set up Odamex 0.5.0 for everyone and haven't looked back. I joined the Doom community in April of 2011.

What was the first (unofficial) pwad you ever played and when?
I don't really remember but the first that stood out was danzig1.wad. I used to watch 4 player LMPs of danzig1/2 for hours because I could only play 1v1 via modem.

What is your favorite game mode?

If you are in a clan, what clan and why are you in it?
I'm an officially unoffical member of UD because of my contributions to Doom and UD-related projects and I'm probably a half-way decent player at times.

What is your fondest memory of multiplayer Doom?
Playing with my buddies at work for 4 hours a day for two years!

Devoblog / Network-related Client CVARs

« on: May 17, 2014, 18:10:21 »
Network-related Client CVARs

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.

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.




Devoblog / Overview of Hitscan Latency Compensation (Unlagged)

« on: May 17, 2014, 15:51:48 »
Hitscan latency compensation is a topic that causes a great deal of confusion as to how it works and what side effects are to be expected. The community has long ago adopted the term "unlagged", which in itself is a source of confusion but hopefully this post can clarify several points. For further detail on the topic, please read this excellent overview by Valve, from which Odamex's algorithm was derived.

For the examples in this explanation, we will consider two players: Player A with a 150ms ping and Player B with a 20ms ping.

Background info:
Odamex has a fixed frame-rate of 35fps, which means each frame lasts roughly 29ms. That also conveniently corresponds to the network update rate and the game physics update rate.

Odamex also uses a term "world index" to refer to the particular set of actor positions that the client has received from the server and uses to draw the sprites for actors in the game (enemy players, etc).

How it works:
When Player A aims directly at Player B and presses the fire button, his Odamex client will send all of his input (eg, fire-button, mouse angle, etc) to the server as well as the current world index. The server will receive this input from Player A 75ms later. During this time, Player B may have moved significantly and without latency compensation, Player A would miss his shot.

With latency compensation, the server will temporarily move all players except the shooter to their position in the world index that was received from the shooter. In the case of Player A shooting, it means that Player B would be moved to his position 150ms ago. The server then performs hitscan collision detection and then moves all of the players back to their current real position. This compensation allows Player A to aim directly at Player B and successfully hit him, even with adverse network conditions.

One side effect of this compensation can be seen from the point-of-view of Player B. It is possible for Player B to have gotten behind cover of a wall and still be shot by Player A. This is due to the fact that Player A has high latency and thus his input takes a noticeable amount of time to reach the server and during this time, Player B can move behind a wall. The latency compensation will temporarily move Player B to his position at the time Player A pressed fire, which was directly in the line-of-sight of Player A.

Hopefully this description is not too technical and also did not omit any details that are necessary for understanding the way latency compensation works in modern FPS games. Let me know and I can further clarify any points which are not clear.

Technical Support / Re: clock running too fast

« on: May 12, 2014, 12:44:08 »
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:

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).

Technical Support / Re: clock running too fast

« on: May 07, 2014, 09:58:24 »
There are several engine functions to return the number of milliseconds since the game began execution. Which operating system are you running this server on?

Technical Support / Re: Error build 0.7.0 in ubuntu 12.04.

« on: April 07, 2014, 21:25:14 »
You should try installing the X11 library development package (probably libx11-dev).

Technical Support / Re: Error build 0.7.0 in ubuntu 12.04.

« on: April 05, 2014, 11:16:19 »
Did you compile SDL 1.2 yourself? A quick glance in other forums indicates that the SDL library that Odamex is linking against may not have been compiled with X11 support.

Technical Support / Re: Odamex Map Limits

« on: September 24, 2013, 14:53:31 »
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).

Technical Support / Re: Odamex Map Limits

« on: September 24, 2013, 14:33:41 »
After investigating a little further, it appears that your test WAD makes use of the ZDoom Uncompressed Node format. It's my suspicion that ZDBSP may automatically switch to this format if a map has over a certain threshold of SEGS or VERTEXES. It appears that both Eternity and PrBoom+ have code for handling this format. While adding code from one of those two sources is certainly possible, it may not be an entirely trivial task. I will file a bug report (feature request) on our bug tracker as a reminder to look into adding support for this format.

Technical Support / Re: Odamex Map Limits

« on: September 24, 2013, 14:19:46 »
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.

Technical Support / Re: Odamex Map Limits

« on: September 24, 2013, 13:43:49 »
When loading this map (specifically trying to spawn the player), Odamex gets caught in an infinite loop trying to insert the player into the list of actors in a particular subsector with the R_PointInSubsector function. R_PointInSubsector iterates through all of the BSP nodes trying to find a leaf that's a subsector. In this WAD, BSP node #0 has two child nodes, #0 and #64978. The fact that node #0 has itself as its own child creates an endless loop.

Technical Support / Re: Odamex Map Limits

« on: September 24, 2013, 10:43:10 »
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.

Devoblog / Netcode White Papers / Videos

« on: September 17, 2013, 17:55:40 »
As players often wonder how Client/Server games work "under the hood", I'm creating a small thread that lists some important white papers in the field of client/server game programming.

This paper describes the architecture of the TRIBES engine and subsequent TNL library.
Video and slides for similar information:

This paper describes Doom 3's architecture, which is an advancement over Quake 3 Arena.

This paper describes the CounterStrike architecture and the specifically client prediction of position and latency compensation for weapons.

This video describes Halo's architecture, which is based heavily on the TRIBES architecture.

Pages: [1] 2 3 ... 5