Sub-folders ...

[Baker]

Once upon a time, I was all for the mindset that screenshots should go to gamedir/screenshots, AVIs to gamedir/video and such. Nice little tidy places for everything.

And in fact, I wonder if the idea of splitting everything into folders (EXCEPT NATIVE GAME CONTENT) isn't possibly the stupidest idea ever.

The *only* rational behind folderitis is being able to see select content easily. Why not sort by file type in Explorer or whatever file manager your operating system uses?

The first time I because anti-folderitis was when I realized that with replacement textures, modern Quakeworld engines -- which have a folder for every damn thing, you can't remember what the folder name for something is. Why should .lits have a folder? Even in multiplayer NetQuake, why should .locs have a folder.

Why do .mdl replacement textures in a modern QW or JoeQuake/Qrack go in textures\models ? .lit files are extra data for maps, they should go in the maps folder with the maps. .loc files are extra data for the maps, they should go with the maps.

Modern Quakeworld has too much history and content that depends on all of this to ever change, but I'm more point out that as any kind of standard it is wrong.

What made me think of this, is that I playing Travail with ZQuake to think about Quakeworld physics. And I saved my game.

I loaded up an NQ engine to play some Travail and tried to load that game. It said file not found, but I knew I saved it.

ZQuake saved the game into "travail/saves" folder

(FitzQuake also could load the save game, said something like "This is version 6 save game, not version 5". Honestly, I didn't have any idea save games have versions or a wrong format mechanism --- which is nice and offers hope. I might have been using DirectQ and not FitzQuake.)

[taniwha]

Actually, I got rather fed-up with screenshots getting scattered all over my quake dir, and now QF puts them all into $quakedir/QF (id1 would be $quakedir/id1). QF actually looks for stuff in the QF "gamedir", but even id1 overrides it.

Two reasons I got fed-up: finding the damn shot; overlapping screenshot numbers (still get that because I think the sw renderers still do pcx instead of png, but I rarely use them).

Now that I've got demo type auto-detection mostly working (I run into oddball "formats" sometimes (caused by proxies, demo tools, etc), I might even send demos there.

QF currently uses a rather different save format (but still reads the old), but still writes to the same place. I should probably make that configurable (using gamedir.conf rather than cvars).

Actually, come to think of it, I should probably make the screenshot/demo/etc destination gamedir.conf controllable, then put the default back to $gamedir.

[Baker]

Two reasons I got fed-up: finding the damn shot; overlapping screenshot numbers (still get that because I think the sw renderers still do pcx instead of png, but I rarely use them).

There isn't a good reason for software renderers using PCX and not TGA in modern times. I think DOS was VGA 320 x 200 - 256 color so I could see quake.exe doing PCX since someone might not have any kind of screenshot viewer that could display rgba. But WinQuake? You'd have to have Windows. Not sure why to make GLQuake do TGA and WinQuake do PCX.

Screenshots and AVI captures are exceptions in that they aren't Quake-dependent in any way and throwing them all in a single place is probably the right thing to do.

QF currently uses a rather different save format (but still reads the old), but still writes to the same place. I should probably make that configurable (using gamedir.conf rather than cvars).

I'd like to see some "improved savegame solution". Yet at the same time, I suppose save games being done "right" for anything except nearly classic single player types of games is probably futile.

[Spike]

software renderers using tga is pointless.
tga images are a real pain to open for most users (which is why many engines use jpg/png instead nowadays).
pcx retains the exact palette, so is about a third of the size of a tga, and is easier to open (as windows paint supports it directly, but still does not support tga).
when taking screenshots, fte at least gives the full system path for the new file instead of merely the quake-relative path. this is especially important when home directories in windows are used.

fte has had its own saved game format for a while now. its pretty much completely different there. being quakeworld its all from-scratch anyway, but the ability to save q2+h2 hubs requires significant differences - q2 specifically requires a separate file for each visited map.
I could have special-cased it, but I didn't.
multiplayer saved games is another perk.
either way, its important to know which progs.dat was used. there's a lot of things nowadays that need to be preserved to make a viable saved game (temp1 etc).

the 1001 different texture directories are painful with quakeworld, yes. for the most part it provides some way around the texture extensions issues, giving sprites/models separate namespaces.
directories for specific maps allows map-specific textures.
but I really don't get the need for the 'exmx' dir or whatever it was.
its hard to not support them without people claiming 'amg it doesn't even support replacement textures'. grr.

[taniwha]

I stopped writing to tga because even linux viewers have trouble with it . Despair and I went to a lot of trouble to give QF a fast (quake's original tga reader was painfully slow) and spec complete tga reader. Probably one of the few around :/

[mh]

Screenshot names can potentially conflict with texture names so some degree of separation is needed. I personally like having everything in subdirs, so that I can more easily clean the install and get back to a fresh id1 if needed. I'm not a fan of too much separation though and agree that .lit and .loc files belong with maps.

Generally the way I handle my loaders is that I have a cvar-ized subdir (which I'm slightly nervy about - I do run some sanity checking on it but I think it goes a little too far beyond what's reasonable in letting the player decide) and if a load from there fails I fall back on the gamedir root. That only applies to saves, demos, etc, of course (textures, maps, other game content - as opposed to user content - have fixed locations). So if I fail to load save/s0.sav I'll try just s0.sav before giving up.

I think the separation of content into "game content" and "user content" is important here. User content is stuff that's generated by the user as a result of explicit action, and also includes .cfg files. So it includes new demos, screenshots, saves, etc. Game content is stuff that either ships with the game or is generated as a one-time-only op by the engine and that the user generally doesn't ever need to touch (GLQuake's .ms2 files - yuck - would also fit into category).

Separate namespaces for sprites and models are important - don't forget that id's pak0.pak has progs/s_light.spr and progs/s_light.mdl - if you're not handling this then you've failed.

[r00k]

Create cvars for each folder name and let the user modify the defaults to their needs.

[mh]

...and if the user changes it to "..\..\windows\system32" you're in trouble...

[Spike]

Oh, I wouldn't worry about the user doing that.
I'd worry about the server doing it.

[mankrip]

Using a subdir for user-created files could be a good thing, as it would also allow for faster cleaning of the file tree when packaging a mod for release.

If all saves, screenshots, user-generated demos, config.cfg and stuff like that were saved to a "user" subdir, it would be just a matter of removing all files from that folder prior to releasing the mod.

As for files that aren't modified during gameplay, I think their hierarchy should be up to the author of the mod. Some people works faster using a single folder, while others works faster using multiple folders.