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. 

I've tried windowed mode and still no error message, a black window appears and then dissapears. I'm running from a network drive with write access but i don't think that matters. Here's the condebug output:

UDP Initialized: 192.168.0.4
Exe: 19:58:01 Feb 7 2016
256.0 megabyte heap
FOUND: ARB_multitexture
Warning: texture_env_combine not supported
Warning: texture_env_add not supported
Warning: texture_non_power_of_two not supported
Warning: texture_filter_anisotropic not supported
Warning: Swap control not available
Hardware gamma enabled
joystick not found -- no valid joysticks (a5)
Input initialized 

Even if you did get it work, it looks like you have virtually no opengl extensions and it wouldn't be very nice at all.

I coded and tested assuming the worst possible hardware was an old Intel GMA and if it ran fine on that well --- that's the baseline and a very low bar.

You have something with Open GL drivers that doesn't even meet the very low bar of old Intel GMA.

Even if it did run, it would terrible and probably not render correctly in all circumstances.

The Direct X version does virtually everything the OpenGL version does. 

FOUND: ARB_multitexture

Does Mark V have -nomtex? IIRC the Direct3D versions doesn't have multitexture, so it might be worth testing with -nomtex to see if that's your problem.

Otherwise I suspect that the best way to figure what's happening would be to single-step video startup in a debugger on the hardware in question. 

Ok but i've tried with both gldirect and the software opengl driver and the same thing happens. Moreover original fitzquake only runs in 640x400x16: if i select another resolution it starts at 640x400x16, goes to desktop and then i get a black screen with sound when it goes back into the game. That's why i was interested in Mark V, may be it's the 32 bit rendering why it doesn't run? The card supports 32 bits however. 

@MH -- my Direct3D version has up to 8x multi-texture because I made some changes/enhancements.

Otherwise I suspect that the best way to figure what's happening would be to single-step video startup in a debugger

Well, I have no absolutely no intention --- I mean 0.00000000000 -- of trying to support a 2002 era oddball graphics card.

I'm not into that. 

Very well could be. Mark V does 32 bit color. Doesn't even have the option for 16 bit color since even the most worst/terrible/horrible computer I could find for testing would do 32 bit color just fine. 

Things that can help performance on old cards with fitz-style engines:

+gl_flashblend 1
+r_oldwater 1
+r_dynamic 0

Those defaults change from original FitzQuake to QuakeSpasm/MarkV (I think) to better-quality options, which could explain why QS is slower than FitzQuake for you. QS has a "-bpp 16" command line option as well, though from a brief look MarkV always uses 24bpp. 

For $6.50 + free shipping, the graphics card could be upgraded to 16 million colors ...

http://www.ebay.com/itm/Nvidia-GEFORCE2-MX200-64MB-G4D-Graphics-Video-Card-/182152616483?hash=item2a69245a23 

toshiba laptop

It's worse than that, he's dead Jim.