Nobody took it up though

The multi-gamedir concept is an extraordinarily sloppy concept and requires someone to be unfamiliar with the Quake precache system, unfamiliar with what Carmack did in Quake 2 and Quake 3 and what Value did with Half-Life and what Zoid did with Quakeworld for downloading.

The Quake precache system, including the QuakeC part is hostile to the idea of this concept. So is the demo system. Where is the information in QuakeC that indicates the source of a file? Or in demo playback.

The idea only sounds great to someone who isn't thinking about co-op, doesn't ever use an engine that supports map/model download and doesn't ever do multiplayer.

Have you ever connected to a DarkPlaces or Quakeworld coop server and watched it download the maps and models and then you play?

Is your plan to break that type of functionality?

Furthermore, how many mods ever reach a completion state to be trustable for multi-gamedir?

Answer: Not even Quoth.

Quoth updates frequently alter map author's maps in ways not necessarily wanted by the authors of the maps (I believe Negke and RickyT23 are examples. I had a complaint about a behavioral change that affects Warpspasm).

So hipnotic and rogue are "safe", but in large part because they have been undeveloped for 20 years.

Quoth has largely been safe because there were 6 years between the update in 2008 and the one 2014.

Furthermore, the Quake Injector doesn't support it and many people depend on it to play maps.

And even if it did, it introduces an extremely fragile and spaghetti-like relationship between mods. Ask any who has tried to use multiple content replacement paks in DarkPlaces how easy it is figure it out when things go very badly.

Perhaps gamedir has a brushmodel and a replacement texture for it, perhaps gamedir b has a brushmodel and no replacement texture for it. You will get the lovely combination of the a model getting a wrong replacement texture being used. This is just a trivial example.

Add to that!

PHYSICS

FitzQuake 0.85 introduced physics being affected by model dimensions. The actual gameplay of a mod can change if the wrong model or even a different model is used.

Multi-gamedir is a huge attack on:

1) Compatibility
2) Predictability
3) Author's intent
4) The engine being able to accurate assess exactly what the required content is
5) Communicating that to the client.
6) Introduces a whole new level of fragility where mods are now co-dependent and can break one another with the slightly change.

A few years ago you were the one with a creative comparison of numerous DarkPlaces incompatibilities and comparing it to Internet Explorer 6. It caused some changes to DarkPlaces to occcur to at least be more predictable and far less mod breaking in the default behavior.

But what you are suggesting is even worse.

You aren't making this terrible suggestion on purpose, I know ...

But rather you are making this terrible suggestion from a lack of diversity --- the tragedy of your idea is easily witnessed in wild with DarkPlaces pk3 support and replacement content and users crying for help saying "I want A to work with B" or "I want this progs to work with this content".

/All of the weaknesses and tragedies of multigame dir support are hiding in plain sight in reading DarkPlaces related posts in the QuakeOne forums.

It doesn't take reading more than 4 or 5 posts related to use of multiple pk3 or multiple gamedir content conflicts with DarkPlaces to get a quick handle of true horrors ... 

https://youtu.be/mAUY1J8KizU 

just got PREKT 

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.