Message Boards

Sloped water is not supported only in the sense that it wasn't something I anticipated and therefore did not test! I don't think it will be too difficult to look next time I look at the transfer heights/deep water stuff.

The terminology that DoomBuilder uses for the format you want is "ZDoom (Doom in Doom Format)". The following are the numbers for the slope linedef specials in that format:

340:       // Slope the Floor in front of the line
341:       // Slope the Ceiling in front of the line
342:       // Slope the Floor+Ceiling in front of the line
343:       // Slope the Floor behind the line
344:       // Slope the Ceiling behind the line
345:       // Slope the Floor+Ceiling behind the line
346:       // Slope the Floor behind+Ceiling in front of the line
347:       // Slope the Floor in front+Ceiling behind the line


That's unfortunately due to the PortMidi and PortTime libraries being combined on some Linux systems but being separate libraries on others. Our build system for Odamex 0.6.2 works around this problem.

The simplest way to work around this compilation problem is to disable PortMidi support in Odamex until we release Odamex 0.6.2 in a couple days.

You can disable the PortMidi library by opening the client/sdl/i_musicsystem.h file and changing the following lines near the top of the file from:

#ifdef PORTMIDI
#include "portmidi.h"
#endif  // PORTMIDI

to be:

#undef PORTMIDI
#ifdef PORTMIDI
#include "portmidi.h"
#endif  // PORTMIDI


Thank you!

We've also noticed the majority of players in locked servers around the times we check.

Is this normal or a glitch of some kind?

That's most likely the IDL private CTF servers. It's not private to exclude newcomers - it's more like the password is freely available but it's password protected to make sure players are aware of the server's rules and how the system of organizing games works to prevent frustration for all involved.

Instead we decided it would be neat to see some of the other levels you'll go into or just left outside a window, ect, of the level you're currently in.

I'm currently doing the same thing with a few of my own deathmatch maps. It's a pretty cool concept!

PortMidi with CMake has gotten some attention by us since the 0.6.1 release and is hopefully now good to go. Have you tried building SVN /trunk in the last few weeks?

Background:
A ticcmd is a collection of data that represents the action buttons a player presses during a particular gametic (1/35 second frame). This includes the amount of movement in the forward/backwards direction, the amount of movement in the left/right direction, status of the +use, +jump, and +attack buttons, and the desired view angle and view pitch.

The ticcmd queue was introduced in Odamex 0.5.6 as a means to smooth the stream of ticcmds going from clients to the server so that the server can process one ticcmd every gametic on average and keep players moving smoothly regardless of sudden spikes in network latency (also called network jitter). At the start of a gametic, the server will enqueue incoming ticcmds for each player and then process the first ticcmd in the queue. If there is a latency spike, the player will typically have a period where the server doesn't receive any ticcmds from the player and then will subsequently receive several ticcmds at once. The means the player's ticcmd queue will be shrinking (or empty) for a few gametics and then will suddenly grow with several ticcmds.

Problem:
When a player has a latency spike, they are often left with a ticcmd queue with several ticcmds. This creates additional latency between when the player sends the server the ticcmd and when the server processes it. Additional latency is undesirable and Odamex attempts to reduce this latency in a couple manners.

The server will process all of the ticcmds in a player's ticcmd queue when the player is dead, since the dead player does not require smooth movement. Additionally, if a player is not visible to any other players, the server will process 2 ticcmds once every 0.5 seconds as well as if the player is standing still.

Although these methods allows the player reduce the size of their ticcmd queue, it is far from ideal. Odamex may need other ways to reduce the queue size. I hope to gather data regarding ticcmd queue size during gameplay for informational purposes.

I'm assuming that Odamex loads and stays in the full console mode instead of connecting to a server and joining a game.  It's difficult to guess exactly at the problem when you say "nothing happens", so could you take a screenshot for us?  You can do that by simply entering "screenshot" into the console, which I hope will give us all the relevant debugging info.