I'm not familiar with the Quake Injector -- I've heard it mentioned, but have never used it. But I was just thinking, "maybe a good solution would be a stand-alone Quake runner, much like QView, but for running mods + maps.... Maybe that 'Quake Injector' could be made to do something like that."

So yeah, you could have a program that looks like Qview, only it scans your Quake folder for mod folders and asks you which one you want to run, and maybe it scans that folder for map files, and if there is only one it runs that, or it could use a similar "guessing" algorithm to select the most likely start map, perhaps showing a list of those maps with the default one selected. Then you click run, and bingo-bango, it automatically runs your selected Quake exe with command like automatically tacked on (similar to how Qview does it to connect you to a server), with -game +map automagically set for you. (Though Qview just tacks on "-exec Qview.cfg" and puts its settings in that).

Heck, someone should make an updated Qview that can both handle running local mods and connecting to online servers, perhaps with a master server list setting included....



You have a point about people sometimes not reading the readme.... Though I'd think in general if they were downloading the zip files manually and unpacking them, they know what they are doing and would likely check the readme, or would just check the map folder and see what's there. Though the Quake Injector thing might bypass that? in which case, yeah, the user may not check the readme.

Though, in that case, there is the wonderful "Levels" menu in Mark V so they can run the included map (I really like menu, and feel it is the correct and best way to handle maps).


In regard to mods including autoexec.cfg, that actually seems like one of the best ways to handle it to me (even better than just having your map named start.bsp) for the very reason you mentioned, mh -- "the autoexec belongs to me."

Meaning I can edit the file easily to include or remove whatever settings I want. I don't mind the mod author putting his suggested settings in there, because, again, they are easy to change (assuming they don't commit the terrible sin of sticking the autoexec in a pak file, but that is rare).

It actually seems handy to me that the mod author would include an (easily editable) autoexec which will automatically start the intended map.



But yeah, I agree that it would be nice to have something for noobs built into Quake Injector for running mods/maps (if it doesn't already?), or just a new version of Qview with that functionality included, or just a new little stand-alone app (which would be pretty simple, really) that could run mods and/or maps with a few mouse clicks. 

Just a couple unrelated observations because I was starting up the Soul of Evil mod while testing the map running stuff. This mod uses its own start.bsp map.

I use an old version of Fitzquake (.85) for comparison, and I noticed two things:

1. Mark V is smart enough to not use the default start.lit file from my id1 folder.... Fitzquake does use that file, resulting in some... unusual colored lighting effects, heh. It doesn't look bad, it just look different, with strange colored lights splashing on the walls from no apparent source. But yeah, Mark V is probably correctly doing this.


2. Even upon first running the mod (by command line), so there would be no cfg files to read from in the mod folder, Mark V carries over some settings from id1. This can be good or not so good....

It doesn't seem to carry over the resolution settings -- that would actually be a good one to set....

It does carry over controls I have set up, which is good for basic movement controls, but not so good in that it keeps keys bound to aliases which are now no longer set (by the autoexec in id1).

It also grabs the settings I have made in the menu, including disabling the demo playing... and in this case that turns out to be bad, because the mod has a little "intro screen" demo that runs by default.



This is a tricky thing, because it's either "all or nothing" using the settings from id1 (or its hidden cfg file somewhere?) as the defaults in a case where you run a new mod... (weren't me and someone else complaining about that previously? heh).


On the one hand, it's handy to not have to set up your controls again, but on the other hand, generally you should be starting from scratch (with the actual Quake defaults) when you run a fresh mod (or delete your cfg file)....

Of course, knowledgeable users will have their basic keybindings in a separate cfg file which they can exec to set up all their default controls and preferred settings....

I think in this particular case, despite the user setting his id1 Quake to not run demos (because he's seen those 1000 times before), upon running a mod where the setting has not been previously made, the demos should default to play (it's actually an intentional part of this mod's experience).


Hm, yeah, this is tricky. There are good and not so good points about it... in which case I start to lean toward sticking to the default behavior (no cfg? default settings apply).

Perhaps there would be some middle ground where keyboard bindings were retained (not much problem with that), but default settings such as "play demos" are not taken from id1 when a new mod is ran. 

so the shadows(3) sometimes go through walls and floors. bug or a byproduct of the mentioned overdrawing by quake?

I could take SS if needed. For instance dead ogres on top of a bridge are casting shadows on the ceiling when you walk under. 

Bit of both.

It seems possible that this is related to the draw order, and I'm going to work out what the possible best compromise is.

Assuming it can be fixed it will be in one of Baker's spring updates. Until then you need to accept it as a choice between 2 imperfect shadow options.

I think this is the fifth time I've said this... :) 

sorry, i tried going through the whole thread and must have missed it.

Documentation is a little sparse, maybe I'd have a better idea of all these things if I checked the source. 

I thought I would raise this subject here because it seems like Mark V is one of the few engines currently under active development that isn't DarkPlaces.

What do people think about supporting lighting on water surfaces? Personally, I think it's a very nice visual effect and I'd quite like to see it in more engines *wink wink nudge nudge*. As far as I know compilers like ericw's tyrutils suite fork can support it, but I've never played with an engine that actually renders it...

Sorry if this has been brought up before. 

The other thing I thought of asking about is if it's possible to disable the Gamma Protector Clock? It makes my screens flash when it fights with f.lux. 

Go to video options and switch hardware gamma off? 

I'm currently using Mark V 1.20 (not sure if that's the latest version), there's only 4 options under Video Options - Resolution selection, Fullscreen on/off, and apply and test buttons. The only thing I've seen relating to gamma is the slider, but that doesn't sound like what you mean. 

That menu item was added in the current version, 1.36. You'll probably prefer the DX9 build over the traditional Open GL version since it is much faster (nearly 3x faster in many situations), but both are available. 

Woah, what happened to my framerate? I tried the dx9 build and it was fine, but the GL build tanked. I was getting a perfect 72 on my map before, but now I get something in the range of 22-23 fps with the standard mark_v.exe.

At least dx9 works. 

Also, r_waterripple is really cool, it's a shame about the seams though. 

Is another topic that pops up occasionally. I'd like to see support for it. May be tough due to the way water morphs and deforms though 

As far as I know light maps are blended after textures are drawn, so depending on where the textures are warped it wouldn't be too much of an issue? I'm not sure how the water warping is done though. 

lightmaps and textures use different UVs so in theory the lightmaps don't have to warp. 

Pritchard, gl_subdivide_size 32 should get rid of the ugly seams, if you're talking about what I think you are, related to r_waterripple.

Something to try which might improve frame rate (GL or otherwise):

r_mirroralpha 1

Using non-hardware gamma will also decrease FPS, unless the gamma and contrast sliders are all the way down (basically disabled).

r_shadows decreases my FPS, so if you happen to be using that setting, try disabling it. 

I was thinking....

So, Mark V keeps a (somewhat hidden?) backup config.cfg file to prevent bad things, such as other Quake engines blanking out a lot of settings and such.

This is both good and not so good....

The good part is obvious.

But it can be not so good for some situations, like if I WANT to blank out my settings in my FvF folder... (they just get re-loaded from somewhere), and like above where I noted that when you play a new mod for the first time, things like "disable demo playing" should certainly revert to its default value (play the demos).

So part of this behavior is taking away user control, and part of it is altering a default behavior that can sometimes be better to not alter.


Anyway, here's my suggestion:

Instead of using a hidden config.cfg file, just have Mark V create its OWN config file in the current game directory, perhaps named something like Mark_V_config.cfg

And Mark V will automatically load the standard config.cfg file, then after that load it's own Mark_V_Config.cfg file.

This is an improvement in my view, because:

- The Mark_V_config.cfg file is easily editable/deletable by the user.

- Mark_V_config.cfg settings will not be altered by another engine which messed with the config.cfg

- Loading that file after the config.cfg will mean Mark V's settings will override settings that other engines have made (or erased) in config.cfg


Mark V would still alter the standard config.cfg file (as is standard Quake behavior) so that any applicable changed settings will apply to other engines. Probably the special Mark_V_config.cfg file would be nothing but a duplicate of the standard config.cfg file... (which is probably functionally equivalent to your special backup config.cfg file, but it's stored in the same game directory now).

And if a new mod is ran which does not contain a config.cfg or Mark_V_config.cfg, then the default settings should be applied (such as playing demos).

If you wanna get fancy, then save all BASIC keybindings and aliases somewhere and let them carry over even if no config exists for a new mod.

Extra fancy would be some menu option for this -- "Save basic config settings," "load basic config settings," "always retain basic config settings," or something like that within the Customize Controls menu (though I know how much you hate extra menus).


Or perhaps some of this this might mean making another config file, much like R00k was suggesting in #1224 (which sounds like a great way to do it all around -- saving aliases and such automatically, and automatically switching to new configs when changing mod directories).

So Mark V could write it's Mark_V_config.cfg which is basically a backup of the config.cfg, and also a Mark_V_user.cfg which will always be written to id1 and read no matter what mod is ran, which will just contain basic key bindings and aliases which would be unlikely to change from mod to mod. Though the Mark_V_user.cfg from id1 should load first in case the user has set up special key bindings for a mod -- such settings would then be read from the gamedir config files and override the basic user controls.

Hm, then, of course, any key bindings made while playing a mod wouldn't carry back to the basic user settings stored in the Mark_V_user.cfg in id1, but that's actually correct behavior, in my view -- UNLESS the user uses that hypothetical menu option "Save basic config settings". Of course, if the user was just running id1, those settings would be saved automatically.


So... in summary, and in order of loading:

Mark_V_user.cfg (always in id1, contains key bindings and aliases, loaded every time even when running other gamedirs. Saved automatically if running id1, or by user selecting a "save config" option when he's running a mod)

config.cfg (standard function, for cross-engine compatibility when possible)

Mark_V_config.cfg (saved alongside the config.cfg in current game directory, backing up all Mark V settings and overriding settings that other engines made to config.cfg).


All files are easily user-accessible.

And like R00k suggested, configs should be automatically saved/loaded upon switching gamedirs. 

It would be better to discuss lit water after a couple of single player releases have the feature.

Would be proof that mappers will use the feature, that the compile tools work reliably, that another engine has achieved a stable implementation.

When these maps exist in the wild and after the rank-file can play these maps and potentially report/discuss issues in engines that current support them, it isn't out of the "idea stage".

Where are these maps?

Until they exist, from my perspective they exist this is the same as talking about leprechauns or the Loch Ness Monster. 

Methinks the reason for the absence of such maps is exactly the fact that there's no proper engine support.

Right now - what, Darkplaces has it? FTE, maybe? I'm not even sure. People don't work with advanced engines here. And it's not exactly the kind of feature that you could squeeze in as an optional bonus for special engines. It affects the way the level looks a bit too much. 

I would like to include lit water in my map - as far as I know doing so is as simple as setting a flag on my compiler. But it is a chicken-egg situation; I don't have any way to know how my map actually looks with such an effect, since I know of absolutely 0 engines which support it.

I'm sure you can imagine that authors may have reservations about releasing a project with something that is "maybe it works and looks good here, but I have no idea since I'm practically blind".

It's totally fair to not want to be the first/only engine with support for something, even if that is a little disappointing. I'm just concerned that someone will have to take the plunge with support, and given features like mirrors, I had hoped that Mark V might finally do it. 

the latest version of gl mark v runs really slow on ad_magna, while it ran fine on previous version that i had (mid december). dx9 version of the latest build runs it fine. what fps killing features did i miss previous month? 

Just checked, the DP dev build render lit water:
https://icculus.org/twilight/darkplaces/download.html

Add "-splitturb" to the tyrutils-ericw qbsp command line to get it. 

@pulsar - I guess I'll be double-checking the Open GL build come spring time to see if I did something that inadvertently caused a performance drop in Open GL. 

Lit water is one of those things that seems like a great idea until you go poking at all the edge cases.

Yes, I implemented it, saw what it looked like, and got rid of it.

I'm willing to add it to my DirectFitz thingy but please be aware of the following.

An engine can 100% reliably detect if a map has lit water.

An engine cannot 100% reliably detect if a map has not.

That's because a surface not having a lightmap doesn't mean that the surface isn't lit in Quake. It means that it's in total darkness. This is the kind of "let's save maybe 200 bytes per map" thing that matters when you're trying to run on an 8mb MS DOS machine but that causes untold pain and suffering later.

So a map with no lightmaps on water can mean one of two things: either the map doesn't have lit water (draw it fullbright) or the map does have lit water but the water is in total darkness (draw it with black lightmaps).

Do you light lava? Slime?

Do you add a warp effect to lightmaps? The lightmaps are a combination of (1) still, and (2) darkening the original texture, so the warp effect on the original texture is lessened.

What about translucent water? Darkening the water will make it appear more translucent. Maybe we should decide that because light goes through translucent water it doesn't get lit.

Should a map with unlit water still have dynamic lights added to it's water surfaces? And if so, is it OK that this would make the light seem brighter than on surrounding solid surfaces?

--------------

These are probably questions that people can't answer until they see it and start exploring around it. Like I said, I'm willing to add it to my D3D9 FitzQuake port if anyone wants it that badly, but don't expect it to be a 100% robust implementation at present. 

I'm not a mapper and am crap at and with tools, so I quickly added lit water to something else I'm working on, just so you can see what it actually looks like.

http://www.quaketastic.com/files/screen_shots/LITWater/e1m2_litwater.jpg

http://www.quaketastic.com/files/screen_shots/LITWater/e1m5_litwater.jpg

http://www.quaketastic.com/files/screen_shots/LITWater/e1m6_litwater.jpg

http://www.quaketastic.com/files/screen_shots/LITWater/e2m5_litwater.jpg

http://www.quaketastic.com/files/screen_shots/LITWater/e4m6_litwater.jpg