Gunter - proquake feature suggestions

Post a reply


This question is a means of preventing automated form submissions by spambots.
Smilies
:D :) :( :o :shock: :? 8) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen:

BBCode is ON
[img] is ON
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Gunter - proquake feature suggestions

Re: Gunter - proquake feature suggestions

by Gunter » Tue Jan 22, 2008 3:17 pm

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).

Re: Gunter - proquake feature suggestions

by Baker » Tue Jan 22, 2008 9:43 am

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.

Re: Gunter - proquake feature suggestions

by Orl » Mon Jan 07, 2008 9:05 pm

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.

Re: Gunter - proquake feature suggestions

by Gunter » Mon Jan 07, 2008 7:56 pm

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.

by Guest » Thu Jun 28, 2007 10:11 pm

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!

by Gunter » Thu Jun 28, 2007 9:07 pm

Er, I wanted to do sizeup and sizedown, but you've replaced the + and - keys with the volume controls... I think it would be better to (is this possible?) leave the default + and - function as sizeup/sizedown, and have SHIFT + and SHIFT - do the volume controls (pressing SHIFT and the + or - keys together).


I was sizing up and down to check the weapon model drawing modes, "classic" and "true pos."

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).

I guess that's just a matter of preference anyway....

by Gunter » Thu Jun 28, 2007 8:41 pm

There's another issue with move interpolation. When something goes off the screen, you need to stop keeping track of it for interpolation purposes, otherwise, when it re-enteres the screen at a later time, the movement interpolation tries to interpolate it from it's last seen position (which will no longer be accurate) to its new position.

For example, go into chase active, then go back to first person view. Then sidestep some distance and go back into chase active.... It will try to interpolate your model to the new position from the old one....


And one little issue, where it says "unofficial proquake" in the console, it's the same color as the quake text, so when you try to read a line of text in the console at the bottom, it's very hard to read.... Perhaps if you could make it say "unofficial proquake" in a dark color, this would be better? I don't know it that's possible... but that's been a minor annoyance for a long time in proquake...

by Baker » Thu Jun 28, 2007 6:06 pm

Oh, and another one to fix: dead bodies (and holograms in runequake) lose their colors... know what I mean?
Yeah, I've been looking into that one. DarkPlaces has it fixed, but I haven't been able to identify how it was fixed in DP because I don't fully understand the nature of the problem ... yet.

by Guest » Thu Jun 28, 2007 6:04 pm

Gunter wrote:What the heck... I'm not getting ANY weapons appearing in deathmatch mode with this...... even running standard quake (listen server, no FvF)......
Couldn't tell you. Works fine for me.

However! I did put in some "iffy" code from FitzQuake that make perfect sense for single player but now that I think of it, could interfere with mods.

I'll reverse the FitzQuake code that reset skill level, etc. when using single player in the menu.

Baker wrote:A dedicated server will not update the monsters' positions as often as it updates the players' positions (at least I think this is what causes it). This results in the monsters moving around very choppily on the server.... This doesn't happen on a listen server though (just running a server in your Quake game window).

Now, the interpolated frame animations look good and smooth, it's just the moving from place to place that looks very choppy.
Ah! A research item. Ok, now I understand what you mean about the interpolation. And it is perfect with a DP client connected to a ProQuake server, right?

Connect to FvF and go into ghost mode and fly around and look at some of the monsters walking around... You can see their movement is very jerky, but player movement is nice and smooth (even without your extra interpolation enabled).
If you connect with Darkplaces, you can see that even the monster movement has been smoothed out.... No other quake client does that.
LordHavoc once told me that "smoothcam" is always on in DarkPlaces, unlike ProQuake which needs pq_smoothcam 1. Maybe this has something to do with it.

Another thing: interpolated weapon model frames never look right, so it should be disabled by default for the weapon model (for example, the muzzle flash seems to dance around instead of appearing and disappearing). This is especially true with some of the altered weapon model animations I use on FvF.
I agree. This is particular obvious with the nail gun.

by Gunter » Thu Jun 28, 2007 5:53 pm

^ in any case, would it work to have Proquake use the Internet IP address by default if one is detected? If you're behind a router you'd only have the local net IP address detected on the computer, and the router handles the rest (is that correct?). But I just have a small home network between a couple computers, so my machine detects both the local and the Internet IP addresses, but Quake defaults to using the Local one, which would prevent me from connecting to servers on the internet.....






Oh, and another one to fix: dead bodies (and holograms in runequake) lose their colors... know what I mean?

by Gunter » Thu Jun 28, 2007 5:08 pm

Ok, giving it a test-drive.

Let's see,


When I die or press TAB, there's a message in the top right that says, "Skill: Normal." That message is printed right on top of the FPS display.... I think that needs to be offset so it doesn't overlap.


And I run in a window, and the brightness slider doesn't do anything for me...


And uh... "Crosshair: On" seems to be more accurate to where my missile hits than "Crosshair" Centered"... is that right?



And... this is doing something different..... Forcing the SKILL somehow?
Normally in FvF, skill 0-2 is "Hard" and skill 3 is "Nightmare." The progs.dat treats skill from 0-2 the same, and sticks in all the monsters as if it were Hard mode... The skill in Quest mode is 1 by default, but all the monsters are present. But in this new Proquake, not all the monsters are appearing when skill is set to 1.... It's taking control away from the progs.dat somehow?

And the DM weapons aren't appearing in the map either.... Hm... is it getting set to coop mode somehow? FvF Quest usually runs in DM mode with the monsters stuck in......

Deathmatch 3
noexit 0
coop 0

is what activates Quest mode... does "deathmatch 3" do something different now?


What the heck... I'm not getting ANY weapons appearing in deathmatch mode with this...... even running standard quake (listen server, no FvF)......


Baker wrote:
Gunter wrote:And of course, one that seems impossible.... correct model interpolation for all entities, players AND monsters. Darkplaces is the only client that does it correctly....
This beta has interpolation. Try it and if you don't like the interpolation, let me know why/how it is wrong compared to DarkPlaces. I'm pretty certain I can make it do whatever DarkPlaces does, but I would have to understand how it is wrong.

3.77 (w interpolation):

http://www.quakeone.com/proquake/unoffi ... ake377.zip

Ok, I think this is a server issue, but it can be fixed client side. At least Darkplaces has a way to fix it all client side....

A dedicated server will not update the monsters' positions as often as it updates the players' positions (at least I think this is what causes it). This results in the monsters moving around very choppily on the server.... This doesn't happen on a listen server though (just running a server in your Quake game window).

Now, the interpolated frame animations look good and smooth, it's just the moving from place to place that looks very choppy.

Connect to FvF and go into ghost mode and fly around and look at some of the monsters walking around... You can see their movement is very jerky, but player movement is nice and smooth (even without your extra interpolation enabled).

If you connect with Darkplaces, you can see that even the monster movement has been smoothed out.... No other quake client does that.


Also, this problem seems to affect your own player model when you use chase_active 1 and step sideways, back and forth... It looks twitchy when interpolation is on.


Another thing: interpolated weapon model frames never look right, so it should be disabled by default for the weapon model (for example, the muzzle flash seems to dance around instead of appearing and disappearing). This is especially true with some of the altered weapon model animations I use on FvF.

Gunter wrote:Make Proquake, by default, not use local network IP addresses!
Actually, your understanding of the issue is wrong. With DSL or Cable, ProQuake needs to use the local ip address.

The ProQuake Launcher has an -ip penetrating connection feature that can overcome the -ip problem.

My real question for you is does the -ip problem exist in Quake 3. Quake 3 is open source and if Quake 3 does it right, I could implement the code.

I have no idea about Quake3, but I would guess they fixed that problem by then.... It's worth a try.

by gulliver-trans » Thu Jun 28, 2007 4:12 pm

Baker is da man.

by Baker » Thu Jun 28, 2007 2:55 pm

Gunter wrote:I never said I wanted one badly. But it would be cool to have some things fixed. Like:


Correct Fullbrights.
I might be trying this soon.
Gunter wrote:And of course, one that seems impossible.... correct model interpolation for all entities, players AND monsters. Darkplaces is the only client that does it correctly....
This beta has interpolation. Try it and if you don't like the interpolation, let me know why/how it is wrong compared to DarkPlaces. I'm pretty certain I can make it do whatever DarkPlaces does, but I would have to understand how it is wrong.

3.77 (w interpolation):

http://www.quakeone.com/proquake/unoffi ... ake377.zip

Gunter wrote:Uh... what else was there that we complain about in ProQuake? I think he already fixed some of the stuff, like the texture mismatch bug.
Yep.
Oh, how about making sure the server does not print "packet overflow" messages over and over and over when that error happens, because all that text scrolling on the server console makes the server lag even more....
I can look into that.
Gunter wrote:Make Proquake, by default, not use local network IP addresses!

This will fix one of the (if not THE) main issues that cause people to not be able to connect to online servers. Quake tries to use a local network IP address by default when one exists.... If it would just ignore them unless there are no other IP addresses (i.e., no internet IP address), that would be just swell.

Any IP address in these ranges is private, and doesn't connect to the internet, so Proquake should ignore them unless the machine has no other IP address to bind:

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
Actually, your understanding of the issue is wrong. With DSL or Cable, ProQuake needs to use the local ip address.

The ProQuake Launcher has an -ip penetrating connection feature that can overcome the -ip problem.

My real question for you is does the -ip problem exist in Quake 3. Quake 3 is open source and if Quake 3 does it right, I could implement the code.

The code the ProQuake Launcher does is very complicated and isn't well suited for including in an engine.
Gunter wrote:Also, when using -condebug to produce server logs, it almost never logs any kind of useful error message (or any error message at all) to help track down the problem when the server crashes..... It's be great if more useful info was dumped to the log on a crash.
I can look into that, but it would take a while. RocketGuy would probably have to help me simply because I don't have enough QuakeC / running a server experience to know the types of things that would be common sense to add to ProQuake to assist with that.
Gunter wrote:And, it might be nice to have colors 14 and 15 available via a console variable on the server (but disabled by default).... and making the client not reset them between levels.
I enabled colors 14 and 15 on both the client and server in 3.70, I think.
Gunter wrote:gl_texturemode gl_linear_mipmap_linear
gl_flashblend 0
I don't plan on changing any of the defaults in ProQuake -- I want it start up exactly as GLQuake does, but I do care about making them easier to change in the menu.

gl_flashblend 0 is certainly the way to go in single player or coop, but not everyone likes that in DM (the light can be really distracting and was a complaint about the ProQuake Launcher's config boost feature).

By the way, gl_flashblend does save to the config in the version of ProQuake I made so if you type gl_flashblend 0, it will save from session to session.
And I use the ALT key to toggleconsole.... Now it doesn't work right
I'm sure I could make that an option.

by Gunter » Thu Jun 21, 2007 2:24 am

by default set:

gl_texturemode gl_linear_mipmap_linear
gl_flashblend 0


And I use the ALT key to toggleconsole.... Now it doesn't work right :x
That was something I was annoyed with in Qrack. :x
I know, it's for inputting bronze letters in the console.... I still don't like it. :x


And for the people who are having trouble getting mirrors to work, tell them to try:

gl_texsort 1

That sometimes helps.

by Gunter » Tue Jun 12, 2007 6:06 pm

And for that "tell" command, let it be able to chat to people by client number, because some of the funky quake names are nigh impossible to type in....

similar to how the kick command works:

kick # 2

would kick client #2 (which can be found by doing a "status")

though:

kick "# 2"

wold kick someone NAMED # 2, heh


But tell could work the same way.... like:

tell # 2 you suck I hate you I'm telling my mom!

would send the message to client # 2.....

Top