Future vs Fantasy Quake

Gunter wrote:Er, I wanted to do sizeup and sizedown, but you've replaced the + and - keys with the volume controls

One of the less than 3 "actual" changes in the Unofficial ProQuake. The sizeup and sizedown keys are pointless and newbies manage to mess up their screen and then post in forums "Help! I can see my health."

Everyone needs to change volume occasionally. Sizeup and sizedown are in the menu anyway.

... I think it would be better to (is this possible?) leave the default + and - function as sizeup/sizedown

Well, I tried to consider where to put volume up/down and didn't want to touch +/- merely out of conservatism, but after thinking about how the sizeup and sizedown binds are only good for noobsters to get confused and then tell me the Undergate made their status bar disappear, I don't see any benefit to those keys.

I mean another change is that mouselook is on by default instead of off by default.

I might add an option to make +/- the default old Quake way.

and have SHIFT + and SHIFT - do the volume controls (pressing SHIFT and the + or - keys together)

CTRL -/+ will probably end up being brightness control. SHIFT -/+ needs to be the dash and the = sign.

This may be hard to describe, but the weapon model should always show as much as it does when you have the screen sized up to full (with no console showing).

With r_truegunangle 1 (weapon = true pos), it uses the DarkPlaces/FitzQuake style of drawing the weapon and with it 0 it uses the classic method GLQuake method.

Perhaps if you could make it say "unofficial proquake" in a dark color

I will probably make this simple text like JoeQuake/Qrack and DarkPlaces do. I agree -- it is really ugly currently!

Baker, over there at Quakeone http://www.quakeone.com/forums/showthread.php?t=3142 wrote:Things like this really agitate me when I discover them.

I totally told Baker about this problem last year, heh, but he said,

Baker, back on page 1 of this topic wrote:Actually, your understanding of the issue is wrong. With DSL or Cable, ProQuake needs to use the local ip address.

I guess his understanding of the issue was wrong, heh.... But maybe now that he's experiencing it first hand, he'll be able to fix it....

I still think my suggested solution seems like it would be easy to implement...

If there is an external IP detected, have Quake simply not use IPs that are in the local network as the default IP.... like these:

10.0.0.0 through 10.255.255.255
169.254.0.0 through 169.254.255.255
172.16.0.0 through 172.31.255.255
192.168.0.0 through 192.168.255.255

That's all of them, so it's not a lot to check for.
To get fancy, let the user select which IP to use from inside Quake, if that's possible....





Ok, new bugs in proquake 3.95.....

I play in a Window, and I use the ALT key to toggle the console and free the mouse. First, the ALT key won't "untoggle" the console like it does in standard proquake (this one isn't actually new to BakerQuake, and it the same way in Qrack... which I also avoid using)... The layout of my wolfking keyboard makes this a dealbreaker for me. I need the ALT key to be able to toggle the console.

Now here's the new bug.... When I bring down the console and free the mouse (gl version by the way, and remember I'm running in a window)... the mouse is trapped within the area of the screen that the proquake window occupies! I can't move the mouse past the edge of the quake window!

What was worse, is that even after I closed quake, the issue was still there! I couldn't move the mouse cursor outside of the screen area where the window HAD been!

I had to restart quake then kill it with CTRL+ALT+DEL so that it wouldn't close while in the mode that had the "free" mouse cursor (because pressing escape also frees the mouse cursor)..... Even after that, my mouse sensitivity in windows was wrong and I had to reset it.

Gunter wrote:

Baker, over there at Quakeone http://www.quakeone.com/forums/showthread.php?t=3142 wrote:Things like this really agitate me when I discover them.

I totally told Baker about this problem last year, heh, but he said,

Baker, back on page 1 of this topic wrote:Actually, your understanding of the issue is wrong. With DSL or Cable, ProQuake needs to use the local ip address.

I guess his understanding of the issue was wrong, heh.... But maybe now that he's experiencing it first hand, he'll be able to fix it....

I still think my suggested solution seems like it would be easy to implement...

If there is an external IP detected, have Quake simply not use IPs that are in the local network as the default IP.... like these:

10.0.0.0 through 10.255.255.255
169.254.0.0 through 169.254.255.255
172.16.0.0 through 172.31.255.255
192.168.0.0 through 192.168.255.255

That's all of them, so it's not a lot to check for.
To get fancy, let the user select which IP to use from inside Quake, if that's possible....

Well theres no need to rub it in...

I still use a slightly modified version of glpro 3.50 as my main multiplayer client that uses little CPU and fixes the texture mismatch problem. But that doesn't have anything to do with the topic.

Gunter wrote:I still think my suggested solution seems like it would be easy to implement...

If there is an external IP detected, have Quake simply not use IPs that are in the local network as the default IP.... like these:

10.0.0.0 through 10.255.255.255
169.254.0.0 through 169.254.255.255
172.16.0.0 through 172.31.255.255
192.168.0.0 through 192.168.255.255

That's all of them, so it's not a lot to check for.
To get fancy, let the user select which IP to use from inside Quake, if that's possible....

In the latest version, 3.99e, I ended up doing this. I hadn't read your post here when I worked through the "right" method, but it's a good thing I did because I forgot about the 172 range and wouldn't have included it.

Anyway, what is possibly the first totally "ipfreely" Quake client is available for testing.

Without others checking to see if it solves their -ip problem, I really can't be certain because proper testing requires verification.

I didn't spend any time on the -dinput + -window + mouse sensitivity thing yet, but I will. I will also come up with a way for you to use ALT to bind toggleconsole, etc. by the time this reaches 4.00.

In the past, my focus was solving aggravating problems. Now I'm in debug and refinement mode, since all the toughest stuff is done (resolution switching, etc.). When I was first learning the engine, there were things that seriously pissed me off about Quake that seemed like they would be an impossible amount of effort to fix and I really wanted to focus on the big problems instead of small user preferences, so I'll be looking into that stuff. It can't be difficult.

Ok, new bugs in proquake 3.95.....

I play in a Window, and I use the ALT key to toggle the console and free the mouse. First, the ALT key won't "untoggle" the console like it does in standard proquake (this one isn't actually new to BakerQuake, and it the same way in Qrack... which I also avoid using)... The layout of my wolfking keyboard makes this a dealbreaker for me. I need the ALT key to be able to toggle the console.

Now here's the new bug.... When I bring down the console and free the mouse (gl version by the way, and remember I'm running in a window)... the mouse is trapped within the area of the screen that the proquake window occupies! I can't move the mouse past the edge of the quake window!

What was worse, is that even after I closed quake, the issue was still there! I couldn't move the mouse cursor outside of the screen area where the window HAD been!

I had to restart quake then kill it with CTRL+ALT+DEL so that it wouldn't close while in the mode that had the "free" mouse cursor (because pressing escape also frees the mouse cursor)..... Even after that, my mouse sensitivity in windows was wrong and I had to reset it.

Very nice!

I tested it and it works correctly with my dial-up connection; no "-ip" command needed. And it's still able to connect me to a server that I run locally as well (10.0.0.1).