Thanks! 

 

I fixed it in rubicon 2, the solution was to use a different channel for the second sound I think 

Created a page on the Quakewiki for external .vis and .lit packs, and put a link to that page on the Mark V page.

I separated out one (Abyss of Pandemonium) as an example and uploaded it to Quaketastic and put a link to it. See the first page in the Func "Screenshots" thread for the Quaketastic username and password.

This way new .vis and .lit content files can be added and updated. 

Video - Flames using QMB particle system

The QMB particle system is now working.

It'll be in the preferences menu and off by default. 

I have some extreme nitpickery to report.

Messing with the fullpitch stuff, I see that Mark V says these value mimic normal Quake:

cl_maxpitch -70
cl_minpitch 80

Buuut, they don't.
These values do:

cl_minpitch -69.93
cl_maxpitch 80.17

So it seems Mark V's pitch is very close to 0.17 lower than it should me.

How do I measure this? Well, start up a new multiplayer game, set gl_texturemode gl_nearest to get a nice sharp pixely look, and look all the way up or down. Looking down, set fov 30 or so and find a nice spot on the floor where you can mark your crosshair position. Do the same by looking up as far as you can with fov 10.

Repeating this (take screenshots if you like), you can see that in original Quake and Proquake, the position is identical, but in Mark V (and I think earlier Fitzqauke) it's off by a bit, unless you make the settings I posted.



Though neither of those cl_maxpitch values will be without issue when connecting to a Proquake server which disables fullpitch.

Upon connecting to FvF, for example, I find my value is altered to:

"cl_maxpitch" is "79.9969" (altered!)

Setting anything above that value causes the weirdness when you try to look all the way down and your view is jerked back to a legal value.

Though with the server sending the setting to me automatically, that's not really an issue.



On a less nitpicky note (though some will disagree!), this is one of those settings I have in the "Restore Quake Defaults" section of my MarkV.cfg file.

The Quake defaults should be respected and left as the defaults here. Fullpitch is for people who want an altered-from-default functionality.

Gosh darn it, back when I was a kid, we couldn't look all the way up and down, and WE LIKED IT THAT WAY!!



Though,

cl_minpitch -700
cl_maxpitch 800

Is pretty funny to play with! 

You are very likely correct about the original pitch numbers because of how client/server read and write those numbers and various roundings that happen (floating point imprecision and conversion to integer types of various sizes).

I remember having to do some fighting with those numbers when test against servers that require original pitch limits or they will fix your angle for you, which is an unpleasant experience. 

I just noticed an interesting interaction between shadows and transparent water.

It looks like the water is being drawn on top of the shadow instead of the reverse. So if the r_wateralpha is 1, you don't see the shadow at all. If the r_wateralpha is .1 then you see the shadow pretty well with a very faint water surface on it, and r_wateralpha 0 makes the shadow fully dark (using r_shadows -1).

This may be related to the issue NightFright reported on #697 of the old thread (and that issue still occurs, by the way). 

they seem to occur around every 30-60 seconds and last for about 3 seconds. the fps doesn't drop at all. It's like micro-stutter with input lag. I initially thought this had something to do with the seemingly random autosaving (didn't know winquake autosaved randomly until now) but loading the autosaves after a lag spike doesn't show a correlation.

this is on a relatively powerful pc (4970k, gtx980, ssd, etc). Still poking around for a solution... 

Shadows + water looks fine to me. screenshot.

Is this DX8 or a special circumstance or combination of settings? I believe you, but need more information or an example -- post a screenshot?

/Note: I expect to change r_shadows -1 to r_shadows 2 in next version. Follows more closely to the way other cvars work like r_lerpmodels (0,1,2) 

Are you using host_maxfps 72? 

144. going to test with 72.

im dumb.

sorry. 

Both GL and DX.

I think you are getting the shadow effect there, but it's not very noticeable because your shadow is fully in the water, and the area is dark. Notice you see the water texture on top of your shadow, but your shadow should be fully dark if you are using r_shadows -1

Stand somewhere so your shadow is partially over water and partially over solid ground, and alter the water alpha settings to 0, 1, and somewhere in between. Try the little square thin water place on e4m2 or just stand on the upper level of e1m3 so that your shadow overhangs the edge above the water.

Or the Start map, just stand so your shadow passes over one of the cracks in the floor with water below.

Uhhh... I wasn't going to post a screen because this should be easy to reproduce, but what the heck is happening here?

http://imgur.com/a/vUIz9


Some kind of anti-wallhack thing? sv_cullentities is 0. If I set gl_clear 1 then that area becomes grey. This in in DX. Looks like in GL, the area is grey even with gl_clear 0. 

Oh, chase_mode 1 is what's causing that weirdness.... I know that's an "experimental" feature... but that's an ugly effect, heh. 

You are using chase_mode and I told you it was experimental ;-)

Sometimes chase_mode can't work perfectly for a few different seasons --- remember the thing about saying how complex camera code is in modern games?

In your screenshot, the camera and the player are in different visibility leafs.

The player can't see those walls, but your camera view point can.

Only one solution for you: Type r_novis 1 + sv_novis 1 and pay the price for the server sending 100% of all entities and the client-side just assuming every wall in the map can be seen. 

Yup, r_novis 1 clears it up. But I'm not leaving that on. Of course, normal chase_active 1 doesn't have the problem, but I like the neat feature of having my crosshair remain accurate in chase mode (that's all I really want), so I'll deal with the occasional ugly effect and keep using chase_mode 1. 

It can actually even happen with standard Quake chase_active with all default settings pretty rare.

Maybe at some point I'll do some sort way to make the crosshair appear in chase_mode. 

Feature tweak request:

If your bestweapon is currently selected, then have the bestweapon command switch to the next item in the list.

Example:

bestweapon 8 5 4 3 2

Normally this command will switch you to weapon 8 (assume you have it).

But if you have weapon 8 currently selected, have it switch you to weapon 5 instead (or 4 if you don't have 5, etc.).

Activating it again would switch you back to 8.

So effectively it will toggle between two weapons -- your best and second best, as you define.

In this example it lets you toggle between your two best close-range weapons. I would find this quite useful, and better than doing "nothing" if you already have your bestweapon selected. 

Gosh darn it, back when I was a kid, we couldn't look all the way up and down, and WE LIKED IT THAT WAY!!
No we didn't, it's always been annoying. 

if it's there, I'm having trouble detecting it at 72fps since it's a slideshow at that point.

I don't notice any physics issues at 144. I'll live with the lag if the fps increase is indeed the cause :/ 

This may or may not help you ...

What would be different about your powerful machine that would make it have an input lag issue that doesn't appear on far lesser hardware?

I mean Mark V --- even the WinQuake version -- runs great on some real clunkers.

Try running on a different computer. Then think about yours.

In my experience, people who beastly machines usually over-configure something.

/If you ever do figure it out, let me know. 

Mark V does simple Windows input just like Notepad (no kidding). Doesn't even do DirectInput. Did you have something "amped up" going on with your mouse, or really fancy settings for your mouse or set a polling rate or anything.

/I hope whatever it is comes to light. 

A cursory check -- the Windows message queue appears to holds 10,000 messages, according to what I found on stackoverflow.

I don't know what your mouse polling rate is, but if it is set real high, it is possible your mouse might be overflowing the Windows message queue.

Which according to these sources, would stall it. 

killpixel, I don't suppose you are using skyboxes? If so, try disabling them. I am playing with the GL version and getting reproducible stutters when using skyboxes, but there are other settings or something involved which I am trying to nail down....


Here's what I do to reproduce the stuttering: In a new instance of GL, single player, go to e4m5 (notarget), load a skybox, walk down the hall and turn right and walk out to the nails, it stutters in up to 4 spots (the same spots), I think as each section of the skybox loads.

It happens every time with my full setup running (from my FvF folder), but I can't get it to happen reliably when running clean out of id1.
I'll try to narrow it down....


Also: GL + fog 0.025 + r_skyfog 0.05 is being wonky for me. Not all maps and positions, but I think I can see the seems in the skybox appearing sometimes:

http://imgur.com/a/fEMJ2

I was getting some weirdness in the upper level of the sky even with skyboxes disabled too, again when the fog settings were on. GL version only. 

Your link is broke, btw.

you are using skyboxes

Nope. I play with classic sky 24/7/365. Unless --- the map sets a skybox.

Note: r_skyfog 0.05 isn't so much for users to play with, but rather so mappers can tune the appearance of how they want the fog to look in the maps they are building.

Common values are 0, 0.25, 0.5, .75, 1 and really if you are using something much different than those values it wasn't designed for that.

I don't know what r_skybox 0.05 would look like, but it is an illogical value to set because someone would basically be using 0. So just use 0.