Sorry for the double-post, but here's a little bonus for the func_ crew. I've repackaged some Quoth maps from before there was Quoth - it's The Lost Chapters!

http://www.quaketastic.com/files/single_player/maps/chapters-pak.zip

As usual, save the pak to your hard disk then drag-and-drop onto launch.bat to play. This was surprisingly easy to port - all the necessary changes stemmed from renaming the hub to chapters.bsp. 

I thought there was a way to make direct to mdl using blender?? 

dude, using the console, I'm unable to launch half the maps from your pack :

chapter_secret,
chapter_esw,
chapter_ionous,
chapter_necros,
chapter_finale.

I can launch the other maps (using the console), while in the usual Quoth default start map. So WTF ?

And why are these superb maps (kell, vondur, zwei) not part of the official Quoth distribution ? There's only one map in Quoth ! W-T-F !? 

Renaming the chapters.pak to pak4.pak solved the issue. But what the hell with the name !? And I lost the path to the default Quoth start map and its nice default level. What gives ? 

you mean the hub map? preach says he renamed it to chapters.bsp 

Yeah, the pak's meant for the launcher, if you drag and drop it on launch.bat (new in 2.2!) then it "installs" the pak and loads the hub for you. You can do it the manual way as you saw, but you need to know one trick: the name of the pak tells you the name of the map to run.

PS: If anyone else would like to have their map added to the map paks page give me a shout. The 9 which are up there were maps that tested the feature best as they came with lots of added resources, but I'll add Chapters and any others people want to include in a "second wave" sometime soon. 

Now that it's able to "spawn awake". I tied it to func_rotate_train. Set targetname to the train and targetname2 to activate. Works!! I can move the spawning along the train route. Might be helpful for arena settings. 

hello, i tested quoth 2.2 with darkplaces engine and encountered one strange thing. everytime i walk my weapon is shaking a little. it's anoying as hell. everything is fine as long as i stay still, the moment i start to walk weapon starts to shake/jitter. it happens only during gameplay, weapons are ok during menu demo loop. i tested the last official dp version with the new quoth 2.2 as wel as with the last one and it's not engine related. qouth2 works just fine. any idea what may cause that? 

It's a darkplaces specific issue, you can read some posts from when I investigated it here:
http://www.celephais.net/board/view_thread.php?id=1&start=24308&end=24332

Essentially sv_gameplayfix_nogravityonground 1 is applied in Quoth 2.2 because it appears to make darkplaces behave more like standard engines in player to BSP-model collusions. The sliding issues I mentioned in that link have been fixed by the latest release, but as you have noticed there is a strange visual head-bob glitch. It seemed safer to release with a visual glitch that will likely be patched than with a gameplay glitch that's probably by design in the engine.

Two known fixes: run in a different engine, or add

sv_gameplayfix_nogravityonground 0

to your quoth.cfg file. Of course, the latter does mean you get the button-standing glitch back. It might also be possible to disable a bunch of the head-bob related cvars and have a stationary weapon, but I don't know which cvars it would take. 

i tried to turn off mentioned cvar and it works. thanks. it's quite confusing because these gameplayfix cvars have been an issue for a long time and lord havoc stated some time ago that he dissabled them all by default. apparently not this one. i set it to 0 and suddenly the game doesnt feel like snowboard simulator anymore. that's a good thing too. 

now i understand... sv_gameplayfix_nogravityonground is globally of, but you added that cvar into output.cfg in pak2.pak. i tested a few quoth maps and found no gameplay problems with that cvar set to 0. 

The specific issue it fixes is how often touch functions run on brush-based entities. In regular engines the touch functions run repeatedly, so you can trigger a floor button multiple times without stepping off it, and continually take damage from spinning blades etc. Without that cvar on darkplaces will only perform one press/deliver one tick of damage. This issue wasn't discovered in released maps but in some of the unit test maps I've made for discovering bugs. 

Quoth 2.2 crashes BJP's GLQuake?! 

be less specific? 

Quoth 2.2 crashes?! 

PR_LoadProgs9: statement 50737: bad opcode 80

This occurs when trying to load a map. Oddly enough, that weird new demo runs just fine. 

Easy to reproduce, it does it on my copy, it happens as soon as you load the mod. Ho hum. I know why it's happening as well, it's an issue that happened in some older versions of darkplaces. FTEQCC uses extended opcodes to make arrays faster in supported engines, coded so other engines never reach them. BJPQuake checks for invalid opcodes, and won't launch a mod if it find them, even though in this case they're entirely benign as they can't ever be reached.

Really this should only be a engine warning on load, because of this case where unsupported opcodes are locked behind a barrier only supporting engines unlock - it should only be fatal when the engine tries to execute the opcodes. Anyway, I've uploaded a fixed version of the 2.2 patch (I'm not gonna bump the version for this) where I compiled with the fast arrays feature turned off (since the arrays in question are of size 4 there really isn't any need for speed). Download http://www.quaketastic.com/files/single_player/mods/quoth2pt2patch.zip for working things.

PS: Spike, what's the command line to turn fast arrays off? I found it in the GUI but I'd like to add it to the build script instead... 

It's -Fno-fastarrays for reference. 

#pragma flag disable fastarrays 

Uploaded a minor update to the fgd file for better compatibility with GTKRadient. The fgd parser for GTK is a little stricter than the worldcraft one - the two crucial differences I've discovered are:

* PointClass, SolidClass and BaseClass are case-sensitive and must be written in CamelCase to work.
* It is not permitted to omit the description string which follows the classname for a PointClass or SolidClass entity. In worldcraft this is an optional entry.

So the new version of the fgd complies with these two rules. Does no harm but makes no difference for Hammer/Worldcraft users, lets you load it in GTKRadient. Note it appears you must jump through some hoops to get it working in GTK - I had to rename it halflife.fgd and place it in a folder called "valve". Plus a few of the .game file settings have to be copied exactly from the half-life .game file to get things to work.

I'm sure there was a way to convert fgd into a def or ent file, but can't seem to find it anywhere online... 

were not part of the fgd with trenchbroom, are they in this one? 

...but they would be very easy to add. On the other hand you hardly gain anything over just manually typing in func_detail, because it's an entity with no key values, just a classname. 

I get this message when opening WC3.3 using the latest Quoth2.2 .fgd

error parsing c:\.....\quoth2.fgd line 1166 expecting '=' but found '.'
error parsing c:\.....\quoth2.fgd line 1310 expecting identifier

Is it important or can i ignore it? 

Looks like there are some places where 3.4 is less fussy than 3.3. Both look easy to fix though, so I've uploaded a tweaked version. Give it a try and let me know if it sorts things! 

no messages this time.

Thanks for the instantaneous fix.