I know an Arcane Dimensions map built by a very handsome young lad that has random mirrors in it now because of the feature "texures specifically named 'mirror_*' are mirrors... and arbitrarily 'window02_1' as well"

I'll just recompile the damn thing with the texture renamed I guess. 

oh, in less salty feedback on mirrors, may want to consider doing some sort of fade effect when a mirror becomes active? The pop in when it switches between mirrored and non-mirrored can be quite noticeable. 

@Bloughsburgh
I'm glad you pointed this out, I was beginning to doubt my own ears. There definitely is a kind of audio problem, a crackling like sound that you described. Quakespasm is fine now but had the exact same problem a couple of years ago, very annoying. 

To something less mirrory like 0.6 

Of course I'm almost always going to push for keeping Quake's default behavior when that behavior isn't flawed, and in this case it is not -- it's just some mods that can be "flawed." Though you have to realize, the whole concept of running a mod is that you are handing over control to the modder to change a lot of default things.... But yeah, placing an autoexec in a pak file is really bad form, but how many mods is this actually an issue with?

In any case, I think as a minimum (mainly for "those who don't know the workings of Quake"), changing game directories should produce the same reminder text that Quakespasm does:

'enter "exec quake.rc" to load new configs.' 

Mh had actually already pointed out some options regarding how to pull off the original underwater warping effect in the old Mark V thread back in 2012.
I dunno if all of his suggestions turned out to be impossible to implement, but maybe they deserve a second look.

(I know, I am kinda nagging with this, but it's one of the very few things that Mark V could still do better. :P) 

if switching gamedirs results in a different quake.rc, default.cfg, config.cfg, or autoexec.cfg file, then save the config, then (effectively) switch the gamedir, reset all cvars to their defaults and exec the new quake.rc. when saving configs always save to the same location as the shallowest of those 4 files.

mods that fuck up your config to enable things that increase sw-rendering capacities will still apply for the new gamedir, but will not be able to affect other gamedirs any more thanks to the reset thing.

the mod will still pick up your normal config.cfg the first time you run it, but thanks to it declaring itself as a special snowflake, further changes to your regular config.cfg won't continue to impact it, and vice versa.
if a mod wants/needs to be special, let it. and if its just a map pack then it really shouldn't need to have its own config file either.

that's how fte handles it, except without the auto-saving-your-config part, because that's considered an explicit action in most quakeworld engines.
that said there are still some things that I could improve... like userinfo changes spamming the server. :s 

https://twitter.com/tonycoculuzzi/status/800311323040976896

I want to see what mankrip and spike can do with this effect =D 

Serious Sam did that well, I really enjoy that effect.

I think killpixel was showing some of that type of stuff in the screenshot thread? 

Is autodemo disabled by default in the latest version? 

 

Yes.


@Baker "cl_autodemo 1 needs host_maxfps set to 72 -- otherwise it won't record because the demo size could be massive and 72 fps is only correct Quake physics in single player. (todo: document that)"

But what would be the problem if you have a lower FPS set, as I do (and probably anyone else who uses vid_vsync)? Sure, physics might be wonky in Single Player, but... that's not exactly a reason to prevent autodemos if the user wants them, at a lower FPS.




I'm playing with zoom aliases now. I think r_viewmodel_fov should default to 0 (standard Quake behavior) rather than 90. Yeah, it improves the look if someone sets a higher fov, but it makes it look weird when you zoom in with a lower fov.

Standard Quake is the opposite, looking correct when you zoom in but bad when you set a high fov.

So, I prefer standard Quake behavior, especially when I have set "weapon draw = quake default" in the menu.


An optimal way to do this might be to have 2 separate variables:

r_viewmodel_fov_min
r_viewmodel_fov_max

Then you could set the max at 90 to never get the weird effect when zoomed out, but the viewmodel would still be allowed to be pulled back when you zoom in (which looks correct).. unless you wanted to clamp that too with the min setting to not go below. 

I'll make the cvar that control "window02_1" only apply to the id1 folder.

I'm hardcore and already had realized that even as a setting it would default on for people using -game. 

maybe you can bring it to the preferences in menu? 

Weird, I always set fps to 150. Monitor is 144hz though, need that max fps 

I know which mappers reside in Asgard and know you are one of them, I've read this site regularly and know, for example, you used to run the speed mapping session.

Let me assure you that if for instance that if you have something to say, I am always listening.

I'm a very conservative engine developer despite also adding player-oriented features.

When I started engine coding, Ben Jardrup helped me several times and would explain the compatibility mindset to me. 

Same,

I never encountered any physic issues so I just kept it at my max refresh. :O 

I'm quite interested in why the framerate changes the physics. I wonder if it is the physics stuff being calculated every frame, rather than every 1/72nd of a second.

If that is the case is it worth trying to keep the framerate at a multiple of 72 to be safe? (144 if your monitor can do it). 

autodemo -- pulsar, I'll spend some time thinking about right way to handle to.

sound 44000 - bloughsburg, I remember some of the sound mixing discussions about that. I'm adding that to my list and will eventually happen.

@fifth - Not sure what you are wanting. Quake physics are still 72 fps and although fps independent physics is on my eventual to-do list. If you set 144 hz in your video card and vid_vsync 1 and host_maxfps 144 in the console, do things work as expected?

@gunter - at a higher fps, the demo files could become huge. Maybe make cl_autodemo 2 option -- record an autodemo regardless of the fps. gun fov 90 -- people love the feature, you know how to disable it.

@nightfright - at least for now, Mark V is a pure Open GL 1.2 engine for maximum hardware compatibility for any machine Windows XP or higher. MH needed a glsl for that in Remake Quake engine.

The track by mapname thing, I will think about and have an idea on a "correct solution" which would give you the same ability to control it but does not work in a way similar to what to you suggest, but I would need to put some thought into it so is more likely a future version item.

@nightfright part 2 ---

I'd recommend creating a Wiki page at https://quakewiki.org/wiki/Main_Page listing extra replacement content paks and I'll put a link to that page on the Mark V page -- that way if new content becomes available it can be updated and available to users without me continually editing the Mark V homepage.

Be sure to upload mod enhancements to Quaketastic (see Func screenshots thread for username, password if you don't already know) beause Quaketastic files are preserved forever at the Amazon/Government funded archive.org site (!!)

/I think that's most of the replies, I read Spike's thoughts on gamedir change and @snaut yeah that's cool. 

I've always thought that the engine ought to be able to cap the framerate of the demo independently of the actual client framerate -- When I recorded demos for rubicon 2 I intentionally set host_maxfps really low to get a smaller demo file, but it would be nice if it was an automatic feature.

But, I never did the research into what kind of problems would have to be dealt with to make the demo playback correctly. For example obviously the dropped frames might have important events in them, you'd need to save them and put them in the next demo frame so they are not lost. 

Spike actually has a separate thread (or similar) in FTE to ensure 72 fps even if the client goes under 72 fps.

In 2014, I made a run at acquiring DirectQ's fps independent framerate, but noticed a little jerk in DirectQ when using +turnleft and +forward at same time -- so I moved it to the back of the queue for future consideration. 

I suspect Spike might suggest that the best to get such a result might be having the "server" record the demo instead of the "client" --- in a properly client/server separated engine (like how the Quakeworld engines have complete client/server separation). 

Never knew it affected demo filesize. I always play at 144 fps and never noticed any bugs 

two things:
1) use a decent network protocol that doesn't resend everything every single packet. get AD's particles under control by harassing sock into using clientside stuff instead of network abuse.
2) screw threads, just don't send packets to the server quite so often. from what I remember the only real challenge is figuring out how to deal with impulse;wait;impulse scripts. one way is to just not wake up from waits while connected with an impulse still pending. obviously if there's any hacks internally directly linking both client+server then you'll need to fix them, otherwise independant rendering/server isn't really any different from a public server or demo. drop the server's rate to 10hz and you'll get quake2! 

Yes to all of that ;-)

Btw, offhand do you know about about the bloughsburg/zbikey sound crackle @ 44 hz. I don't touch the sound mixer often -- and such a conversation wasn't recent so I can't recall the details immediatelly. Is that the true hz is 48k issue?