have the bomb in them it crashes when triggered

you have to use quoth1 for that 

There is a fix coming for that, but it might still be two/three weeks off. Which isn't to say that it's a hard bug to fix, the required change is there. I'm just making sure that everything is stable so there only needs to be one patch to sort everything out - and that has to wait until exams finish. As a freebie there will also be lots of performance improvement thrown in : - ). 

it is compatible 

your hubs dont save each map state, right? 

No, they don't. It was something that myself and Kell discussed as an idea for Part 3, but there are technical and conceptual hurdles to it. So it's unlikely to appear there either. 

check out FrikaC hub mod - it saves all the maps.
http://inside3d.com/frikbot/junk/hub.zip

2001 sheesh 

But the way that mod does it would break coop mode, for example. It also allows only one "saved" state on any given hub-system. So something more complicated would be needed. 

coop and folders - cant do that w/o engine mods afaik. 

Certainly you wouldn't be able to play hub maps in coop, it's out of the question without engine mods. What I was saying was that the way this patch does hubs would break playing existing maps in coop, and seeing as how quoth just got done putting lots of coop support into the mod, that seems unwise.

As for the folders thing, I was thinking more of a random/incremental prefix in front of each hub save file which would match within each playthrough. But like I say, it probably won't materialise. 

Thinking about the way these hubs work has put in mind of something. It would be really easy to make an autosave trigger for quake, where it would save upon touching/triggering it, and next time you died, pressing fire would load that rather than restart the level. If it doesn't make it into quoth, it's certainly something people might want to add to their own progs - especially if their map has one or two "first time unfair" moments. 

trigger_once stuffcmd save 'blah'
@playersart trigger_once stuffcmd 'load blah' 

what about the trigger than activate console commands (forgot the name)? Does that work?

I was thinking about trying to put an autosave point at the end of my map, but thought maybe it's a bit rude to do it in a game that doesn't have an autosave feature to save without the player's permission. 

You could use a trigger_command with message "save autosave" to save the game to autosave.sav. This would work well enough - although you might want to flag it NOT_IN_COOP. The problem would be loading it again - speedy's idea has a small problem.

The plan would be to have an info_command over the spawnpoint, which sends the message "load autosave". First time you touched it, the game would send you a warning telling you that autosave.sav couldn't be opened. This is a bit ugly but passable. Then when you hit an autosave the file is created, and next time you start the map then the trigger fires and the autosave would load.

The problem is that the autosave would load any time you restarted this map - whether you just died or not. You wouldn't be able to replay the map from the beginning without deleting the autosave from the directory manually. And if lots of maps started doing this, the autosaves might "collide", and starting one map would load an autosave from another.

You could add a slight contrivance, similar to the way that FMB_bdg allowed you to shut the music off. That would mean adding a func_button to the starting room for actually loading the savegame. It ought to have a trigger round it which tells you "press this button to load a past autosave". That's how I'd do it if I needed to do it, but I wouldn't recommend it.

One thing you certainly shouldn't do is replace the trigger_command for loading the autosave with info_command_spawn. I know it sounds like a perfect plan, you want the command to be sent as the player spawns, and that's what info_command_spawn is for! But...the other thing info_command_spawn does is resend the command when you load from a saved game. So you'll get trapped in a loop of loading the autosave constantly... 

is there any way you can do it with some info_player_start2 trickery? 

you could do the 'always autoload after initial spawn' with a trigger_once that triggers a not gate that then would trigger the load.

not gate = shooter, toggleable door and a shootable button 

that sounds even better! re-viving machines from systemshock :) 

metlslime: Just tested it out, but I don't think it's possible. info_player_start2 is used when the player has a sigil(serverflags set to something). If you pick up a rune in a level, and then die, you don't count as having serverflags when you restart. As far as I know, there's nothing that would persist from the previous state of the map when you restart after dying - it's indistinguishable from just reloading the map with "restart" or "map pr1sp1"(*). So what you need is something that loads the savegame before the restart, which is where the new code would come in.


(*) Actually, there is a recognised difference between these two seemingly identical commands when used in the console. "restart" will leave the console open, "map x" will close the console. Whether the console is open or closed at server spawn can make items drop out of levels. I don't think this difference has an effect here. 

bad name really. If anyone does this, I argue the save game should be named the same as the bsp to avoid any conflicts between different maps.

Also re: player_start2, I had some idea that it could be used to start in a different area of a map when starting a level that occured after a start map when the player found the nightmare exit. I assumed that it was related to the episodegate entity, but I guess that's just for printing text at the end, right? Still, I guess it could be done just by giving the player a rune before they enter the nightmare door 

Indeed, there is a difference.
However, items only drop out if they're placed incorrectly. The restart command also screws around with suspended items if they're done the regular way (func_wall -> killtarget on map start). Self-removing func_walls are unaffected. 

Where can I get all the mapping stuff for Quoth2? Like the .DEF files and all that jazz? I downloaded Quoth2 from Kell's site but the zips contain a few PAK files and that's it. 

 

No, I need a .DEF file like for QERadiant ... that's what ToeTag will read. I remember I got the Quoth 1 file from somewhere but can't remember where now. Quoth2 must have one, right? What did the FGD file get made from? :) 

I don't know of an existing .def for Quoth2. If anyone has one, please cough it up! :)

I keep meaning to make one myself, I was kind of hoping for the complete docs before I did so though (so I didn't miss any info or parameters). To the best of my knowledge the Quoth 2 mapping documentation is not fully complete yet?

I think that the WC/Hammer .FGD files are in a pretty different format (to .def files) but you may be able to get the information you need out of them with a little bit of screwing around.

I promise to deliver a .def, if and when I ever make one... ;) 

Blast.

OK, Ricky, do you have a complete FGD file for Quoth 2? If so, could you send it over to me (willem - wantonhubris)? I'll make a DEF file out of it if I can find the time. 

AFAIK there is no complete fgd file, I just edited the one I already had!

I dunno what def files are like but fgd's remind me of css files ;-P

Sorry I can't be of more help