Intermap travel thought ...

[Baker]

Intermap travel ends up being a bit messy because you have to create folders for everything, right?

Well ... no. That's sloppy. Writing a pak file is a perfectly simple thing (all the functions needed to do so are in The utility itself has some kinks, but the pak writing code ... if I recall ... works flawlessly by itself).

There is only one "game state" for any given level, therefore throw one save game into the pak file per applicable map (I wrote functions for delete, add, compress pak ... delete doesn't actually delete a file, just nukes the directory entry, so compress recovers space. Which you do, say, randomly ever 5th time you save a pak, since compressing can be a bit slow.)

And the use of an independent pak wouldn't have to be part of the "Quake file system". You could store the pak somewhere Quake won't look for it, like in "saves" or with a name that standard Quake isn't looking for (i.e. don't name it pakx.pak). The pak read/write capability in the above source has a way to get the file offset and the file length of a file in a pak, that can be used to read a file in it without it being part of the Quake file system.

So saves could be like save1.pak sitting in quake\id1 --- although then DarkPlaces or something might try to read it so if you aren't doing a total conversion and worry about that --- have it in quake\id1\saves. Or name it quake\id1\save01.savpk as the code doesn't care about the extension.

Blue sky thought that I won't be acting on any time soon, but was trying to think of how to handle multi-map travel.

[p.s. one fun thing about writing pak source code, you could change it a bit like so the header doesn't have, say, "PACK". And then for most mortals, they'd never be able to figure out a way to --- say --- see what maps are available if you chose to use it in that way. Why would you care? Well, let's say you make a single player map episode and want people to have to play them and disallow the idea of loading up maps they haven't "earned the right to play". But wait, "they can cheat anyway!" --- well, if you have customized the engine and made it so it loads a non-conforming pak, you could change it so cheats only work with -developer in the command line and few people are going to look through your engine source to think of that.]

I'm just saying that in a lot of console games, for instance, you can't cheat and ruin the experience of playing a game by typing "map end" in the console. In Quake, I kinda of wonder if things aren't in many ways "ruined" by easy accessibility of cheating and/or bypassing tough spots by typing a map name in the console. So you don't have to play through something to get the "reward" of seeing a map that you saw in a screenshot, for instance.

/End of book-long post on blue sky thinking ...

[Spike]

by 'intermap travel', I assume you mean a hub system like hexen2/quake2/halflife.

the only thing you'd need to constantly rewrite anything is for the current game. saved games are just a copy of the current game. Note that you should either have two copies of the current map, or the 'restart' command should reload the saved game (note how q2 shows a load-game menu should you die, likely to avoid this).

saved games on disk are merely a copy of all the active map state. Whether they're thrown into the .sav as separate nested chunks, stored in separate files within a separate directory, or stored as separate files within a pak. None of that really matters as the saved game will be created from scratch every time you re-save the game.
You can leave stray files lying around, but that's laziness/deletion-paranoia rather than an actually useful feature.

For *current* gamestate, sure, use an updatable pak file if you really want. Easier to just use separate files. There's no fantastic gain from either. Separate files in some temporary directory is simpler and thus less likely to be buggy. Or you could store the whole lot in memory.

You might want to look at RMQe, which features a fairly simple hub system. The QC control of it is compatible with FTE too.

[Baker]

[metlslime]

[goldenboy]

In the RMQ svn, using the latest windows binary of the engine in there (or recent FTE), load up hubtest1.bsp.

[taniwha]

metlslime: neither - nor ~ should break stuffcmd. However, neither one would do the job. First, there's quoting: nq-x11 +map '"-mapname"'. Then, there's the fact ~ doen't toggle the console for me (I have a Japanese keyboard and I taught QF to use hankaku/zenkaku (same place as ~ on US keyboards) instead).

[metlslime]