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.

Topics - Ralphis

Pages: 1 2 [3] 4

Devoblog / Doomseeker 0.2a; now with Odamex support

« on: May 24, 2009, 11:31:56 »
The new cross-platform server browser, Doomseeker, has just been released with support for the current version of Odamex.

Doomseeker boasts some of the fastest speeds seen on server browsers yet. Other useful features of the browser are a search filter for servers, buddy lists, and plugin support for other multiplayer engines. Doomseeker also utilizes Wadseeker, a quick, GetWAD alternative.

Doomseeker appears to be a nice alternative to those who do not prefer the native Odamex launcher or IDE. To download Doomseeker, visit their download page to select your platform.

Devoblog / Apple OS X package available once again!

« on: April 16, 2009, 18:45:03 »
After an eighteen month wait, Odamex has an official Mac OS X package once again! The package works on both x86 and PPC systems and has been confirmed to work with OS X 10.4 and higher.

This has been one of the most frequently received requests from our players. Many thanks go to Hyper_Eye who took the time to prepare and package Odamex for our loyal (and patient) Mac users.

To grab the package, click the Apple at the top of our home page.

Developer's Corner / Ready Mode/Round System Design Document/Proposal

« on: October 14, 2008, 19:24:16 »
Ready Mode/Round System
Design Document

[What is the Ready Mode/Round System?]

The purpose of the Ready Mode/Round system is to allow server administrators the option to offer players a more controlled, competitive environment.


The idea of ready mode/round system stems from mods for various modern games, perhaps most notably Quake 3's CPMA. Skulltag also has a similar, yet different design than the system detailed in this document. Alexmax's input (found in bug 238) was also reviewed for this draft.

[Server Implementation]

This system calls for the server to have four different states if the ready mode is enabled.

1) Warm up/Join
2) Begin round
3) End round
4) End Game

{Detailed Explanations of the Four States}

1) Warm up/Join

The warm up/join state is arguably the meat of this feature. In the warm up mode, players will get in line to play. If they are due to play in the upcoming round, players will be able to play freely without scoring until one of two conditions are met:

a) A server determined time limit on warm up is met
b) All players set their status to "ready"

Once one of these conditions is met by players in warm up mode, the engine will move on to begin the round.

2) Begin Round

Once this state is reached, the server must soft reset the map and spawn all players on the same tic.

The soft reset calls for the map to return to its original state without an engine reload of the map. This includes sector states, items, and anything else dynamic found within a map. When this is acheived, all players should spawn in immediately at the same time.

3) End Round

To end the round, conditions that normally would end a game without ready mode (fraglimit, timelimit, scorelimit) should still apply. If the new ready mode cvar, "sv_readymode" is set to 1, this will simply end the round and return the game to the warm up/join state.

If other players are waiting in the queue (this applies more heavily to 1on1 type play), the losing players are knocked out of the queue and others waiting enter ready mode with those that won the round. In a team based game, players may not be ejected from their teams.

4) End Game

The game can finally end if a new cvar, "roundlimit", is met. Once the specified amount of rounds have been played, the game will move to intermission and the next map in the maplist. If "roundlimit" is set to 0, the game will repeat states 1 through 3.

Maps can still be changed with the (proposed) votemap command.

[Client Implementation]

Client implementation calls for clients to be able to do the following:

1) Join the queue
2) Declare their client "ready" in warm up mode.
3) Receive server information for rounds won and post them to scoreboard.
4) Be able to be forced back into spectator/wait mode upon a loss.

This design document is not entirely complete. Please offer input.

Developer's Corner / 'votemap' Design Document/Proposal

« on: October 14, 2008, 19:10:15 »
Odamex 'votemap' System
Design Document

[What is the votemap system?]

The purpose of the vote map system is to allow server administrators the option to grant clients flexibility to play outside of the normal map list order.


Multiple modern game designs, as well as the other two major multiplayer Doom source ports, were considered when attempting to find the most viable solution for an Odamex map voting system.

When trying to find the right system, there were some major concerns that most existing designs did not comply with:

1) The system should allow clients to view a list of all maps eligible to be voted on.

2) The system should not clutter the screen with large amounts of text or messages.

3) The system should not require any new binded commands. Simplicity is key.

Ultimately, I chose to base this design off of that found in the Half-Life mod, Natural Selection.

[Server Implementation]

The server design of map voting will require a new cvar and will have to read from the server's existing map list (maps in the maplist are maps eligible and transmitted to clients for voting.

A new server-side cvar, 'sv_votemap', will be used to enable or disable map voting on the server. If enabled, any maps in the maplist may be voted on by clients. If disabled, the maplist operates as usual.

When a client votes on a map, the server sends a message to clients (not a chat string) that should be formatted as follows:

"Player has voted on wad map [z] (x/y)"


Player = name of client who used 'votemap' command

wad = name of wad (example: DWANGO5.WAD)

map = name of map lump (example: MAP18)

x = number of players who have voted for same votemap # (see z)

y = number of votes required to change map (must be over 50% of clients connected rounded up to the next whole number. For instance in a server with 8 clients, 'y' would equal 5. (Perhaps the required percentage could be a server variable).

z = ID number assigned to each map in the map list. Each time a new map is added while the server is running, the next consecutive number is assigned to that map. Duplicates (same wad and map) are ignored.

[Other Server Stuff]

A few notes added in 2010:

-Voting should be disabled during intermission

-Voting should probably take place in sessions, especially since different votes for different maps can be occuring at once. Maybe clear all votes at the end of a map or every 5-10 minutes?

-Players should only be able to have one outstanding vote, so using the command twice on different maps should be allowed if one decides to change their vote.

[Client Implementation]

The client will require a new console command and should receive the map list with the map IDs after inputting it.

The 'votemap' command, when used in console, will output a list in the follow format:

"[z] WAD MAP"

The client can then use the command 'votemap "z"' to vote for a map they'd like to play.

This design document is open to input.

Developer's Corner / New Game Type Design Document/Proposal: OdaBall

« on: October 14, 2008, 18:58:17 »
Design Document

[What is OdaBall?]

Odaball is a proposed game type for Odamex that takes some inspiration from Halo 3's Oddball game mode and adapts similar ideas to Doom's fast-paced game play.

[How is OdaBall played?]

OdaBall can be played in both individual (free for all) and team based modes in existing deathmatch maps or maps specifically designed for the OdaBall mode.

[What are the rules of OdaBall?]

In this mode, one OdaBall is spawned into the map. Players compete to hold the OdaBall as long as possible.


For every second the Odaball is held, the player (or their team) receives a point. A point is also awarded for picking up the OdaBall. The game can be won in two ways:

1) Earning enough points to reach a specified 'scorelimit'
2) Having the most points at the end of a set timelimit

{Spawning the Ball}

OdaBall should be designed to not only be compatible with maps specifically designed for it but for existing DM maps as well.

A thing type should be set aside for OdaBall spawn spots. If more than one OdaBall spawn thing exists, the ball should be randomly spawned at one of those things.

OdaBall should also be built to work with existing maps. If no OdaBall spawns exist, the ball should be spawned onto a DM start.

{OdaBall Timeouts}

The question could be raised on how to deal with the ball being dropped into an inescapable area. Since OdaBall is designed to be a fast paced game, one could offer the suggestion that if the ball is dropped in a spot for 10 seconds (proposed value - subject to change following testing) without being touched, it should be respawned randomly to another spawn spot. A cvar should be considered to toggle this.

Also, if the ball is dropped into a sector with a damage special, it could be respawned. This would need to be tested to see how it affects a game.

{Finding the OdaBall}

Unlike Capture the Flag, which emphasizes players hide with the enemy flag to avoid conflict, OdaBall allows opponents to know where the OdaBall is at all times with the aid of a color translatable arrow that hovers above the ball.

What is special about the arrow is that it can be seen through all objects and walls at all times, never changing in size. This allows for a constant chase of the ball.

When the ball is at rest, the arrow flashes blue and gold (or maybe gray). If an enemy is holding the ball, the arrow will appear red. If a teammate is holding the ball, the arrow will appear green.

This is all subject to change and open to input.

Devoblog / Odamex 0.4.2 available now!

« on: October 09, 2008, 11:14:48 »
** This is a required update **

The third in the Odamex 0.4 series of releases, 0.4.2 brings some long sought after changes that will surely benefit both players and server administrators alike.

Perhaps the most noticeable change for players will be the improved mouse support for Windows operating systems. Thanks to some crafty work from our friends at the ioquake3 project, we have packaged a modified SDL with the Windows Odamex packages that should remedy the "jerkiness" that you may have experienced with mouse input. However, there's much, much more! Check out a more extensive list in the release page.

For those that use Odamex as a single player solution on various platforms, the saving and loading functions from zdoom 1.22 have been restored to the engine (thanks to Randy Heit) after being stripped from the code in csdoom. The code went through some minor adjustments to fit in Odamex's more optimized code base. Please report any issues you may experience with this restored feature if problems arise.

The biggest change in this release will be for server administrators as the Odamex team has taken measures to make it less complicated to run certain types of game types. For instance, to run a CTF server before server administrators would need to check that three separate cvars, "deathmatch", "teamplay", and "usectf" were all set correctly. Now, through the use of the new "gametype" cvar administrators will be able to set these modes while only managing one cvar (for CTF, "gametype 3"). Please refer to the Gametype article for more information on this.

Other neat features introduced for server administrators in this release include the new "shufflemaplist" cvar which enables a random shuffle of the maplist similar to how a music application shuffles a playlist. All maps will be played in a random order until the entire list has been played which can help add new excitement to a known maplist order.

The new "sv_teamspawns" cvar also allows maps only designed for teamplay to be played in standard deathmatch gametype as well as random spawns in TDM/CTF gametypes. Manual flag return CTF has also been fixed for the 0.4.2 release.

The Odamex team would like to remind our users that the Odamex project thrives off of user input, particularly when it comes to resolving bugs in the engine. If you would like to be involved in helping Odamex's development move forward, please take a moment to sign up for the Odamex Bug Tracker. The team consistently refers to the bug tracker to determine how development should move forward. If you come across an anomaly not listed in the tracker, please submit it! Odamex can only truly succeed with the help of dedicated users!

If you are interested in tracking official Odamex releases more easily, you can subscribe to updates in one of two ways:

1) You can subscribe to the Odamex releases rss feed.

2) You can receive email alerts (requires a sourceforge account or an openid).

POST-RELEASE NOTE: The issue with the launcher displaying 0.4.2 Team Deathmatch servers as coop has been noted. Expect a patch shortly.

General Discussion / SDL Mouse Fixed for Windows Users?

« on: August 31, 2008, 19:27:25 »
Windows users! Our friends over at the ioquake3 project seem to have solved the problem with SDL's "jerky" mouse movement.

Anybody who has had issues with the mouse in Odamex, please replace the Odamex packaged SDL with the following modified version and post your outcome. Those who have already tested have confirmed that the mouse is much, much better.

General Discussion / Simplifying the Mouse Options

« on: August 26, 2008, 10:50:16 »
It has come to my attention recently that, after introducing a variety of new players to Odamex, people tend to all change their settings to similar things. Here I'm going to suggest some changes that will simplify the overly complicated mouse menu and excess mouse options in the engine.

If you disagree with any of these speaking up is crucial.

1) Remove acceleration and make it always set to 0 (off). Players tend to always set their acceleration to off from what I can tell.

2) As a byproduct of 1, removal of threshold.

3) Removal of Dynamic Resolution.

4) Removal of ZDoom mouse type? The values all translate differently than the ZDoom mouse as it is so it's not even as if you can just transfer your settings over from the other ZDoom engines.

5) Changing the sensitivity scale to decimals so 10 becomes 1.0, 20 becomes 2.0, 25 becomes 2.5, etc. Lower numbers are easier to remember for users.

Developer's Corner / New Hi-Res Scoreboard Design Document/Proposal

« on: August 18, 2008, 03:04:21 »
The following is a design document I've worked on that details (and displays through some mock up pictures) proposed changes to the hi-res scoreboards for use in 640x400 and above.

In some cases, this design document will step outside of the scope of changes to the scoreboards and to other areas of the engine that may be addressed to enhance the user's experience.

Odamex Hi-Res Scoreboard Proposal

Standard Scoreboard

The standard scoreboard would apply to all non-team based gamemodes and would supply users with important server information that the current scoreboard does not.

The scoreboard is separated by a divider to allow quick information on three categories: Server information, player information, and non-player information.

Let's touch on all parts of the standard scoreboard, what each part of it does, and what would need to be flexible for usage in the future beyond the current gamemodes.

Server Information:

Game Type: Centered on the second of three lines above the scoreboard. This displays the current gametype. At the current version of Odamex, the only two game types that would be displayed here are Deathmatch and Cooperative.

Clients: Displays the number of total clients currently connected over the number of "maxclients" allowed.

Players: Displays the number of players currently IN-GAME. Spectators and downloading users are not counted here.

Fraglimit: Displays the "fraglimit" set by the server. This must be able to change on the fly if the server changes its "fraglimit" mid-game. If no fraglimit is set, display N/A.

Time Left: Displays the time left before the server ends the game. Once it counts down to 00:00 the game ends. Is dependant on the "timelimit". This must be able to change on the fly if the server changes its "timelimit" mid-game. If no "timelimit" is set, display N/A.

Scorelimit: Displays the "scorelimit" set by the server. This currently is not in use by deathmatch or cooperative modes in Odamex, but may be used in the future. This must be able to change on the fly if the server changes its "scorelimit" mid-game. If no scorelimit is set, display N/A.

Player Information:

The player information portion of the scoreboard gives seven pieces of information to users. All seven of these are currently in Odamex but will be covered regardless.

Color: The color of the player is displayed to the left of their name.

Name: The name of the player.

Frags: Current frag count of the player.

Deaths: Current death count of the player.

Frag/Death ratio: Current frag count / current death count. 0 deaths is counted as 1 as to not divide by zero. (NOTE: In the future, if non-team based gamemodes are introduced that rely on "scorelimit" this field should become 'Score'.)

Ping: Current ping of client to the server.

Time: Current time client has spent connected to the server.

Other Client Information:

Any clients connected that aren't in game are sorted into this area. They should display all of the information that the active players do with exception to the color field.

Spectators: Unlike active players, spectators should not display any color at all.

Downloading Players: Though players who are downloading will not show a color, a downloading player should be represented by an icon. In the mockup photo, I created an arrow (using the Odamex blue/gold) to denote this.

Team-Based Scoreboard

The team-based scoreboard is what it sounds like and needs to be suited and adaptable for a variety of game modes that exist now or potentially will in the future.

Unlike the standard scoreboard, the team-based scoreboard is separated into four areas (six if you count both teams separately). Of these four areas however, only the non-player information area remains the same as the standard scoreboard. Due to this, that section will be omitted as it has already been covered.

Game Type: Centered on the second of three lines above the scoreboard. This displays the current gametype. At the current version of Odamex, the only two game types that would be displayed here are Team Deathmatch and Capture the Flag.

Clients: Displays the number of total clients currently connected over the number of "maxclients" allowed.

Blue: Displays the number of current players IN-GAME on the blue team.

Red: Displays the number of current players IN-GAME on the red team.

Fraglimit: Displays the "fraglimit" set by the server. This must be able to change on the fly if the server changes its "fraglimit" mid-game. If no fraglimit is set, display N/A.

Time Left: Displays the time left before the server ends the game. Once it counts down to 00:00 the game ends. Is dependant on the "timelimit". This must be able to change on the fly if the server changes its "timelimit" mid-game. If no "timelimit" is set, display N/A.

Scorelimit: Displays the "scorelimit" set by the server. This currently is only used by Capture The Flag. This must be able to change on the fly if the server changes its "scorelimit" mid-game. If no scorelimit is set, display N/A.

Team Information:

This area of the scoreboard houses information for both teams.

Score: In modes where scoring is used, this will display the current score of each team above their colored bars.

In Team Deathmatch, this will display the current frag count of the team. It will consider any frag subtractions such as suicides or team kills.

In Capture the Flag, this will display the current total of flag captures by the team.

The numbering here uses Odamex's FONTB## lumps. The lumps in odamex.wad are named FONTB16-25.

Total Frags: Displays the team's total frag count. This does not count or subtract suicides or team kills. The number is displayed in the respective team's color.

Average Ping: Displays the average ping time of the entire team.

Total Points: Displays the sum of all team members' points. I currently cannot think of an application of this field in Team Deathmatch. Please offer your opinions.

Player Information:

The player information portion of the team-based scoreboard gives five pieces of information to users but covers both teams. The player information section is separated by a divider colored to the team's color.

Color: The color of the player is displayed to the left of their name. This will be the color of the team they are on.

Name: The name of the player. Unlike the standard scoreboard which supports displaying the 15 character limit on names, this has to be limited to displaying only the first 12 of a player's name due to space constraints. (NOTE: Only display the top eight players on each team in cases of 9+ player teams.)

Point: Current point count of the player.

Frag: Current frag count of the player.

Ping: Current ping of client to the server.

Team-Based Player Joining

After going over the team-based scoreboards and how it sits over the spectator area, I am of the opinion that Odamex should approach team-based games differently when it comes to joining in as an active player.

Unlike the current scoreboard which does not have an area reserved for spectators, I propose the following for when a player joins the server with this new scoreboard system:

1) When the player joins a team-based server, they are automatically assigned to the spectator board and assigned to no team.

2) When the player presses use to join, they are given one of three menu options to select from on-screen. Red, Blue, or Auto-Assign.

3) The auto-assign selection should assign a player to a team based on a few conditions.
3a) If no player is joined in the game yet, assign to a random team.
3b) If team player counts are uneven, assign player to team with less players.
3c) If team player counts are even, assign player to team with lower score.

4) Make a new bind key that allows player to switch team in-game with the press of a button like newer games.
4b) Assign a enforced delay to prevent a player from being able to rapidly switch teams while in game.

Devoblog / Odamex 0.4.1 is now available!

« on: August 03, 2008, 11:33:38 »
** This is a required update **

Without further adieu, the Odamex team proudly presents to you, the first official minor point release. Don't let the word minor fool you though as there are plenty of fixes and some new additions to the engine in this release.

Before we go through some of the new changes of 0.4.1, Odamex still needs a dedicated package maintainer for Mac OSX PPC/X86. If you feel that you can assist us please do not hesitate to contact us via forums or IRC as soon as possible.

Some notable fixes in 0.4.1 include the improvement of weapon desyncs, freelook issues being resolved, smoother moving platforms, wad downloading fixed, and a variety of mouse code improvements.

Odamex 0.4.1 comes with some fresh flavor as well with the addition of passworded server support, audio notifications of connecting and disconnecting players, and chat flood protection for server administrators. Don't take our word for it though, check out some of the changes for yourself!

So what are you waiting for? Go ahead and grab Odamex 0.4.1 now!

Devoblog / Odalauncher Quick Fix

« on: July 10, 2008, 18:21:26 »
Those that use our packaged launcher may recently have noticed that there currently exists an issue with our primary master server that is preventing many of the servers reporting from being displayed on your list. Ultimately, you may have only been seeing a handful of servers over the past week or so.

Though this is a temporary fix for Windows users only, extracting and replacing your old odalaunch binary with this quick fix should allow you to see all of the servers currently running that are reporting to the secondary master (

Unfortunately, only a win32 fix exists at the moment. For those that compile the launcher themselves, you can easily fix this problem by changing the master address to

Expect a full update soon as the 0.4.1 release grows imminent.

Download the replacement launcher by clicking here.

Developer's Corner / Internationalization

« on: June 02, 2008, 01:07:37 »
Over two years ago, before the first public release of Odamex even saw the light of day, an enhancement for internationalization was posted in the bug tracker.

Odamex currently has an ever growing user base with many of its users coming from the Czech Republic, Russia, Germany, and a wide variety of Spanish speaking nations (among many others). There may not be a better time than now than to attempt to make this proposal a reality.

I recently began the creation of console fonts for a variety of different languages and will continue if there is interest in this project throughout the community. However, this truly has to be a community effort as many things will need to be translated by a fluent speaker of each respective language. Then, if possible, they will be looked over by a second fluent speaker to ensure clarity.

We're going to start off small working on translating the Odamex menu system and then we'll try and move on from there. This is somewhat of a long term project but the more that we can accomplish before even touching the engine, the sooner Odamex can likely support other languages.

So, if you're interested in translating the menu system please let me know what language you're planning on translating and keep me up to date. Make sure you include each line's English counterpart so that it is easy to place everything where it needs to be.

The following status covers the translation of Odamex's menu system to each respective language:

Language:Volunteers as of 06/02/08

Czech: [Status: Vacant]

German: [Status: Vacant]

Russian:Nautilus [Status: In Progress]

Spanish: [Status: Vacant]
After taking some time to look through the bug tracker it is apparent that there may be bugs which are resolved but unmarked to reflect this in the tracker. This is not conducive to the development of Odamex.

In light of this, I am beginning a new Bug Tracker Cleanup Initiative which promotes community and personal involvement and investment in Odamex. This will hopefully lead to a healthier, more manageable project for our programmers and encourage faster project growth.

The way to get involved is easy! All you have to do is let me know by means of this thread, IRC, or other method of contact that you would like to participate in the program and then, after your credentials are evaluated, you will be assigned the numbers of open bugs in our tracker.

After taking some time to look through the bug tracker it is apparent that there may be bugs which are resolved but unmarked so in the tracker. This is not conducive to the development of Odamex.

In light of this, I am beginning a new Bug Tracker Cleanup Initiative which promotes community and personal involvement and investment in Odamex. This will hopefully lead to a healthier, more manageable project for our programmers and encourage project growth.

The way to get involved is easy! All you have to do is let me know by means of this thread, IRC, or other method of contact that you would like to participate in the program and then, after your credentials are evaluated, you will be assigned the numbers of open bugs in our tracker.


Revision 565 or greater is REQUIRED for this. For Windows users, you can get revision 565 here. Users of other platforms will have to build their own copy of revision 565.

Your job is to identify or try to reproduce the bug in your current client. PLEASE SPECIFY THE PLATFORM YOU ARE RUNNING ON.

If you cannot reproduce the bug but you are 100% sure that the bug does not exist anymore you will mark the bug SOLVED (in this thread, not the tracker). DO NOT MARK A BUG SOLVED IF YOU ARE NOT 100% SURE IT IS SOLVED. READ DOWN FOR FURTHER INSTRUCTIONS.

If you can identify the bug you will mark the bug OPEN. Additionally, if you have any new information as to how the bug is reproducible or anything else useful, you should report any new findings to the bug tracker immediately.

If you cannot reproduce the bug but are not sure that it is corrected you will mark the bug UNSURE. This may or may not be the most common response we'll receive. We'll have to see how this goes.

While it is important to find any new information on a bug, it is not the main goal of this program. The main goal is simply put to determine the legitimacy of any bugs still in the Tracker (some of which have been open for over 2 years!). However if you do find new information pertaining to a bug you are responsible for, PLEASE REPORT IT!

Any bug in which you have not attended to please mark PENDING.

Upon signing up you will be assigned anywhere from between 5 to 10 bugs. A list of those who are signed up, the bugs they are responsible for, and the reported status of those bugs will be located directly under this information.

Although a list of all open bugs will be located in this post as well, please only focus on solving the bugs you have been assigned. After you have solved the status of some of your assigned bugs, you will be assigned more. If you prove reliable, the specific field in which your bugs are assigned may be negotiable where applicable (i.e. Sound, CTF, etc).

Only game play specific bugs will be included in this particular initiative. Enhancement bugs will not be included in this particular initiative.

The projected goal is to report and complete the status of all current open bugs by April 25th. Let's see if we can pull together and get the ball rolling towards the summer season (or winter for those of you in the southern hemisphere).

Ant P:
103 - Reimplement intermission screen (check through bug comments for more information) PENDING
109 - Partial death animation PENDING
143 - Ceiling/floor edge render problem OPEN
287 - Incorrect E1M4 door+lift behavior (somebody please test in chocodoom as well to confirm this bug) PENDING
400 - 'Allow Freelook' switch broken PENDING

92 - CTF: 3-team ctf scoreboard PENDING
120 - Mouse strafe reverse. PENDING
134 - Animated sprites with transparency are distorted on certain resolutions PENDING
211 - Renderer problem: Slows down when you look at a wall. PENDING
265 - Sound handling on ExM8/MAP08 (will assign this to a UD member if they sign up as I believe this bug occurred on RottKing's castle UDMX map. Please get back to me) PENDING

135 - Various sounds are played multiple times at once PENDING
216 - hr2final.wad menu does not render properly PENDING
289 - Multiple "oof" sounds when hitting a floor (Duplicate of Bug 135? Please confirm) PENDING
333 - Silent bfg does not work for opponents PENDING
380 - Team Damage Issue PENDING


18 - Incorrect sector data on connect
32 - make coop work
42 - sprite-level zfighting
86 - CTF: sv_soundteam problems
167 - Consistency of weapon firing feedback (visible / audible)
181 - Missing sounds (Scroll down to my comment and test everything unrelated to the wallhack issue)
188 - Rendering error when eye is level with the floor
206 - Boom-enhanced errors
215 - Weapon pickup at spawn
224 - Remote Door Server/Client Disagreement
228 - could not respawn with r1714 (try your best to reproduce. I believe this might be a poorly reported bug)
260 - Respawn facing direction you died
269 - Weapons shoot wrong ammo upon autoswitching
274 - buffer overflow with player-player visual check (comment 2)
283 - Teamplay issues (comment 1 bullets 1, 3, and 4)
288 - Too fast sprite frameswitching
293 - Ghost Monsters in Coop (needs extensive testing)
304 - Weapon Pickup Doesnt Switch
384 - Teamsay/messagemode2 broken

General Discussion / MAGFest Checklist

« on: December 13, 2007, 04:09:19 »
This is our MAGFEST Checklist. It is subject to change at all times until MAGFest. It would be great if we could lock down most of these details.

Travel Attendees

Confirmed attendees thus far:

Red denotes traveling from Philadelphia with Ralphis
Blue denotes flying into Washington for pickup

Matt Cibulas (RottKing)
Michael Lightner (Manc) CONFIRMED BABY
Tim McGrouty
Ralph Vickers (Ralphis)

Travel Itinerary

Ralph's group travel plans

Wednesday, January 2th

-Ralph & Tim load most equipment on Wed. Jan 2

Thursday, January 3rd

-Ralph takes R2 from Norwood to 30th St. station @ 10:12am
-Ralph picks up Matt at 30th st. station @ 11am
-Ralph & Matt take 11:39am R2 to Norwood, arrive at noon
-Ralph's party leaves around 12:30 pm for Alexandria
     -Estimated distance: 135.49 miles
     -Estimated travel time: 2.5 hours
-Arrive at Hotel around 3:30 pm, check into rooms

Friday, January 4th

Saturday, January 5th

Sunday, January 6th

-Hotel check out is at Noon.
-Playing this by ear atm.

Monday, January 7th

-Ralph & Matt take R2 from Norwood to 30th St. station @ 12:18 pm, arrive at 12:39 pm. Kiss each other goodbye.
-Matt boards Amtrak to Bridgeport at 1:58 pm from 30th St.
-Ralph takes 2:31 pm R2 to Norwood, arrives home at 2:48 pm

Mike's travel plans

Thursday, January 3rd

-Arrives at Airport at 9:43a

Friday, January 4th

Saturday, January 5th

Sunday, January 6th

-Leaves airport at 7:45p

Table Schedule

I haven't put anything in here yet because I'm still waiting for a schedule from MAGFest on their events. We probably wanted to schedule everything around their big events and not run tournaments when they'll be having high volume tournaments, etc.

Thursday, January 3rd

10:00p-Midnight: 1on1 Tournament

Friday, January 4th

3:00p-5:00p : 1on1 Tournament
Note: Followed by concert

Saturday, January 5th

1:00p-4:00p : 3on3 CTF Tournament
Midnight-1p : 1on1 Tournament (Maybe)

Sunday, January 6th

11:00a-Noon : 1on1 Tournament


Red is being brought by Ralph's group
Blue is being brought by Mike
Yellow still needs confirmation

Windows XP loaded Computers (7)
Flat Panel monitors (5) Note: Could use one more!
Flat Panel monitors (1) Note: From Manc
Keyboards (7)
Mice (7) Note: More optical mice would be great.
Headphones (6)
8-Port Hub
Network cables (7)
Power strips (?) Note: Not sure how many of these we would need for 7 computers, monitors, a hub, and other equipment. At least 15 sockets.

Odamex Shirts (14) Note: Need 15, one goes to Hobomaster22. Some goto staffers. Rest can go as prizes.
Odamex Banner

UD Radio broadcasting equipment
USB wireless connection dongle
Amplifier for Wireless Mic

Please let me know if you think I've forgotten anything.

Anything that is in yellow is not 100% confirmed to be on its way, either because we don't have it or because the people that would have it are not locked in yet. If you can donate to us anything on this list, please contact me AS SOON AS POSSIBLE.

Also, for the people who are attending, remember that if you want to swim or anything in the hotel pool, you should bring a bathing suit or what not. Though we're here on "business", each of us will have downtime to hang out and should enjoy as much as the rest of the festival has to offer.

Money Not Yet Spent

Potentially $10/day for Wireless = Approx. $30
$9/day for Parking (2 vehicles) = $54

Total = $84 extra expenses
Pages: 1 2 [3] 4