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

Pages: [1] 2 3 ... 5
1

General Discussion / Re: Community Questionnaire

« on: August 20, 2014, 21:53:15 »
What is your username and what does it mean?
My real name...

My other username, RTC_Marine reflected a time when I was with the TRTCC crew, Maonth suggested this nickname and I accepted it

What was the first doom you ever played? (Doom, Doom 2, Final Doom, Doom64, Doom3)
Doom shareware 0.99 iirc, the neighbor in the house next to us had a computer and we were around the same age, he introduced me to Doom, was good times :)

What was the first (unofficial) source port you ever played and when?
The first port I would have played was Doom 95, the first unofficial one was zdoom 1.22, I remember going crazy over the look up/down and jumping features

What was the first (unofficial) pwad you ever played and when?
Galaxia.wad was one of them, Crossing Acheron rings a bell too.

What is your favorite game mode?
Nightmare cooperative deathmatch, yes you heard that right :P nightmare respawning fast enemies + dming players. Just for the shear insanity of it

If you are in a clan, what clan and why are you in it?
I used to be in clan Unidoom, but the "used to" phrase is probably irrelevant in Ralphis eyes, since I bet according to him "There is no such thing as leaving UD"

What is your fondest memory of multiplayer Doom?
Wasting Blizzardson with rockets on Ralphis Magical Ice Forts and some UD clan matches
2

Technical Support / Re: UPnP External IP is empty

« on: May 29, 2013, 05:44:31 »
My guess is that you'll have to use port forwarding on your router, not easy on cisco ios (unless your router has a web interface) so you may need to investigate this on a google search

1) Set up odasrv to listen on a specific port (preferably one greater than 1024) using the -port command line parameter
2) Configure your router to port forward to the machines ip address running odasrv, use the same port as what you did in step 1, the protocol is UDP

Hope this is a little helpful
3

Technical Support / Re: UPnP External IP is empty

« on: May 27, 2013, 03:18:10 »
According to this page of your router http://bc.whirlpool.net.au/bc/hardware/?action=h_view&model_id=232 :

Code: [Select]
...Cisco does not support UPnP on any of their routers..
4

Technical Support / Re: UPnP External IP is empty

« on: May 20, 2013, 16:20:26 »
UPnP is not supported by all routers, some only have partial support.

What is the brand and model of your router?
5

Technical Support / Re: Launcher list refresh problem

« on: October 28, 2010, 17:02:41 »
Spam? look at its signature
6

Devoblog / Odamex 0.4.4 on the horizon..

« on: November 02, 2009, 07:01:35 »
It has been too long (and we apologize for that!)

Since 0.4.3, Odamex has been vastly improved in the areas of stability and reliability, some changes including better Mac support, closer vanilla doom emulation, some gameplay changes/improvements, ALOT of crash/resource leak/buffer overrun and bug fixes, plus many more.

We hope to get this out ASAHP so stay tuned!
7

Maps, Wads and Mods / Re: E1remake

« on: December 12, 2008, 00:52:41 »
wow this is a really good job, nice work.

I found a couple of problems though, when you start the second map and go to the part to flip the switch (where you encounter the nazi) you can walk out the window and get stuck.

The other weird thing is unknown thing marker on the second map, you can see it in odamex, its through the other door at the start.
8

Technical Support / Re: New protocol design ideas

« on: December 05, 2008, 17:33:00 »
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.

Oh okay, here is an idea: we can have a team name field, but if the field is blank and since we have a limited number of colours to choose from (doom has a palette of only so many colours), we could assign a name to each of them (or have a range for the team colour, so the colours can vary slightly?)

I still don't get it, frags usually dips into the negative and most people who play doom know that, should we really change the semantics/terminology of it?
9

Technical Support / Re: New protocol design ideas

« on: December 02, 2008, 22:04:27 »
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.

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
10

General Discussion / Re: Simplifying the Mouse Options

« on: September 06, 2008, 00:18:22 »
I can suggest a few things:

1) Instead of just having a sensitivity bar, we split it and make it horizontal and vertical sensitivity.
2) Change "Zdoom Mouse" to "Odamex Mouse"
3) Move Lookstrafe from parent menu into the mouse one, it seems that the slider only affects the mouse

Our acceleration code is the same from chocolates and uses the same values by default, do we need to remove it?

Dynamic resolution seems to be related to high resolution mice, which is counted in DPI rather than CPI (most standard mice have a DPI of around 400, high res mice can go from 400 - 1200+), I don't know if this is correct since there isn't much information available. If it doesn't work we either fix it or throw it out.
11

General Discussion / Re: Bullet puffs bug

« on: August 18, 2008, 22:48:19 »
It's a little more than just a "cosmetic issue".  Things that people may be used to seeing or not used to seeing when in certain maps IS a "gameplay" issue.  I'm not an expert on the subject but the argument could certainly be made.

For now I vote no on this until more research can be done.

I agree, stuff like this shouldn't be messed with, as it also may affect demo compatibility.

Its also bit non-sensical because someone may create a bug report to add it back later on.

Sorry but I have to vote no.
12

Technical Support / Re: New protocol design ideas

« on: August 10, 2008, 22:38:26 »
denis is going to dump the current master list setup it at some point anyway, he mentioned using http so we might aswell not waste time on that.

13

Technical Support / Re: New protocol design ideas

« on: August 10, 2008, 09:19:40 »
Yeah, one of the other ports ran into a fragmentation problem with packets stepping over the boundary if I remember correctly.

This sounds like a good idea and I have uploaded a (very) rough idea of an implementation:

Code: [Select]
Current list Format:
--------------------

4 bytes = Tag

2 bytes = Server count

Data block: 4 bytes (ip) + 2 (port) = 6 bytes

1) 10.0.0.2:10666
2) 10.0.0.2:10667
3) 10.0.0.2:10668
4) 10.0.0.2:10669
5) 127.0.0.1:10666
6) 127.0.0.1:10667
7) 192.168.0.1:10666
8) 192.168.0.1:10667
9) 192.168.0.1:10668
====================
8 ip/ports * 6 bytes = 60 bytes total


Proposed New List Format
------------------------

4 = Tag

Data block: 4 bytes (ip) + 1 byte (port count) + 2 (ports) = 7 bytes

10.0.0.2410666106671066810669127.0.0.121066610667192.168.0.13106661066710668
    4   1  2    2    2    2      4    1   2    2     4      1  2    2    2
====================
37 bytes total


What we do now:
1) We omit duplicate ips
2) We omit the server count field
3) We include a byte field after the ip, indicating how many subsequent ports exist

Pro's:
1) Saves data (example above proves a 23 byte saving)


Con's:
1) More complicated parsing required (but not much more)
2) We may or may not save space, especially if every ip address had only 1 port number

Hopefully my calculations aren't wrong, it is 2:30am.. :S
14

Technical Support / Re: New protocol design ideas

« on: August 09, 2008, 08:23:53 »
New draft up

Comments and critique welcome.
15

Devoblog / Re: Odamex 0.4.1 is now available!

« on: August 04, 2008, 18:38:45 »
strange way to setup password in client, really..
and about versions server sends to launcher: what do all these numbers mean, for ordinary user? isnt it easier to setup normally readable version string and send it to launcher instead? that is "0.4.1 alpha" instead of 41 and 65 (never understood what is 65..)?

I can't ever remember why the protocol version was sent, it only deals with the client/server communication..

I just noticed that one of our resident devs decided to add an extra field into the launcher protocol without updating the documentation or telling anybody :/ the launcher protocol on the wiki has been updated, I'm sorry about this.

Deciphering the value is done by some macros in the source, I'll get to adding that later
Pages: [1] 2 3 ... 5