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. 

Just noticed this: load kellbase1.bsp, and noclip to the orange room with the water pool, just behind the info_player_start. Kill one of the pyro enforcers.

DP spams the console with: "WriteDest: Tried to write to non-client"
Fitz 0.85 and QS freeze for a second and then drop you at the console with this:
CALL2 596(WriteByte)()
: centerprint
: centerprint_toall
: counter_use
: SUB_UseTargets
: monster_death_use
: Killed
: T_Damage
: T_PlasmaTouch
<NO FUNCTION>
WriteDest: not a client
Host_Error: Program error
Client ericw removed

This is on quoth 2.2. 

Hi ericw. The log from the console tells me that the pyro is killed, the trigger_counter bumps the numbers, tries to broadcast the message to all players, picks an entity to broadcast to, and then crashes. The error is that the entity picked was not a player, and sending the message to a non-player is a no-no in Quake. However, there is already code which is meant to limit the messages to players, and I can't replicate the crash here with any of those engines.

If it's consistently replicable at your end, can you make a save game before you crash the game, and e-mail me that save game and your config.cfg/autoexec.cfg files, so I can see about fixing it. 

It turns out I was downloading quoth2pt2full.zip which had an older (2014) pak2.pak than quoth2pt2patch.zip (2015).

Preach updated both the full and patch zips (thanks!), so you may want to download the patch if your pak2.pak is modified in 2014. 

Ooh, I didn't know that. I have the full version so I'd better check it out. 

No wonder I had so much trouble with the last jam. 

Umm, you mean map jam 7, I suppose? The last one runs in AD. 

Someone just told me that doing -game warpspasm -quoth doesn't play the startdemos.

I know this wasn't on purpose.

I wonder if there are any other standalone-like releases like The Living End or such that are also impacted.

I'm just raising awareness of the change of behavior.

/I will probably have Mark V block loading of Quoth 2.2 pak2.pak (just have it load up pak0 and pak1) for Warpspasm eventually, since you implemented a very organized structure for falling back to the previous version.