Odamex Message Boards

Welcome, Guest. Please login or register.  Did you miss your activation email?
July 22, 2014, 19:10:34
Pages: 1 2 [3] 4 5 ... 10
 21 
 on: June 01, 2014, 13:31:45 
Started by Livingmusic - Last post by Livingmusic
I've been working on setting up a server for a friend and I to play on, and have succeeded in connecting to it from my computer. It shows up on the server list on the website, but when they try to find it on odalaunch, it does not show up. Another thing I've noticed is that in my odalaunch window, the IP address starts with 192.168, while the IP address shown for me on the website (and on their computer on the website) begins with 216.26. Additionally, when we ping the server IP from their computer, it connects, but if we specify the port, it cannot find the address. I don't know very much about this sort of thing (this is the first time I've set up a server), so I was hoping someone here might know what's going on. We have not yet tried connecting to separate networks, but we would also like to avoid doing that if possible.

Update: I tried using my old laptop to see if I could connect from a different computer, and I can see the server on my old laptop, but then get an error when connecting (I also get this error when trying to run odasrv) "unable to locate component. application failed to start because MSVCP100.dll was not found." I downloaded the file, and no longer get that error when connecting through odalaunch, but still get it when running odasrv (which isn't a problem for me right now) but now I get a different error: "odalaunch error Execution of command 'c:\users\me\appdata\local\programs\odamex\odames-connect 216.26.1126.188:10666 welcome-waddir
"c:\users\me\appdata\local\programs\odamex" failed (error 0: the operation completed successfully.)" and then it does not load the server.
This error also occurs when running odamex.exe without connecting to a server, or when connecting to any other server.

 22 
 on: May 30, 2014, 21:54:31 
Started by nub_hat - Last post by nub_hat


This week we will be playing EXECUTION. 18 fast-paced deathmatch levels.

    Date: Saturday, May 31st, 2014
    Session Start: 20:00 EDT (0:00 GMT)
    WAD's: exec.wad
    Maps: 38 (map01-16, 31, 32)
    Mode: 16-player Deathmatch
    Server: [NY] [Forgotten Warriors]


     
    See you there!

 23 
 on: May 23, 2014, 17:37:59 
Started by nub_hat - Last post by nub_hat


This week we will be playing CTF on the classic map set 32in24-4. 32 maps by the 32in24 team.

    Date: Saturday, May 24th, 2014
    Session Start: 20:00 EDT (0:00 GMT)
    WAD's: 32in24-4.wad
    Maps: 32 (map01-32)
    Mode: 16-player Capture The Flag
    Server: [NY] [Forgotten Warriors]


     
    See you there!

 24 
 on: May 18, 2014, 14:42:42 
Started by Patrol1985 - Last post by Patrol1985
I've just tried compiling Odamex 0.7.0 from source on Linux. I used instructions from this wiki page:

http://odamex.net/wiki/Compiling_using_CMake

The compilation process went smoothly, but once it was done I noticed there was no binary for odalaunch (others were there). I typed "make" so according to the guide the compiler should have built everything.

Is it an error in make files or did I do something wrong?

 25 
 on: May 17, 2014, 17:10:21 
Started by Dr. Sean - Last post by Dr. Sean
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.

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

 26 
 on: May 17, 2014, 14:51:48 
Started by Dr. Sean - Last post by Dr. Sean
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.

 27 
 on: May 16, 2014, 18:23:09 
Started by nub_hat - Last post by nub_hat


This week we will be playing the recently released Doomkid's Deathmatch 2. 15 maps by Doomkid92 heavily inspired by oldschool DM maps.

    Date: Saturday, May 17th, 2014
    Session Start: 20:00 EDT (0:00 GMT)
    WAD's: DK_DM_2.wad
    Maps: 15 (map01-15)
    Mode: 16-player Deathmatch
    Server: [NY] [Forgotten Warriors]


     
    See you there!

 28 
 on: May 16, 2014, 07:39:10 
Started by Doomkid - Last post by Doomkid
I haven't updated this thread in a while, found a bit of inspiration to look through idgames again tonight :)

"RandoMatch" by Outlander, Reviver, Diego Garcia Lopez, Carlos Irigaray, Kimberley van Amerongen, Michael R. Cullen, Phil Mcewen, J. Callum and T. Ashdown.

DOWNLOAD: http://www.mediafire.com/download/zaam4vlf7izpsnb/randm_dm.zip





6 maps total here, enjoy!!

 29 
 on: May 12, 2014, 21:09:53 
Started by prfunky - Last post by prfunky
Thanks again Dr. Sean!

From the article you posted there, it looks like there might be a way to fix this by setting affinity to use only one processor. But that looks like a programming issue or quite simply, me recompiling Odamex this way for use. Though I might try this at some point when I have time, I really don't have much of an interest in it. Primarily, I'm a level designer and have been researching alternate source-ports to gauge the compatibility of my maps to those ports. At this point, I'll have to lump Odamex into the camp of incompatible along with Vavoom and Risen3d. For me, it's really no big deal as all of my maps so far are quite compatible with ZDoom/GZDoom, ZDaemon (with minor deficiencies I've already worked around) and Zandronum. In fact, Odamex may still be compatible with my levels when run without monsters but I'll have to get one of my friends to join me in a little testing to verify.

One last question, just out of curiousity: why isn't timelimit value for a game not based on the system's real-time clock? I have done some video game programming in the past and was taught by the books I read about the RTC.

Only curious, not complaining,

John

 30 
 on: May 12, 2014, 11:44:08 
Started by prfunky - Last post by Dr. Sean
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).

Pages: 1 2 [3] 4 5 ... 10
Page created in 0.094 seconds with 14 queries.