ProQuake 3.82 (Unofficial)

[=peg=]

I'll look into it and fix that. Is this a new problem that occurred in 3.87 or is it also present in 3.80?

I only noticed it in 3.87 but its gone now (at least in the video mode i am playing in 1280x1024x16 75hz) so thats good! i did not test in any other modes tho..

the keypad still not working for me.. that is: with international keyboard mapping [off] it does not work at all (besides in console, also cl_keypad 0/1 did not change anything) and with international keyboard mapping [on] its still works incorrectly :/ (for me at least)

[Baker]

I'll dedicate some extra time to getting that pesky keypad issue fixed and maybe figuring out a scheme for aliases and such to work right with AZERTY keyboards and such.

[Fuzznut]

Thank you for all your hard work on this Baker. You really love Quake. Good for you. I think you're a good egg no matter what Canadian Sniper says about you.

[Canadian*Sniper]

I think you're a good egg no matter what Canadian Sniper says about you.

Cute. What exactly is it that I say about Baker?

[Baker]

I had demo auto-play half-implemented somewhere around 3.75 or so; after some messing around this will be fully and automatically implemented in the next release.

[IEEE 802.11]

Since when are you a programmer, Baker? Or did I miss that?

[Baker]

Since when are you a programmer, Baker? Or did I miss that?

Probably because I thought it was amusing listening to Ur dead telling me what I know and wondering the limits of how wrong he could be in a discussion :d :d :d

[Fuzznut]

Probably because I thought it was amusing listening to Ur dead telling me what I know and wondering the limits of how wrong he could be in a discussion :d :d :d

If he wasn't a programmer then how did he come up with the ProLauncher?

[Baker]

Download: Unofficial ProQuake 3.89 - 0.5 MB

Source code is here

Nothing big:

- Demo autoplay (i.e., after first use you can click on a demo [.dem] anywhere and it will automatically startup)
- Demo rewind/fast forward via PGUP and PGDN keys
- Nothing else of major interest (host_timescale, other boring stuff).

Add: 3.87 thru 3.89 are beta. They are meant to be started without a command line because video mode switching is done in the menu, and if you provide one unexpected things can happen. If you want to try it, don't use a command line because I haven't decided yet how I want to handle how it works if someone specifies them.

[=peg=]

i noticed that when i was typing a message in massage-mode 2 (say_team) the cursor started in the same position as in message-mode 1..

example:

(say team):hello

resulted in:

(say_thello

overwriting (but still showing) the chat prompt while typing the message.

using latest build (3.89)

[Baker]

i noticed that when i was typing a message in massage-mode 2 (say_team) the cursor started in the same position as in message-mode 1..

Thanks for pointing that out. It was a very small change I forgot about and did not test.

I wanted to make it clearer to someone new what was going on and that it was team talk.

Easy to fix.

Download: Unofficial ProQuake 3.90 - 0.5 MB (Beta)

Source code is here

- (say_team) display issue fix
- "anti-wallhacking" server-side - sv_cullplayers_trace (on by default) ... the server will NOT send player positions to connected clients for players who cannot be seen, making wallhacks or "pak2 cheats" rather pointless.
- sv_cullplayers_notify 1|0 (for server console for testing) - prints Player visible or not visible to console for when walking around the map.

[Phenom]

Anti-Wallhacking, awesome!

What about anti "Pak2"?

[Baker]

Anti-Wallhacking, awesome!

What about anti "Pak2"?

Explain that

If I can't see Player A, the server simply doesn't send me anything about Player A.

Neither of wallhacks nor pak2 are of any use if the server isn't sending information on players that cannot be seen.



In the above picture (see IHOC pak2 explanation page), the leftmost player will not be rendered by someone playing on a server using the anti-wallhack code, because the server will say "hey, player #5 can't see player #2 so don't send player #2's position." The position will not be sent and therefore the client doesn't have anything to render.

[Phenom]

Thats what I was talking about, the long sticks coming from the player model.

So I'm guessing the server waits until the Collision box of the player model is visable t render's the player?

[Baker]

You can try this out yourself, actually.

#1 Start up c:\quake\wqpro390.exe +deathmatch 1 +maxplayer 2 +map dm6

#2 Type in console: sv_cullplayers_notify 1

#3 Type in console: status (and see what the ip address is)



Now startup another client (Qrack, GLpro, etc.) and connect <ip address from #3> (I type connect 192.168.1.100, for example).

Now switch back to the wqpro390.exe window and walk around.

One of 3 things will happen:

1. It will print "visible" on-screen if you can see the other player.
2. It will print "not visible" on-screen if you can't (therefore it will not send the data)
3. It will not print anything at all, which is "not visible" by default.

You can walk around and if it says visible, the player is in sight or not visible if you can't see the player. If it says not visible, it isn't going to be sending the player data, that only happens if it says visible.