Now I'll never have to type Chapter 15 of the "Horrors of DarkPlaces" again.

I'll just copy/paste that post ;-) 

Baker, I think you're misunderstanding me, I'm not really looking for a console command (well, except for the very speculative last bit). I'm looking for a command line switch. And it's not for combining arbitrary mods, it's for combining a map pack which knows it's adding onto AD onto the standard AD installation. I don't think there would be any compatibility issues because each "mod" higher up on the chain knows what to expect below it (AD knows to expect ID1 files, the map pack knows to expect AD and ID1 files).

It might even let you fix the issues that future versions of a mod break compatibility by adding the progs to the map pack, thereby freezing the version of the progs which the map pack uses (although on the flip side this means that you won't get bug fixes from future versions either). Quoth implements this feature already with a batch file that renames a pak file to add it to the path, so it's doable in practice. I'm just suggesting that being able to do this directly, and with directories instead, would be nice. 

half of baker's rant is about people messing up paks/pk3s, rather than gamedirs... I suspect half the reason he's complaining is because he has no idea how to get it working with his special-case 'hdfolder' hack.

Demos don't even come in to it, or at least no more than a multiplayer server. Users have had to use -game manually for a long time, simply adding another gamedir changes NOTHING in that regard.


Frankly, multiple gamedirs are fine if mod makers take the necessary precautions.

1) Always include a progs.dat in your map packs. This gives future-proofing.
2) Update news posts etc as appropriate whenever someone finds a bug in the underlaying mod that might affect your map pack.
3) For multiplayer, if a mod adds/removes/changes frames in a model, then the new version of the model needs to use a different filename (the old may or may not need to be distributed).
4) For single player, if you want to make it friendly, then provide/check for 'quothversion.txt' or whatever from qc to give a more helpful error when content is missing/outdated. Imho Baker is part of the problem if his engine(s) still don't allow this.
5) For multiplayer, always provide your content in pk3s. Each new version gets its own pk3. Clients that support downloads can then download compressed data instead of wasting bandwidth and time. Again, engines that don't support pk3s are imho part of the problem.
6) Avoid the use of default.cfg or quake.rc. Clients should not auto-download these, and if they come from a downloaded pk3 then they at least shouldn't be given full priveledges (like including a 'save pak0.pak' line), which causes a few sandboxing issues.

All it takes is some discipline (well, that and no custom defaults).

Nobody took it up though
fte+dp already support multiple -games from the commandline, and have done for quite some time:
-game basemod -game mappack
equivelent console command for fte (with 'hdfolder' equivelentsish):
gamedir "basemod;*hdbasemod;mappack;*hdmappack" 

6 great arguments against multiple gamedir support, really. If supporting something like that is going to require that much consistency from authors, there's no way it's going to work out well.

I mean, honestly! Updating news posts? Unique filenames for each version? Avoiding use of default.cfg/quake.RC? Very few developers have managed that level of professionalism or quality in their releases over the past 20 years.

And as much as the stated goal is to provide an easy way to load map packs from their own separate directory, I can't see what recourse an engine developer would have to stop people from using it with anything else. Maintaining a list of what's compatible and what's not is infeasible, so I imagine you could easily end up with strange cases of mods partially overriding other mods or just straight up crashing, just like Baker mentioned.

I'd like to be proven wrong on that point, though. I've never tried multigamedir in engines that support it so I'm curious as to how they solve or work around the problems of inappropriate use. 

That list of 6 requirements (NOT arguments) are things for mods with a specific base mod in mind, which is what Preach was talking about (according to #402).

But hey, lets all make multiple copies of AD. One complete copy for each map pack that depends upon it. Then we can get the quakeinjector/downloads to redownload it all multiple times.
Yes, that's a much better idea. Not. 

other than weird people who like Quake better when it has textures from a shitty Xbox-era game coated with a fresh coat of jizz? 

I didn't figure you as someone who would make this kind of derogatory comments, Lane. Funny thing is, the feature you're bashing DP for is the one that's also supported by QS, so I guess you should shit on QS too, just to be fair...

There's more to DP than hi-rez textures, like for example support for replacement models or a killer real-time lighting system. BTW, if you ever wander at QuakeOne.com, you'll see that a lot of quakers use DP. 

One of these days I'll buy you a drink and tell you about my last.fm days. 

I think I'm missing something in this whole discussion, sadly.
If we're releasing map packs for mods, which is what people are saying multigamedir would be best for, why would we actually need multigamedir? Map packs are just collections of .bsp, .lit and other files that can simply be plonked down into the /maps directory of a mod installation.

Or are we talking about map packs that are more than just map packs? So, sub-mods?

I ask because Spike mentions creating multiple copies of AD for various "map packs that depend on it", but so far that hasn't been necessary for releases that use AD in the past so... yeah. Confused. 

I don't take offence easily. And I am a bit weird... ;) 

the jizz would be the awful bump maping? ja!

- i dislike bump maping. in old games, in new games.
- i don't like the new dp particle, smoke and blood effects either.

+ i don't have problem with hd textures, though

- i remain unimpressed with RTlights

+ i like water reflections, dp have those right? pretty water and all that... i couldn't make it work.

+ i like seven's smc mod. well, half of the mod, but comes with a .cfg to disable things.


+ and i would bow and praise if i see actual realtime raytracing lightning coming from those bizantine mosaics.
+ or, more realistically, sun rays like those in stalker clear sky in the morning, but colored (and various colours!). those mosaics are begging for something like that 

why would we actually need multigamedir?
For cleanliness and ease of use? A new folder for each map pack would prevent the cluttering of the mod's \maps folder. 

omg, omg
i remembered

i didn't play tfuma, azad or magna yet!
omg, omg

i will record demo in skill 3. without deaths if possible, with quickloads instead of restarting the level if i die 

I do! Dp and fte support multiple game directories which I use all the time with no issues. Not to mention all of their other features, but having those features doesn't mean you have to turn them all on or turn up the "jizz". Whatever the hell that is to you...LOL 

Avoiding use of default.cfg/quake.RC? Very few developers have managed that level of professionalism or quality in their releases over the past 20 years.

Okay, so how do we provide our own settings while staying professional? 

It's not my criteria, don't ask me. A lot of people seem unhappy with the idea of you providing your own settings though... 

i thought quake.rc was the correct way to do it. autoexec.cfg and config.cfg are the ones that you should never include. 

Yeah I for one definitely vote for having multiple gamedir support in an engine as it gives so much freedom to the end user with regard to how he wishes to combine different gameplay mods, assets, and maps. I have been using this feature for years with DP, and since its development slowed down, I have picked up first QS then Mark_V but the multi gamedir support has always been what I miss most of DP, on par with multi folder mod directory support (e.g. DP.exe -game ./addon/czg07) 

Are you aware that LordHavoc is working on his engine again? Check the link in post #159 and download either the nightly autobuild or one of the 2016 betas. No, they're not in the Downloads section... Bonus: you'll get alpha-masked texture support, so these vines in AD will no longer look broken. 

using a default.cfg in a base mod that a map pack depends upon runs the risk of a user installing the map pack, and getting a config.cfg auto-saved from it when the base mod wasn't installed. Which means that the default.cfg still doesn't do anything when they do finally get the multiple games enabled.

In multiplayer, the client will not know that it needs to download a new default.cfg.


I'm not necessarily saying no default.cfg ever, rather I'm saying that any changed settings within the default.cfg will not always be usable.
Just be aware that custom default.cfg files won't always be execed, or might be execed after its settings were already saved into config.cfg

qss+fte have a customisable binds menu, which is one way for a user to fix things up if their prior config.cfg overrode newer defaults (an updated default.cfg might still rebind stuff if something was not previously bound, at least, just don't depend upon the user having no prior binding).

qss+dp+fte all support set+seta console commands to create custom cvars from eg default.cfg (as well as autocvars, in case the default.cfg was missing or the engine ignored set/seta). Such custom cvars won't exist in prior config.cfgs so they'll pick up their correct default once the correct default.cfg is installed. Not (ab)using temp1 means that its default value of 0 becomes irrelevant.

Imho the only valid use of a custom quake.rc is to change the auto-play demo list. any changes before config.cfg should be done by modifying the default.cfg instead, while any changes after override the user's settings and are thus user-hostile. 

Seasoned mod users delete the .cfgs shipped with a mod before even running it anyway, so they're basically useless. 

But it can bite you in the aft end if a mod binds custom impulses, so the truly seasoned just rename it, skim it for anything modspecific, the paste in their own cfg and add the mod binds as necessary. 

ad_azad
skill 3
37:11 ; 2/10 secrets ; 161/192 monsters ;; 3 deaths
so much for no dying
good architecture 2/10 secrets... those secrets are well hidden. i died the three times because of monster ambushes
i liked that section with those wood.. mmm.. scaffoldings... or whatever...
https://drive.google.com/open?id=0B72Jjyg-RfNFZGZUNkhoUWl2Njg 

I thought I should mention one of the main motivations for having some way of separating out the content that comes with a map from the content that comes with a mod. There is a benefit to neatness, and with that you get the ability to "uninstall" a map and its content cleanly. But the main benefit to my mind is to avoid conflicts.

Suppose that two maps released for AD both come with their own unique skybox, but by coincidence both name the skybox "dusk". If you just extract both maps directly into the AD folder, one skybox will overwrite the other. The direction of the lighting at dusk needs to match with the position of the sun in the skybox, so it's likely that one map now looks broken.

The same risk applies to external models, sounds, and other resources, and the important change that AD and Quoth make is that these custom resources can be loaded by a map without needing to create a new mod. As more people take advantage of the features, there is a greater need to bundle together the map and its own resources into a single package.

A pak file makes for a nice, easy to handle bundle, because it's all a single file (and pk3 has the bonus of compression). However, I think the gamedir has won the day because it has lower cost of creation, has the necessary engine support, and degrades gracefully - people who can't or don't want to use the feature can continue to extract the zip file into the base directory. Cheers Spike for making that happen, it's always fun when you ask for a feature and get equally forceful replies of "stop asking for that, it's impossible" and "stop asking for that, we did it ages ago"! 

If you just extract both maps directly into the AD folder, one skybox will overwrite the other. The direction of the lighting at dusk needs to match with the position of the sun in the skybox, so it's likely that one map now looks broken.

A bit of offtopic, but I'm glad people care about these things now. Some years ago developers small and big were seemingly unaware of the relationship between the shadows on the ground and that weird bright spot in the sky.

Attaching a lens flare effect to the latter - sure, looks purdy. Shadows are pointing towards the sun - uhhh, so what?