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

Pages: [1] 2 3

Technical Support / Re: New protocol design ideas

« on: December 04, 2008, 18:48:54 »
Not bad so far.

I think "Teams Enabled" is kind of irrelevant, since you can already use "gametype == teamdm" to determine if its enabled.

Also, "Team Name" is kind of the same, we can determine the name launcher-side by comparing "Team Colour" to a list of predefined values and set it.

Fragcount needs to be signed, this value can go into the negative if players keep dieing all the time.

Killcount should stay really, because we already have Deathcount anyway.

Oh and you forgot the player name field too. :P

But what if the team's color does not match the list of predefined values? TEAM3? TEAM4? And what if one server wanted to display one team both in-game and in the launcher as the EAGLES?

As for fragcount and killcount, the message I posted under the layout should explain everything.

Technical Support / Re: New protocol design ideas

« on: November 08, 2008, 16:21:57 »
I think the layout of our server response packet structure could use a bit of organization for 0.5.

Code: [Select]
//--- Main Response
Tag - Unsigned 32bit Integer
Version - Unsigned 32bit Integer
Protocol version - Unsigned 32bit Integer

//--- Server information Related
Password MD5 hash - ASCIIZ String
Current map - ASCIIZ String
Time Left - Unsigned 16bit Integer

//--- CVAR Related
Cvar Count - Unsigned 8bit Integer
+Cvar name (Cvar Count) - ASCIIZ String
+Cvar value - ASCIIZ String

//--- WAD Related
WAD Count - Unsigned 8bit Integer
+WAD filename (WAD Count) - ASCIIZ String
+WAD MD5 Hash - ASCIIZ String

//--- Team Related
Teams Enabled - Boolean
Team Count - Unsigned 8bit Integer
+Team Name - ASCIIZ String
+Team Color - Unsigned 32bit Integer
+Team Score - Signed 16bit Integer

//--- Player Related
Player Count - Unsigned 8bit Integer
+Player Ping - Unsigned 16bit Integer
+Player Time - Unsigned 32bit Integer
+Spectator - Boolean
+Player Team - Unsigned 8bit Integer
+Player Color - Unsigned 32bit Integer
+Player Score - Signed 32bit Integer
+Player Fragcount - Unsigned 16bit Integer
+Player Deathcount - Unsigned 16bit Integer

You might notice some odd changes in here. They're optional, but here's why I did them:

* Now that we've made the team structure a little less hardcoded (with our teamsinplay cvar), we can treat the number of teams like we would number of cvars/wads/players. We should also be prepared if we want to make teams customizable to the server. (Custom names and colors... but CTF will still remain RED/BLUE)
* If it won't increase the size of the packets too much, I was thinking that the server could submit the color of each team and player to the launcher. I'm not sure if wx's Color (or Colour, it's very picky sometimes) supports RGB values, but it would be nice to support it. (Maybe add a color square next to the name a la the odascoreboard)
* Replaced player killcount with player score so we can use it for other game modes. Making it 32bit is overkill, I know, I'm just putting it in there in case we decide to further implement my "replace monster kills with damage inflicted" patch.
* I was thinking maybe we have player fragcount an unsigned value that doesn't decrease due to suicides and use player score for DM matches. (where it's the fragcount - suicides) Ralphis kinda doesn't like the idea of the scoreboard showing Score / Frags / Deaths instead of Frags / Deaths, so we could either disguise the scoreboard Frags as Score or make it optional to display Score / Deaths.
I think for the team-based scoreboard, the spectator/downloadplayer part should have two columns (no different sorting unless we plan to have the priv-ctf style "waiting spectator and true spectator" styles.)

General Discussion / Re: Simplifying the Mouse Options

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

General Discussion / Re: Bullet puffs bug

« on: August 19, 2008, 15:47:35 »
I don't see how it affects demo compatability. All it affects is the display of a bullet puff.
I agree with this.

General Discussion / Bullet puffs bug

« on: August 15, 2008, 20:32:48 »

I'd fix it, but apparently it's a "doom2.exe tactic" by some people or something. Any particular reason why this shouldn't be fixed in Odamex?

Developer's Corner / Re: /me messages in Odamex

« on: August 13, 2008, 23:01:35 »
Hey man, that's pretty cool.

Developer's Corner / Re: The big cvar standardization initiative

« on: August 13, 2008, 22:46:51 »
Here's the latest for the gamemode patch. It's not heavily tested, so there might be a few bugs with it. But overall it's pretty smooth.

Developer's Corner / Re: The big cvar standardization initiative

« on: August 08, 2008, 09:00:19 »
We should also establish and document which of the server cvars can be read by the client, even if these cvars do nothing to the client.

Developer's Corner / Re: Quit Messages In Odamex

« on: August 08, 2008, 08:56:29 »
It's a really solid patch. (except for the whitespace, which I don't really mind fixing) We're going to hold off on implementing it because it breaks protocol compatability. When we update the protocol, this is definitely going in.

Ralph and I also decided to update the maximum character limit to 35, unless you have any objections to it.

Developer's Corner / Re: The big cvar standardization initiative

« on: August 05, 2008, 12:17:00 »
Okay, so Ralphis wants a step-by-step guide on how we're going to implement this. This is the best way to go about this:

1) Create a branch called 'gamemode', exactly like trunk.

2) Remove gamemode cmd from client.

3) Rename all instances of the gamemode var with 'doommode'. And to keep with consistency, rename 'gamemission' to 'doommission', the GameMode_t enum to 'DoomMode_t', and the GameMission_t enum to 'DoomMission_t'. Not much more than simple find and replace.

4) Create a new CVAR_FUNC_IMPL in the common cvarlist: gamemode. Default value is "0", CVAR_SERVERINFO, CVAR_LATCHED, CVAR_NOENABLEDISABLE. The reason it's not standard CVAR is because we should do the following:

* Make it so when the client or server simply types in "gamemode", the console will read all supported values.

* We should add in value translation so that inputting "gamemode ctf" should do "gamemode 3".

5) Create #defines (or whatever is best) for

1 - GM_DM
2 - GM_TDM
3 - GM_CTF

It would be much better in the long run for us coders. (example: if (gamemode == GM_COOP))

6) Remove the 'deathmatch', 'teamplay', 'ctf', and 'usectf' cvars and, at the same time, replace all instances with the appropriate gamemode cvars.

7) Change launcher protocol to reflect the new cvar.

8) Run it by denis, fix bugs, merge to trunk when ready.

EDIT: We should also create two flags, CVAR_SERVERARCHIVE and CVAR_CLIENTARCHIVE for the common cvars. Same as CVAR_ARCHIVE but just for either server or client.

Developer's Corner / Re: The big cvar standardization initiative

« on: July 21, 2008, 01:58:23 »
Ralphis and I think it's a good idea to merge the deathmatch, teamplay, and usectf/ctf cvars into one cvar: gamemode.

gamemode (int) - Common cvar. (Read-only for client) Distributed to launchers as an integer. (Will require protocol bump)

gamemode 0 - Coop
gamemode 1 - DM
gamemode 2 - TDM
gamemode 3 - CTF
gamemode 4+ - New gametypes. (Would show up as "unknown" for outdated clients/launchers)

This would eliminate the hassle of juggling multiple cvars (deathmatch and teamplay do what for usectf?) while paving a smooth way for potential new gametypes.

Developer's Corner / Re: The big cvar standardization initiative

« on: July 07, 2008, 03:50:11 »
The client cvarlist should be split up into two lists:

- A list of actual client cvars.
- A list of read-only server info cvars.

I'll look into the cvars later.

Devoblog / Re: Bans and Exceptions

« on: May 01, 2008, 22:51:42 »
So if I read all of that right, I can do "addban *" to have a whitelist?

To have a whitelist-only server, yes. People can only get in by requesting an exception. This is great for having both a "private" and unpassworded server that you want to remain visible in the launchers.
Pages: [1] 2 3