I think it's more a limitation of how the physics simulation is designed.

Spike was saying that the results of physics after one 72fps timeslice can be different than after two 144fps timeslices. 

Is there a way to allow QC to refer to gfx.wad textures by name for certain "slots" in the hud inventory?

No. 

The HUD is absolutely and totally hardcoded into the engine.

DarkPlaces, FTE give you additional options (csqc). I don't believe Spiked Quakespasm has any csqc support.

I think with csqc you need to self-draw the HUD. Nahuel at QuakeOne had a open source implementation of a CSQC HUD.

http://www.mediafire.com/download/3tzacatwdazo4r6/HUD_v4.81_Nahuel_Dresk_Smith.zip

http://quakeone.com/forum/quake-mod-releases/finished-works/10604-csqc-hud-v4-8-rt-lights-edit-tool

http://forums.insideqc.com/viewforum.php?f=16

Providing information only so you can decide on options, altering the HUD is impossible in vanilla Quake.

If you were to make a CSQC custom HUD, it could work for DarkPlaces/FTE and other engines would simply ignore the csqc progs.dat just use the regular HUD. 

I have a small request, please bring back m_filter. 

I've done my own dragndrop csqc inventory before. I'd prefer a simpler method, but alas oh well. 

Hey all, I've never posted on a forum or anything before but I'm seeking some help.

I was just wondering if there was ANY possible way to get back the funny quit messages from vanilla or DarkPlaces in QS. I know enabling "-fitz" in the shortcut gives you the credits box, but its bothering me far more than it should that the original quit messages are seemingly gone in this port.

Any help would me appreciated, thanks 

I've added the 'cask' for the 'homebrew' package manager on macos, now you can install the client from the command line:

1) install homebrew: /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
2) install homebrew-cask: brew tap caskroom/cask
3) install quakespasm: brew cask install quakespasm
4) put pak0.pak and pak1.pak into /Applications/QuakeSpasm/id1
5) enjoy 

Model skins in some mods are corrupted, appearing half blue, half black. In particular, gib skins in Shrak and tarbabies in Arcanum. This is an old GLQuake bug which is fixed in Bengt Jardrup's Enhanced GLQuake, DarkPlaces, Mark V etc. 

This bug was present in earlier versions of Mark V, I found it reported here:

http://www.celephais.net/board/view_thread.php?id=60831&start=826&end=850

I suppose, Baker can help you fix it. 

That the blacknblue checker is indicative of a mod trying to use a skin that doesn't exist. This is most notable with gibs if they are coded to 'inherit' the skin of the monster being gibbed when the gib model only has one skin.

Which mod did you see this on and what model? 

The corruption doesn't happen with Mark V or Darkplaces running exactly the same installation of Quake. Here's how you can check this:

Grab the mods here:
https://www.quaddicted.com/files/commercial/Shrak2.7z
https://www.quaddicted.com/filebase/arcanum.zip

In Shrak just start the first level and kill one of the shotgun enemies (input "impulse 255" in the console to get Quad Damage so that you can easily gib them), their head gib is affected.

In Arcanum go to map arcanum5. You'll see the tarbabies right at the start. 

But maybe the other engines default to skin 0 if the skin is not present? 

for arcanum5, I think you missed an install step; you need to install arcanum on top of drake. The monsters at the start should be spiders, not tarbabies.

In shrak, I see the blue checkerboard on the gibs. It's a feature inherited from fitzquake, I guess the intention was for modders to notice invalid mdl skins.
It looks like MarkV is displaying skin 0 instead of the checkerboard for compatibility with mods like shrak that set invalid skins. 

Oh man, totally missed that part about installing Drake. Guess I got a bit careless when playtesting so many map packs. Still though, the tarbabies don't get the checkerboard pattern in the other engines.

I suppose you could change it to display skin 0 when developer is set to 0, this way it would accommodate both players and modders. Backwards compatibility with old content is pretty important, especially in this decade that's so heavy on the 90's nostalgia.

Just my two cents, is all. 

Oh, and one more thing. In vanilla GLQuake the gib skins in Shrak are completely white, while they show up just fine in WinQuake (and supposedly DOS Quake as well). It's definitely some old GLQuake quirk. 

I was the one that at added the blue checkerboard feature. I didn't realize at the time how many mods relied on the behavior of vanilla quake to show skin 0 when the mod asks for an invalid skin. So I now agree, the engine should replicate vanilla quake's permissive behavior and maybe just put up a non-spamy console warning when the bad skin is first set. 

Glad that I could help. Here's a couple more oddities that I've come across:

- r_wateralpha < 1 results in various see through glitches on non water VISed maps, like e.g. qte1m2 in Travail. Other engines seem to ignore r_wateralpha if the current map is not water VISed, I'd prefer such behavior.

- Console font sometimes has a thin underline/overline with some characters, no matter what value scr_conscale is set to.

- Water textures are not mipmapped and thus look pixelated at distance. 

•Missing skin: console warning and checkered texture
•Missing sound: console warning
•Missing model: CRASH to desktop! You lose.

Couldn't this also just be a console warning and remove the entity? 

well... we could play a checkerboard sound for missing sounds. Like a horn honking or something. 

play the Wilhelm scream 

 

Har har 

Is there a console command in QuakeSpasm similar to sv_gameplayfix_nogravityonground in Darkplaces? I'm experiencing something called the sliding effect on my setup; it's basically when the player slides forward a small distance before coming to a full stop. AFAIK it is how the Quake engine behaves on modern hardware so the issue persists with all ports faithful to vanilla Quake (FitzQuake, QS etc). My workaround is setting sv_stopspeed to 200 (def 100) but I wonder if that has any effect on player movement (jumping etc). Is there a workaround? Could it be input-related? 

Isn't that just normal Quake physics momentum at work? Not sure I understand what you're describing. 

Not really because it looks like I'm walking on ice or some other low-friction surface rather than the ground. Moreover it reduces the precision of player control when navigating ledges, lifts etc. I don't see this when watching other people's demo runs.