I mean your "school of thought" on the efficiency of a network protocol. No I don't mean your explicit approval, per se.

(And maybe with luck I may have a real block of time later this year. Otherwise it's 2017 -- and such is the way of things in this world ...) 

Thanks for the code review :) Mankrip: here is the diff to QS. I was meaning to test it more, like test connecting between my implementation and FTE/DirectQ/RMQEngine and demo compatibility, but didn't get around to it yet.

I will look at implementing PRFL_EDICTSCALE.

One thing I need to look more closely at is the "roughround" flag in RMQEngine, in MSG_WriteShortAngle:

// -1 and -2 are legal values with special meaning so handle them
// the same way as ID Quake did; other values can use rounding
if ((f == -1 || f == -2) && roughround)
{
// encode to byte, decode back to float to get the same behaviour as ID Quake
sang = (int) (f * 256.0 / 360.0) & 255;
f = (float) sang * (360.0 / 256);
}

I'm not sure what the purpose of that is.

Also, I am tempted to switch QS to use the 24-bit position to save space. I noticed that with 32-bit positions, QS overflows the signon buffer when loading telefragged.bsp (this map requires something like 48KB with protocol 666..)

My thought on the protocol flags: it's useful if a demo recorded with protocol 999 is playable in any engine that supports 999. This implies freezing the set of flags, because otherwise an old 999 client won't be able to play a demo (or connect to a server) running a new 999 version with new flags.

General thoughts: I'm still sort of meditating on this as well, and it's not merged into the main QS repo. Larger than +-4096 map support only really happens for users/mappers if 999 is enabled by default, you can't expect users to know whether a map requires >+-4096 support and set the sv_protocol cvar accordingly. I even forgot to set it myself while testing oms3_2.bsp and had to restart the level, lol. 

My to do list --- whenever the time comes and it does not feel soon ---

1) ipv6 + what I have been discussion above + automatic background high-speed LAN/non-LAN propogation of current mod running for coop via TCP.
2) Enhanced graphical integration with Quaddicted.
3) Mirrors + security cameras.
4) Linux software renderer build and polish up unreleased OpenGL version which regretably uses SDL because X Windows is a cluster-mess and seems like it was designed by a basement nerd who never used an operating system with a decent GUI --- and even then SDL doesn't cover all the bases, but hats off the SDL guys because it does cover 90% of the way and SDL 2.0 is exceptionally nice and forward thinking.
5) Inter-map travel with single file saves.
6) Absorb remaining ProQuake features. Absorb 1 or 2 remaining JoeQuake features. Mark V already plays .dz demos on any platform with no dependencies, the Mac build for instance. ProQuake will then become just a different build of Mark V.
7) sv_gameplay_fix_qrally_is_a_crappy_mod_dot_com 1
8) Probably add rotation back in.
9) I think I needed to touch up Nehahra in 2 places.
10) Possibly multiplayer save games.
11) Take another look at WinQuake and what I wanted to do but didn't. It wasn't too much, but I can think of a 2-3 things.
12) Would need to check list, I'm sure something else is on there. 

re: not knowing if a map requires large map coordinates. 

I'm not sure what the purpose of that is.

All discussed here: http://forums.insideqc.com/viewtopic.php?f=3&t=3184

Basically the game uses an angle of -1 or -2 to signify special behaviour rather than rotation. With the default rounding these are transmitted to the client as 0 and the entity draws correctly. Using Q_rint (Fitz & a few others) they transmit as non-zero and the entity is incorrectly rotated. So in certain cases it's necessary to revert to the original engine rounding: the linked thread gives one test map and I remember reliably reproing this bug in a number of engines. 

Quakec resets the yaw to 0 after detecting angle -1 or -2 in the spawn function for those entities that support the special values.

The bug occurs when -1/-2 is added to classes that don't support those special values, such as func_train. In that case, the spawn function doesn't reset yaw to 0.

In maps that have this error, it is invisible to players in stock engines by the way those engines do rounding. (at least -1 is invisible, -2 might still show up as a bug) 

Cheers, I suspected my explanation was incomplete.

So it comes down to "do you want to support buggy content" then. 

i wonder if it's possible to fix the -1 and -2 yaw values without screwing up other entities that are simply spinning in place, like fans. Do func_rotate objects always have a positive yaw? And what about monsters and players that rotate? Do they ever have negative yaws? 

I believe this is something that Sock tried to fix in AD in the progs but it broke a bunch of func_doors... found that bug fairly quick. 

Sometimes for a func_rotate_train you might have a negative angle, if e.g. a waypoint has a destination angle of 270 degrees, and you want the train to perform two full rotations on the way there, you could set the starting angle to -450.

Of course, you could easily redesign so that all the angles in that set-up were positive, there's never a necessity to have negative angles. The problem is 1) insisting on positive angles is changing the rules after the game's started and 2) the bug we're fighting is introduced unwittingly by mappers, so giving them more to think about won't really help.

In an ideal world, I'd introduce a very targeted fix. I don't think you need to deal with -2, because that angle should be visible in normal engines and fixed in testing. What I'd want is for the engine to detect when an entity has received a yaw of -1 from the map file, and render that entity as if it has yaw 0 until its angle next changes. It would still have yaw -1 from the QC's point of view, there would just be a temporary disconnect between the visible angle and the QC.

I thought you could just get away with this by sending a fake angle update over the network at the start of the map, then you wouldn't need to a) monitor whether the angle had changed at all or b) keep a flag to remember if the -1 had come from the map load or not. When I thought about it more I realised that you need to send this message each time the object comes into vision, so that wouldn't work. Is there a way to hack this into the protocol? 

Mark V has "sv_fix_func_train_angles" to strip negative angles off a train. Defaults on for APSP1.

(Yeah, yeah, Preach and the theoretical train.)

With true rotation, negative angles never happen, the angles are wrapped 0-359.99999 

Just as a reminder that I am still checking here, still hoping for a fix for the Nehahra bug in the final boss map at least. Solving the Shrak issue would also be nice, because then all the official and inofficial addons would work with this port, which is still pretty much the best out there if you are aiming for vanilla Quake gameplay with a few nice enhancements. 

According the source code, the Shrak invalid skin number issue should be fixed. Could you confirm whether or not this is still an issue? 

Testing with the build from May 8, 2015 (if that is the latest one), it seems I can no longer reproduce the issue, at least not when playing the first few Shrak levels and gibbing mobs like crazy with the rocket launcher. We can consider this one fixed, then.

What remains on my personal list is the Malice issue from #855, the game messing around with FOV until it crashes. 

Update:
I just saw there is a build from Feb 8, 2016. Used that one and tried Malice d16 again. Unfortunately, the Host_error: Bad fov: 180.000000 problem still occurs when the boss pulls you towards him. Also tried by loading the map directly, skipping usage of savegames from earlier builds. 

Possibly fixed for Malice.

Mark V with Malice FOV fix

Let me know if that fixes the issue. 

Latest mark v seems to have problem with playing demo with pauses. If the client pauses the demo ingame while recording, it doesn't seem to unpause anymore when playing it. It can be seen in Vondur's demo of my latest map. Quakespasm plays it without problems (unpauses right after pause). 

Baker, your latest build fixed the FOV issue in Malice... kinda. Good news is the crash doesn't occur any longer. That's already a huge progress!

However, if I (quick)save during the fight and (quick)load, the FOV would be totally warped. Checking the config.cfg, I see that the game (still) changes fov to 170. That needs to be prevented.

Then there are two other issues regarding demos/cutscenes, one of them may be related to PuLSaR`s finding above. Cutscenes don't play any more when they are inside of PAK files. I get an error like this at the end of d15 after entering the exit portal:

Playing demo from cut8.dem.
ERROR: couldn't open
D:/Games/Quake/addons/malice/cuts/cut8.dem

If I extract the file from the PAK, it works. Same with any other cutscene, e.g. from the beginning of the game.

The other thing is rather minor: The HUD remains visible during the cutscenes. I don't know if that can be changed, though. 

Hi, for me the last build still crashes on my toshiba laptop with win xp sp3 and trident blade xp integrated video. The directx build runs fine and both original fitzquake and quakespasm, the latter very slow though. 

Thanks for the info. I don't expect to have time to do further updates for a while (next year probably). But I read all the feedback and always use it when the time comes. 

According to this that card doesn't support OpenGL, so QS is probably using the windows software renderer.

If you don't mind, try launching QS with "-condebug +gl_info", then quit, and upload the qconsole.log file from quake directory. Possibly MarkV crashes when only the windows software renderer is available? (the software OpenGL implementation in Windows is unusably slow, anyway) 

Interesting. Well, at least there is the Direct 3D API for him to use. 

Thanks. The card had opengl 1.2 support and could run even quake 3 engine games. Mark V changes video mode, 640x480, and then back to desktop resolution and exits cleanly. 

Mark V changes video mode, 640x480, and then back to desktop resolution and exits cleanly

That sounds like an error that happens at some stage during video startup. I would also suggest that you try running it with -window. This is just to test it's behaviour, as it may be able to pop up an actual meaningful error message if the failure occurs in windowed mode.