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 - Ralphis

Pages: 1 ... 4 5 [6] 7 8 9
76

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.
77
No, the Odaball spawn would have its own special thing type
78

Maps, Wads and Mods / Re: E1remake

« on: December 12, 2008, 01:13:36 »
I believe that's a doombuilder 3d mode start.

Anyway, map01 was really great and I really enjoyed playing through it. Playing through on skill 4, I thought it was well paced - having played through at least half of the map until I got anything other than the pistol.

Keep up the great work, this was really fun.
79

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

« on: October 14, 2008, 19:24:16 »
ODAMEX
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.

[Research]

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

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.

[Research]

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

{Legend:}

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

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

« on: October 14, 2008, 18:58:17 »
ODABALL
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.

{Scoring}

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

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.
83
Though there have been some short lived experiments with having other source ports connect to Odamex servers, nothing concrete or important came out of them.

The core Odamex development team currently has no plans of supporting any other Doom engines in cross-compatible play.
84

General Discussion / Re: REQ: feature requests list?

« on: September 29, 2008, 10:27:57 »
Hi Andrew.

Features and bug reports are all submitted to our bug tracker. Before requesting any features, please search to make sure that your feature has not already been requested. When submitting anything to the bug tracker, please try and be as descriptive as possible.

List sorted with Enhancements found at bottom

As far as Heretic/Hexen support goes, it is unlikely that there will be support for it anytime soon within Odamex due to, at the very least, two reasons:

1) Heretic and Hexen code was painfully removed for months in order to GPL Odamex's code. It will take a long time to integrate it all back in AND make sure it works.

2) There are still problems that exist within playing a game of Doom over Odamex's netplay which include some latency issues, most notably in cooperative play. These issues should be fixed first as to further complicate the stability of an online game by having to compensate for Heretic and Hexen.

Never say never, but in the short term it is highly unlikely at the moment.
85

General Discussion / Re: SDL Mouse Fixed for Windows Users?

« on: September 10, 2008, 14:48:32 »
Completely unrelated question: Does zdoom use the same input code? Might explain why it's unplayable for me under wine...

The problem in Odamex was caused by SDL, which Zdoom does not use.
86

General Discussion / Re: SDL Mouse Fixed for Windows Users?

« on: September 01, 2008, 04:08:15 »
Nope, still sluggish. This sure works for OpenArena but not for Odamex

Of the 15 or so people to respond thus far you're the only negative reaction. What are your mouse settings and what OS are you running?
87

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.

http://icculus.org/~tma/SDL.dll
88

General Discussion / Re: Simplifying the Mouse Options

« on: August 26, 2008, 10:53:08 »
I don't think any of us have any idea what dynamic resolution is.

Exactly why we either need to remove it or someone needs to explain what the heck it is. What's the point in having options that even the developers don't have any clue what their intended purpose is?
89

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

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.
Pages: 1 ... 4 5 [6] 7 8 9