Is gooning with the player physics not a crossing a bit of a red line? 

Yes, I was thinking that too. But the reason why I choose to mention this is cause I don't think that would be crossing the line, this small specific "fix".

I can see if even more things were added, like double jump, ledge leaps, etc etc.
I think Id added this small thing so you wouldn't get stuck as easy when jumping too close to something.

Actually, I'm not sure what the difference really is, I mean, it's not like you are jumping close to a ledge in Q3 and magically just appear on top of it, but in Q3 you can jump around in stairs and not get stuck. 

it's not like you are jumping close to a ledge in Q3 and magically just appear on top of it

Not sure if it is related but q3dm13 mh? 

Maybe you are right, can't try it now.
In any case, it's not an issue in Q3 afaik =) 

makes it harder to run some maps 

is a little twitchy. I personally hate that a floor connected to a slope will often stop you dead as you transition onto the slope. It's like there is a forcefield stopping you. 

In quake2 and darkplaces you can do this, i think in darkplaces it's called "air step." It's a nice feature because you won't get snagged on things like running across the floor grates in dm4.

I added it to Fitzquake early on, but deleted it before releasing because I realized it changes gameplay too much. The player can jump onto much higher crates with the feature -- ~40 without the fix, ~56 with the fix. Of course it's tunable, but the lower you tune it the less beneficial it is. 

Fifth, I noticed that in ad_zendar, when you climb the bricks at the start and go up the slope, there is an invisible wall blocking you at the top of the slope. It doesn't happen in DarkPlaces though - maybe LH fixed a bug in the collision code.

QS probably errs on the side of leaving everything vanilla; touching physics can have unintended side effects like metl mentioned. 

modern quakeworld servers have airstep enabled via the pm_airstep cvar.
even small airsteps of 1 or so should help work around the invisible barriers issue that results from bsp hull precision (tbh I don't actually remember quakeworld ever having that problem).

you could also only allow it when near to the ground which would fix steps (but also mean people could bunnyhop far too easily) without making ledges too easy.
that bunnyhop thing is why its not enabled by default in fte. I believe it is enabled by default in dp. 

I try my best to avoid using ramps in my maps specifically for this reason. I fudged the ramps in q-deck by having a "lip" to prevent getting caught when moving down the ramp. 

...this small specific "fix"...this small thing...

First rule of engine coding is that what may seem to be a small thing from a player's perspective quite often isn't.

Second rule is that this applies doubly so when it comes to the physics code.

Anything involving Quake physics code is almost definitely not a "small fix". It may seem small to you because you're just describing one single problem that only seems (to you) to happen in certain very specific circumstances. But the physics code has ways of blowing up spectacularly and innocuous-seeming changes in one place can have huge repercussions elsewhere. 

Go to E1M1 quad secret area. Stand under the screen with the world on it. Lower gravity a little. Jump. In a normal engine, you'll hit your head on nothing. In DarkPlaces you will jump unimpeded.

It is odd. 

That's a trigger_multiple with "health" "1". I guess it's solid? 

What is weird is load up ezQuake and -- like DarkPlaces --- you won't hit your head on the invisible trigger.

Go figure ...

So normal Quake = it is there.
Quakeworld/DarkPlaces = it is not there. 

Hey, I've been learning to play with bots in Q1 and it's come to my attention that compatibility with some bots is borked in QS.

Frogbots seem to be the best bots around but sadly they're one of the bots that don't work. Frogbots work fine in Fitz et cetera

Is it possible to add support back in to QS?

PS: The Xinput support is a godsend for my tired old wrist! Thank you. :) 

"Couldn't find a cdrip for track 0" the console tells me.

happens in aop, and in some custom maps like teacups. playback works fine *most* the time(?) so i am at a loss.

hoping this is just a case of operator error.

using win7 and the xinput build of qspasm. 

I just checked and AOP's qc code sends a "svc_cdtrack" command to the engine requesting track 0, which is what causes that warning to print. Possibly QS should suppress that warning message, not sure.

btw, valid music tracks are 2-11 for the original soundtrack. You can enter a console command like "music track03" to start music manually, if a map doens't have it set up. 

hmm. well ive got my naming convention correct, and my oggs in the proper dir. so perhaps i will just go with the manual playback for now. thank god for the console.

i wonder if the tracks playback sequentially in the game, or what. i need to find out. i guess that is the real problem now? not knowing what track an author has intended for their map. 

It doesn't sound like an issue with the engine or with your setup. It sounds like the mapper forgot to specify an appropriate music track. 

i wonder if the tracks playback sequentially in the game, or what. i need to find out. i guess that is the real problem now? not knowing what track an author has intended for their map.
They don't play sequentially; mappers can set a key on the worldspawn entity of their maps to specify a cdtrack.. I forget the key off hand. All of the original game maps do this.
e.g. the base maps e*m1 all use the more industrial sounding music track. 

I think mappers used to set the music track to track00 so that no music would play during their map even if a CD was in the drive...

I vaguely remember someone creating a track00 song so that one could listen to that instead if one liked (I think that was around the time Travail was released). 

it would be cool if there was a way for the user to specify a custom playback via autoexec.cfg ie

music_eXmX "trackXX"

manually playing tracks via the console is an acceptable workaround, i know 100% aop compatibility is not a huge community priority :D 

You could always bind keys to whatever tracks you like. Then it would only be a single keystroke instead of going into the console every map. :) 

// entity 0
{
"classname" "worldspawn"
"message" "Centerprints this text on map start"
"worldtype" "0" // specifies silver and gold key models
"sounds" "10" // specifies CD track to loop
"wad" "path to wad; path to wad" // paths to texture wads used
"fog" "0.025 0.50 0.50 0.50" // fog density and color
"sky" "skyboxname_" // specifies skybox to use 

My main laptop has a partially broken keyboard; the C and D keys doesn't work. Due to this, to play Arcane Dimensions I've went to the Controls menu and configured QuakeSpasm 0.91.1 like this:
bind 2 +forward
bind w +back
bind q +moveleft
bind e +moveright

Now I'm using an external keyboard, so I've decided to reconfigure the movement controls back to the WASD keys. I've done this through the Controls menu again, but to rebind the "impulse 2" to the number 2 key I'd have to use the console.

And this is where the problem happens. Take a look at the ABNT2 keyboard layout. This is the keyboard layout for Brazilian keyboards. Also, remember that vanilla Quake engines does not require quotation marks around the command string for the bind command. But QuakeSpasm does, and instead of using a fixed American keyboard layout like vanilla Quake does, QuakeSpasm uses the actual keyboard layout from the OS.

Now put these factors together, and you'll understand the problem. QuakeSpasm made it impossible for me to rebind impulse commands through the console. If I don't put quotation marks, QuakeSpasm doesn't accept the binding, and when I try to type the quotation marks, QuakeSpasm toggles off the console - even if I type "disconnect" to get a full screen console (it switches to the main menu).

From an usability perspective, this is an awful situation. The only way to restore that binding without resetting everything else is to manually edit the config file.

Such problems must be predicted when designing input interfaces. Even the American keyboard layout can have problems in some cases, since the tilde character is used in some filepaths. The solution I've implemented in the latest versions of Makaqu is to not toggle off the console when pressing that key; the Esc key should be used instead.

Also, an additional user-friendliness feature can be to only toggle off the console by pressing that key if there's nothing typed in the commandline. That would prevent the user from starting a line with tildes, quotation marks or other stuff, but the user can work around that by inserting a space first.