Interesting, I'll check it out. 

What are people's thoughts on rotating bmodel bounding boxes when the "angles" field is set, as described in Baker's tutorial here:
http://forums.inside3d.com/viewtopic.php?f=12&t=2376

This lets you do "real" rotating doors without setting up func_movewalls.
I had a request to add this feature to QS. As far as I know the only quake singleplayer map to need it is e3m3rq.bsp, from the rmqwinter11 demo.

Here are some pros/cons I thought of:

Cons:
- strictly speaking, this is a breaking change. for example, in those maps that have a func_train with 'angles' set, (recall the offset elevators in add.bsp or apsp1.bsp), with fitz 0.85, only the visual part of the model is rotated, the bounding box is left in the original place the mapper put it. If you add bbox rotation to the engine, the bounding box is lined up with the visible part of the model. Both maps still seem playable with bbox rotation, but it's possible other content is broken.

Pros:
- better for mappers than hipnotic rotation, no need for func_movewall
- possible to make rotating fans, etc, with no qc
- already implemented in many engines: mark V (only if you use sv_protocol 668), fte, darkplaces, quakeforge, qbism.
- IMO the chance of breaking existing content is small; because you could consider the fact that bboxes don't rotate in vanilla quake a bug, and it's unlikely that somone would deliberately have the physics bbox in one place and the visual part of a model rotated away from that.

Question for Baker, was there any compatibility reaason you left this disabled in protocol 666 in MarkV? 

Remember the apsp1 issue with an entity being rotated a little? With a rotation of -1 or something? It had something to do with that, but I can't remember off hand --- it might have been of the "an entity has a strange rotation, do we honor it or ignore?" So I chose to disable rotation until the feature gains some usage. But I haven't thought about this in a while, so my memory could be wrong but I wanted to err on the side of compatibility.

The reason for protocol 668 was for smooth rotation. Something like FitzQuake interpolations positions nice and smooth, but not angles.

But yes, I'd love to see rotation go into mainstream usage. 

This was an angle key of -1 on the entity signifying something meaningful to mappers; probably the direction in which a moving brush model should move, I can't recall exactly what, but it was valid usage in Quake.

This wasn't a problem in the original Quake because angle-to-byte quantization with truncation meant that the value was transmitted as 0.

In FitzQuake it became an issue because it used a Q_rint call for better rounding, and so the -1 value suddenly became visible on the client.

It was only ever an issue on the client; -1 was insignificant enough that on the server things were just off by a little.

It seems that it should be possible to detect these entities at load time and flag them for special handling in the edict_t struct.

Another, possibly bigger, thing to watch out for with rotated bboxes is that some of the maps have an angles key set; e3m3 is one example from ID1. Things go quite insane if you don't exclude the world from bbox rotation. 

I believe the cause of the -1 angles in those maps is a door that was converted to a plat or train, without deleting the angle key. For doors the -1 is meaningful and i think the quakec even zeroes it out after doing its special thing. For plats and trains the angle isn't used, which means the unnecessary key is left alone to cause this bug.

Otherwise you'd see weird angled stuff in every level in fitzquake because almost ever level has a vertical-moving door (angle -1 or -2) 

To have true rotation instead of the hacky method.

Maybe enable it as a default on variable so if some map or mod does rely on weird qc usage it can be turned off. 

...is that you're pushing the solution on to the player. 99% of the time the player won't take up the solution and then it's going to be your fault anyway. Deervedly so, because you didn't fix it proper nor proive a sensible default to begin with. 

But you choose the default that works with most old cases, and place the onus on new modders to choose the one that they want in their rc or whatever. 

Here is a zip rotate.zip

Do -game rotate, map rotate or map rotate2

There is an old Mark V in there "fitzquake_mark_4.exe" which has rotation working and under both 666 and 668.

Rotate2.bsp only works right under DarkPlaces, I'm not sure why and I swear that ages ago I had that working in engine tests. I don't think even the RMQ engine does that map right. Try DarkPlaces and you will be standing on rotating platform to see the correct behavior.

Try Rotate.bsp with the provided fitz under 666 and 668. Pay particular attention to shooting the "drawbridge" and standing on it when it raises and lowers with 666 and 668 and try DarkPlaces too doing the same. 

The Problem With Cvar Controlled Stuff...
...is that you're pushing the solution on to the player. 99% of the time the player won't take up the solution and then it's going to be your fault anyway. Deervedly so, because you didn't fix it proper nor proive a sensible default to begin with
Haha :) Fix it proper for 1000 Q1 maps/mods ?
Sensible defaults vary according who to joe dick and harry are. Roughly - QS tries to provide sensible defaults and interface for the Average Joe, and *document* cvars, workarounds, etc, for more technical users/features. 

gb made a bbox rotation demo map back in 2010 that has a bit more stuff to play with:
http://www.quaketastic.com/upload/files/misc/rmqrotate_patch3.zip

It works well in the engine baker attached in #1508, or here is a test build of QS with rotation:
http://quakespasm.ericwa.com/job/quakespasm-ericwa-sdl2/62/artifact/quakespasm/quakespasm-r4daaebe3ea8cf5a23dc5c3530a9abc3f59cbe564.zip

(sorry about the url..) 

Works great!

And in Quakespasm if I noclip onto the top of the rotate continuous it works fine with the rmq_rotate/rotatetest.bsp (and it works in the old Mark V I provided, so I'm not losing my mind that standing on top of a rotator works fine in a correctly compiled decent .bsp)

[Perhaps my rotate2.bsp in rotate.zip is "wrong" or the map compiler used (unknown what it was) did a poor job.

I've not thought much about rotation in quite some time ...] 

Version 0.90.1 of QuakeSpasm is released.

http://quakespasm.sourceforge.net/download.htm
http://sourceforge.net/projects/quakespasm/files/

Changes since the previous version:
http://sourceforge.net/p/quakespasm/news/2015/06/quakespasm-0901/ 

Thanks Oz and Eric 

Thank you guys for all your hard work on this. It really is appreciated by those of us who enjoy playing Quake. The new games have _nothing_ on the classics. 

hi all!
thanks for the new version of the engine!

found this visual glitch with the teleporter and the secret door on the start map of 'contract revoked' pack:

http://imgur.com/VdnkXE3

i was using 0.90.1 windows version, seems to happen on both x32 and x64 executables. doesn't happen with quakespasm 0.90.0. graphics card is nvidia gtx 550 ti with recent drivers. 

thanks for the report. Was trying to be clever and sort the bmodels by texture to gain a bit of performance, but it breaks that scene.

I guess the entities were ordered in the bsp file so that the teleporter entitiy would draw after the bookshelf. 

I've noticed some rendering issues with certain models and fog in the map:

http://i.imgur.com/BGel82p.png 

Feature Request: Write stdout so that it is line-buffered or unbuffered or something. This would allow grepping the output and have the Quake Injector's engine output log update while playing.

Darkplaces does this well, no idea about other engines. 

In Jackhammer textures animate depending on which is their assigned frame. So you can do an animation that looks cascading inside of the JH viewport (for example with having a bunch of brushes with slip textures with increasing framenumbers.)

This looks pretty cool, but it seems this is not the way the engine handles things, since they all seem to start at +0. This is kinda lame (esp seeing as in Doom having them at different frame offsets is possible. Step back :|)

Would there be a way to implement this easily somehow? r_animtexoffset maybe? 

Duplicate the textures and offset them by hand. 

Well yeah, that is the obvious hack. Have the same textures a whole bunch of time with different offsets. Would be nice if it was possible in a non-stupid way :/ 

Why not just offset the UVs on the brush? 

How would that help with which animation frame is played? 

But it could help hide the fact they're all marching in unison, depending on how tall each brush is.

If you have large flat wall, it's always going to be visible. however, if you break the wall up into steps or multiple slopes and have the liquid flow over each one, this will also help hide the repetition.

Especially if you scale the textures as they 'flow' over the different angles to give them different flow speed. You will get some misalignment between brushes doing that.

If you do want them to move at different speeds (even though physics don't do that) you can just scale the textures on each of your flat brushes. A minor range of variation, say between 0.9-1.1 in Y.