r1ch.net forums
* Home Help Search Login Register
r1ch.net  |  Recent Posts
Pages: 1 ... 8 9 [10]
 on: October 12, 2011, 04:33:54 pm 
Started by R1CH - Last post by hehheh
Thanks for the info! And is it 100% all-or-nothing at the directory level as well as at the file level? By that I mean is if there is a "maps" directory supplied on the http server but not a "players" directory then will it download players from the q2 server and maps from the http server?

[Edit October 13: after thinking about the above some more I'm guessing it is 100% all or nothing at the directory level as well since the code to fall back at that level wouldn't be much different than the code to fall back at the file level... still wondering about the below though.]

In very brief use I've noticed 2 things that are maybe worth mentioning...

1) file names are case sensitive if the http server is on Linux - so windows q2 server, windows client with map sending name in lower case works with a windows http server with name in either case but not with linux http server with name in upper case. If the q2 server and http server use the same case then no problem for server initiated map changes; but still potential problems if the client requests the map change - the q2 server will accept the name in either case and then possibly fail with the http server. Since people weren't too careful about naming their maps there may be lots of case problems for some servers - thought it was worth an fyi.

2) before downloading the .bsp for a map "x" it gives off two complaints:
HTTP( weapons.filelist): 404 File Not Found [2 remaining files]
HTTP( weapons/maps/x.filelist): File Not Found [1 remaining files]

and then succeeds with:
HTTP( maps/x.bsp}: 866240 bytes, 213.94kB/sec [0 remaining files]

is this normal and/or is there anything to be done to silence the complaints (which may confuse users) or give it what it wants?

Got to say it is really nice to see a large map download in nothing flat - thank you Rich!!!

 on: October 08, 2011, 10:07:41 pm 
Started by Pogo - Last post by Pogo
Increasing the fov will also deform the picture and make things appear smaller, and i'm happy with the fov i'm using now. My point is that if this was implemented properly i shouldn't need to change my fov. Unless this is done intentionally to combat the "advantage" of having a wider view, but surely that can't be the case? It works the "right" way in Quake Live for example, there you can see more horizontally while avoiding the deformation caused by changing fov. AFAIK R1ch isn't planning on releasing anymore r1q2 builds though, so i don't have high hopes of this getting adressed.

 on: October 06, 2011, 07:32:33 pm 
Started by R1CH - Last post by QwazyWabbit
Clients that don't support HTTP download files the old way - from the game server at old-style speeds. HTTP enabled clients download from the file server if enabled, from the game server the same as non-enabled clients, if not. If the file doesn't exist on the HTTP server, the r1q2 client won't try to get it from the server the old fashioned way, you just don't get the file.

It's the responsibility of the server admin to make sure files are synchronized and are identical for both methods. This can be a PITA to admin if you don't control both servers.

What I wanted to see was HTTP download when enabled but fail-over to UDP download in the case of an error in the HTTP method.

 on: October 06, 2011, 05:27:25 pm 
Started by R1CH - Last post by hehheh
I asked R1ch for this in a bug report on HTTP download. If it doesn't exist on the HTTP server, the client can't fall back to normal download. Rich declined to modify the code to allow UDP fail-over. I hope you have better luck.

What happens for non-r1q2 clients then - do protocol 34 clients not get any download or do they download from the game server while the protocol 35 clients download from (only) the file server?

 on: October 06, 2011, 10:09:31 am 
Started by Pogo - Last post by puppy
you should increase fov

new fov = 2*ArcTan( (X/Y) * (Y_old/X_old) * tan(fov_old /2) )

where X_old and Y_old are normal widescreen resolution (3/4 = 0.75)
where X and Y are widescreen resolution

for example normal fov was 105 in 1920x1080 it should be 120
(round up to the lower whole)

2 * arctan( 1920/1080 * 0.75 * tan(105/2) ) = 120

in calc should set "degrees" mode

 on: October 02, 2011, 05:34:58 pm 
Started by Elysium - Last post by QwazyWabbit
Release b8012 is confirmed not to load SP mode in a system with the full commercial version of Q2 installed. The program insists that single player data is missing. This appears to be a malfunction in the StartGame function in the new version. It checks to see if base1 will load. There is a bug introduced in this version as a result of StartGame calling the CM_MapWillLoad function which looks for two files, base1.bsp and base1.override. This function gets called twice, first by StartGame looking in the Quake2 root folder for both of these files and the second time by SV_GameMap_f looking for them in the maps folder. BOTH tests must pass, indicating that one or the other file exists or the game will fail to start. Since base.bsp is properly stored in the maps folder of pak0.pak it never exists in the quake2 root. The result is that the first call, by GameStart doesn't find base1.bsp or base1.override in the root and announces the failure, preventing SP mode.

You can work around this bug by putting an empty base1.override file into your Quake2\baseq2 folder.

Once that file exists and you restart r1q2, the empty override file will be found in the root, passing the first test and base1.bsp will be found in the maps folder of pak0.pak on the second pass and you will be able to play single player.

IMO, this file check in GameStart was needlessly added and should be removed and a new version released.

 on: October 02, 2011, 04:29:19 pm 
Started by Elysium - Last post by QwazyWabbit
Symptoms confimed on a known good full commercial installation of Quake2.

 on: September 27, 2011, 02:11:47 pm 
Started by Elysium - Last post by Elysium
I have all of the retail single player maps but R1Q2 says they are missing when I try to start a new game via the menu.

Also, I would hope that R1Q2 checks for the demo maps (demo1.bsp, demo2.bsp and demo3.bsp) as well. This is fairly important to me as my Q2 installer (Quake II Starter) uses R1Q2 along with the Q2 demo data.

Thanks, and it's always appreciated when you take the time to work on R1Q2!

 on: September 25, 2011, 11:12:39 pm 
Started by Q2 Dedicated server - Last post by island55
your using a tourney mod config file for the base quake2... wont work. well it will work but most of the cvars are invalid. also you need to download the anticheat and install it on your server and you can use either r1q2 server or q2pro server

R1Q2 can be found at:  http://www.r1ch.net/stuff/r1q2/
Q2PRO can be found at: http://skuller.net/q2pro/

then you need to come up with an original quake2 server config and edit it to your liking and you should be good!

 on: September 12, 2011, 11:39:53 pm 
Started by R1CH - Last post by R1CH
This will probably be the last release of R1Q2. Hopefully I didn't introduce any regressions, the demo thing worries me as I don't recall how well tested it was but we will see. Unfortunately my Linux build environment got destroyed somewhere in the last few years so I don't have any pre-built binaries for Linux. Sorry.

  • Common: Fixed %p / 0x%p inconsistenices in error messages.

  • Common: Run "EXEC_NOW" exec commands immediately rather than just dumping into the command buffer. Fixes issue with r1gl.cfg not applying.

  • Client: Increased HTTP download to 4 connections by default.

  • Client: Fixed another crash that could occur when issuing vid_restart or changing vid_ref while connected to a server.

  • Client: Fixed a possible crash in the video menu.

  • Client: Hide "ignoring DirectInput mouse" message when using cl_quietload.

  • Client: Ignore cl_quietload and vid_quietload if developer 1 is set.

  • Client: Check before starting a game from the single player menu that the single player maps are available.

  • Client: Improve how demos handle non-recordable (oversized P35) packets. Recording now maintains a last valid delta so a lost demo frame will be recovered and deltas will continue from the last known valid frame. This should fix instances of entity state corruption following a lost demo frame due to invalid deltas. In the instance of many dropped frames or packet loss, uncompressed messages will be written.

  • Client: Fix cl_railtrail being set too high causing an error.

  • Client: No longer require 1ms per frame, allowing frame rates to be unlimited (previously capped at 1000 fps). Note that extremely high frame rates may cause visual artifacting.

  • Client: Prevent quake2:// links from being able to include additional command line options.

  • Client: Support for q2proxy, a re-routing proxy to route connection through a 3rd party server in an attempt to reduce latency. Set cl_proxy to the address of the server running the proxy then connect as normal. Experimental, may cause complications with multiple clients from the same IP.

  • Client: Improved precache speed when running with vsync on.

  • Server: Improved qport handling from multiple clients from the same IP.

  • Server: Fix 'required' flag on anticheat-hashes.txt to actually kick clients that fail the hash.

  • Server: Include 'port' in response to status or heartbeat messages to help with NAT traversal.

  • Server: Configurable rcon brute force protection, sv_rcon_ratelimit cvar to control how many rcon requests to allow per second.

Pages: 1 ... 8 9 [10]
Powered by SMF 1.1.19 | SMF © 2013, Simple Machines