Message Boards

All I can really say is, I’m actually stunned. I mean, at 11, I don’t think I could’ve done what she had done in a matter of months with all that learning involved. Shoot, I don’t think I could do that now =P

Why do you think so? Do you think that 11 year olds are dumb or something?
BTW, the link is broken.

I have resolved every issue within Odamex's setting with the exception of the scripts that do not work. I.E. in Darkest Hour when you grab your space suit, it is supposed to allow you to open the doors to go outside where the gravity is lighter, but still it tells me that I need my suit on first.

Because in Odamex, ACS inventory checking functions are commented out.

However, there are probably still small bugs. One that is noticible is the exit pipe at the foot of the dam.

While walking along the dam to get to the end where the staircase down is, for some reason the pipe bleeds all over the place and we can't seem to find the cause. This doesn't happen in Zdoom and there appears to be no improper textures.

I cannot find a place with such a bleeding texture in the current download. Is it fixed already?

All teleports that I could find work (using the latest SVN build of Odamex). I think it was fixed a few days before.

Regarding the soundtrack, have you considered using MIDI and moving the high-quality version in a separate pack? Also, MP3 is obsolete. For in-game music, you should use Ogg Vorbis instead of it; it will allow you to either have a better quality with the same size or smaller size with same quality. (If you decide to use Vorbis, don't transcode from MP3, encode the lossless originals instead.)

I hope to gather data regarding ticcmd queue size during gameplay for informational purposes.

Is that your "ticcmd_queue logging test" server?

I'll repeat my (draft) proposal.
Just trying to make the player move slowly enough is not quite correct; Doom doesn't allow you to stop suddenly unless you crash into an object or a wall. So speed should be changing slowly as well.
Not knowing a few consecutive ticcmds doesn't introduce much uncertainty to player position. (It grows quickly with the number of ticcmds, though.)
The current behavior, however, somewhat helps client experiencing a short latency spike by suddenly stopping them and thus disrupting their enemies' aim. Creating artificial latency spikes is, however, useless for cheaters, because of the additional latency which can't disappear at cheater's will (the queue on the server).
Ticcmd queue is also, in effect, an anti-speedhack. This should be preserved also.
Thus, I propose the following:
- If the server stops receiving ticcmds form the player and exhausts the ticcmd queue, start to estimate possible player positions. As long as uncertainty doesn't exceed some threshold OR the player cannot be visible anyway, predict the player position and increment the player's counter. (Client probably should be aware that player's position is server's speculation.) When it does, stop predicting.
- When the lost ticcmds arrive, immediately execute counter commands, set counter to zero, and put the rest in queue.

Notes:
If we're uncertain if player will cross a special line, stop predicting.

Problems:
- If the player firing command was lost, it might have been better for him to be "frozen" and hope the enemy will miss adn his own shot will hit.

In coop, ticcmd queue doesn't help much but ensures that monsters will kill you. It probably should be off in coop configs.

Yes.

As for vetting gametypes, I think that this runs contrary to "everyone policing his own server" goal. Just not providing dedicated functionality to implement AOW-style mods (but still keeping it theoretically possible) is as much (IMHO) as Odamex project should ever do for that purpose.

Option #2 is not worth any serious consideration for the reasons above and also because it's not cross-platform compatible.
#1 has been in effect already for a few years. Some proposals have been made but none implemented AFAIK. Its benefit is that clients can do better prediction than is the case with (limited) scripting language (#3).

As for original question: Those features which are needed by maps considered important to support, and those with technical merit that simplify editing (or allow some new features) for Odamex. (FWIW, IMO ACS and Hexen format bots are messy and lack technical merit. Although some parts of it have some merit. So the question is: what "important" maps need?)