That's the one, thanks mankrip 

Hmmmm, doesn't work. Seems to be trying to load quick.sav which doesn't exist. 

Put a "wait;" command between both commands, it should work.

Also, it will only work when you open the save menu by pressing F2. It won't work when the save menu is opened from the main menu. 

It keeps accessing quick.sav
I'm using QuakeSpasm 0.93 

bind F2 "save quick;menu_save"

works for me in Quakespasm.

Do any Quake engines have a command for "load the most recent save"? I don't know of any. 

yes that works, thanks ericw and mankrip. 

And just hitting F6 to quicksave, then F9 to quick load? 

The difference is minimal, but if it doesn't hurt anything, there's no need to be against it.

The savegame subsystem in Quake is something that could be vastly improved, in both usability and robustness. But most people don't care. 

Not a whole lot, just thought there was a way to "quickload" most recent save by hitting fire instead of F9. By default when you die, hitting fire loads the start of the level. Would be nice if this loaded the last hard save as I don't use F6/F9. Habit :) 

any news on your map pak 

https://youtu.be/bLWGIYYEKfg 

I'm just sort of building stuff with the idea of it all being part of some full-length adventure game using modern quake engine tech, not really quake levels.

No imminent release date I'm afraid :} 

After the Wikia debacle and other transgressions, you'll have to release a Quake version to appease the Quake gods (Vondur)! 

I was always aware that the chances of such a project going tits up are pretty high, so I am deliberately designing all the content in such a way so that if the aforementioned tits were to assume a vertical trajectory, then most of the stuff can be minimally reworked and released as Quake content without everything being lost. 

No imminent release date I'm afraid :}

gotta wait, anyway 

I suppose it depends on if your project is a cow or a woman.

Either way, finish someday. 

Spam. 

 

seeing some screenshots of a cream colour like map, but don´t remember if it was coloured lighting or not or if it was released.

It the colour is more subtle you could go just with coloured lighting. The effect is good, just check the exterior of my jam 2 map. 

Or I'll tan-ify it and make an iktan.wad for those desert persian arabic palaces. 

eventually IKBlue will be converted to all colors in the quake palette. IKPurple, IKGrey, IKFullbrightRow... 

up to two progs.dat files simultaneously, is it possible to modify Q engine to make it support a multiple progs.dat files

progs.dat
progs2.dat
progs3.dat etc 

How hard is to make an IK red? And more importantly, how hard is to make the same change in all the textures so they stay coherent? I always wanted to learn to make textures and this seems like it could be an easy thing to try, but would like to know in advance. 

hexen2's maplist.txt file gives a mapname->datname lookup. This particular mechanism sucks on account of conflicts over which version of the maplist.txt file to use (as FTE can run hexen2, it also supports this feature with quake, but don't expect any other quake engine to also support it).

Its more normal for engines to have some cvar to control which .dat to use, typically named sv_progs if it exists, but could have some other name.
This also sucks. A series of maps that need a specific .dat will need the qc to figure out which one is meant to be used and thereby switch accordingly using map restarts or some other ugly mechanism.
It would be better if the engine were to figure it out based on some worldspawn field, but then which one takes precidence - the field or the cvar?

but seriously, why exactly do you want multiple dats? are you having issues with the max_regs limit of 65536? its worth noting that once hexen2's hcc compiler started optimising things properly, they ditched the whole progs2 thing with their mission pack, for good reason.

If you're after mutators/addons or some such, then FTE does support those, but the vanilla gamecode has conditionals for things in unrelated areas - for instance making a new monster is far more messy than it should be if only due to ClientObiturary using hardcoded strings for when said 'non-existant' monster kills you. I'm sure you can see the problem. You can add in all sorts of hacks to wrap functions etc, but frankly its not really worth it.

Note that fteqcc's #merge feature allows wrapping an existing mod in a similar way, and without needing any engine changes. This gives a way to still quickly adapt many mods and to do so in a slightly more robust way (as your users won't inadvertantly end up trying to apply your mutator to eg quakerally).