that they have too much health!
They should be one shot -> dead enemies.
Sigh. 

You can make a map that looks and feels 100% like pure Quake, but still uses Quoth. It is totally transparent. The monsters are optional. It's kind of a honeymoon phase where everyone overuses them, but that will go away.

Transparent functions that I think are very nice to have would include the spawning, hub system, screenshake, breakables, rotateables, ladders, longtorches, info_multispawn (aka func_hordespawn), buttons that travel with lifts, new traps, sound players, console command entity, enhancements to existing entities, forcefields, monsters dropping keys... you name it...

all that in a neat package... although I would like to see most of the monsters split off into their own pak file... so you have a base Quoth, containing just the progs, plus what's required for breakables etc, plus some models and sprites (trees etc) plus signature monsters (voreling, rocketeer.)

The benefit would be that it would be a much smaller download. Quoth Lite?

Monsters' HP have been drastically reduced already, you should have seen the beta Sentinel, or beta Edie.

Vorelings are OK IMO, the problem is that they're still overused (groups of them) without appropriate firepower given. A nailgun is enough against a small group, SNG/GL is IMO required for larger groups.

Concerning Quake sounds, it is possible to substitute them with Creative Commons licensed samples (plus self-made voice acting), but it's true that some sounds are so unique that players wouldn't want to miss them. That is a general problem with replacements, players are going to warez the original instead because it will almost certainly be better.

give me 600 dollars and I'll buy a copy of the General collection (where most of them come from) and assemble a pak. But I don't know how legal it would be to distribute them along a GPL Quake replacement.

Quoth sounds, let's not go there. Nobody guarantees that they're royalty free. Modified id skins, models... same goes for knave.wad, do you honestly see no modified id textures in there? Look again...

You can have the first episode plus a modern engine for free already, in Gentoo it's as simple as

emerge ezquake-bin quake1-demodata

and there you go... more engines are on their way into the various package managers every day...

and there are warsow, nexuiz, alienarena, quake2-demodata (you can play online with just the q2 demo plus latest patch), quakedoomblah-demo, doom1/2 shareware, rtcw, cube/sauer, AA...

linux/bsd users have access to hours and hours of free fps games and modern engines already.

look @ www.happypenguin.org.

needless to say, a free original Quake at least covering online gaming (= you can get on a normal server with it) would indeed increase Quake's popularity.

Id could release a patch that upgrades the shareware to a standard-multiplayer-capable version, like Quake 2... 

Is Quoth 2 fully compatible with Quoth 1 maps?

I don't care about save game files, I just means do the maps work fine with it? 

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? :)