Qrack 1.90

[Trickle]

I want mirror alpha on qrack =]

[Lightning_Hunter]

turn off m_directinput and use -noforcemparms and your mouse should feel normal.

I just tried this, as well as about every combination possible for the mouse options, but the problem still remains. I think you may be on to something with the Enhanced Pointer Precision though. It feels to me like the newest version of Qrack is using Enhanced Pointer Precision, while 1.90 and less didn't - and it seems that I can't turn it off no matter what combination of options I use for the mouse. I did notice the same thing with 1.90 - where if you minimize the game, enhanced pointer precision is sometimes on in the mouse panel. However, it didn't always happen, and the mouse in the game itself never changed.

Maybe it's nothing, but I noticed that in version 1.90, if I use -condebug, minimize, and look at qconsole.txt, I see stuff like this at the bottom:

DirectInput Active
Mouse smoothing active

In version 1.95, I don't get that at all in qconsole.txt. Hmm...

[R00k]

condebug prints anything written to the console, it may be because extra output generated during out/in app focus. I should try to silence that output.

[Lightning_Hunter]

condebug prints anything written to the console, it may be because extra output generated during out/in app focus. I should try to silence that output.

I think you already did. It appears in qconsole in 1.90, but not the newest beta.

Rook, I think we need to have a night where we meet on AIM/MSN and figure this out.

[R00k]

I think I've fixed this the code was here

void MSG_WriteAngle (sizebuf_t *sb, float f)
{
	MSG_WriteByte (sb, Q_rint(f * 256 / 360) & 255);
}

void MSG_WriteAngle16 (sizebuf_t *sb, float f)
{
	MSG_WriteShort (sb, Q_rint(f * 65536.0 / 360) & 65535);
}

I've changed it back to the v1.80 way

void MSG_WriteAngle (sizebuf_t *sb, float f)
{
	MSG_WriteByte (sb, ((int)f * 256 / 360) & 255);
}

void MSG_WriteAngle16 (sizebuf_t *sb, float f)
{
	MSG_WriteShort (sb, (int)(f * 65536.0 / 360) & 65535);
}

Q_rint is rounding +/- 0.5 which screws up even pointing up or all the way down!

[MH]

MSG_WriteByte (sb, ((int)f * 256 / 360) & 255);

Shouldn't that be

MSG_WriteByte (sb, (int)(f * 256 / 360) & 255);

[R00k]

whoops!

[Lightning_Hunter]

Hey Rook, any news on the mouse issue? Did the code you change fix it?

[R00k]

Ya, i'm pretty sure everything works fine now. I'm also almost done implementing the fake_gl wrapper to release a dxQrack soon. Currently on my card it's stuck in 16-bit mode. but everything else works fine.

[Lightning_Hunter]

Good to hear! That reminds me, were you ever able to reproduce the packet overflow in kndybase with the configs and stuff I sent you a while back? Or should I keep Qrack 1.90 around for Frikbot editing (even though 1.95 has better ways to save waypoints)?

Also, is there a way to turn off the feature that loads start.bsp if the map typed in the console is wrong? It can really be a pain in the butt when I'm doing a lot of editing, and accidentally type a map name wrong. It wastes quite a bit of time loading the wrong map before I even realize I have typed it wrong, and I have to go back and try it again. I liked the old "Couldn't spawn server" message better for editing purposes.

[R00k]

http://www.quakeone.com/qrack/qrack201.zip

[Lightning_Hunter]

Ah! All mouse issues seem to have been fixed. Flawless mouse support, Rook. Truly flawless. I've always felt that Qrack had the absolute best mouse support of any game, and that statement still stands (minus version 1.95).

I did notice that enhanced pointer precision kept turning itself on in windows, but once I used -noforcemparms, that problem went away and everything was fine. If anyone else experiences this problem, make sure to put -noforcemparms into your commandline (maybe it should be the default?)

There didn't seem to be anymore packet overflows in kndybase, so it looks like that was fixed too! I have found one other minor problem now, however. There is a map that refuses to load, and I imagine it's because the map has 5 .way files. It crashes out of the game with, "Ed_alloc: no free edicts". This map loaded just fine in 1.90. So far, this is the only map I've found with this issue, so it's not a huge deal, but I thought I would mention it anyway. It only crashes using the Frikbot mod when the waypoints are loaded. You can download the map and waypoints here to see for yourself:
http://filebeam.com/9e5a587b0a98e9e203fb6a9f99fd191e

I would still like to see a cvar that makes it optional to load start.bsp when a mapname is typed wrong in the console. I much prefer the old method where the console just tells me the mapname I typed in is not valid, rather than loading up start.bsp. I'm sure some people like the new way for servers, so a way to turn it on and off would be perfect.

[=peg=]

So I wanted to give 2.01 a try, started with a clean sheet, just id1 pak0 and pak1, no custom maps, no other client crap in the folder.. just glqrack and all the files that came with it in the .zip -> Run it -> single player -> start new game -> CRASH!!

(windows xp, amd2600+, 768MB ram, nvidia GF6800GT)

[Baker]

Ya, i'm pretty sure everything works fine now. I'm also almost done implementing the fake_gl wrapper to release a dxQrack soon. Currently on my card it's stuck in 16-bit mode. but everything else works fine.

Ah Cool!

[Lightning_Hunter]

So I wanted to give 2.01 a try, started with a clean sheet, just id1 pak0 and pak1, no custom maps, no other client crap in the folder.. just glqrack and all the files that came with it in the .zip -> Run it -> single player -> start new game -> CRASH!!

(windows xp, amd2600+, 768MB ram, nvidia GF6800GT)

It works fine for me! I just now put pak0.pak and pak1.pak in a folder, extracted the qrack content to the folder, double clicked glqrack.exe, and everything works. I started an SP games with no problems. My system specs are similar to yours:

Windows XP
pentium 4 processor 2.8Ghz
Nvidia GF7800GS
1 GB of RAM

Are you using any commandlines?