Awesome list of compat issues, Baker.

Link to a previous discussion: here

This is the code I set up for QS (never merged in) link..really just applied your tutorial.

I'm more skeptical of this now than 18 months ago, now I am thinking if it is added to engines like QS/MarkV it should be opt-in only.
- possibly an entity key "_true_rotation" "1" to enable for an entity,
- or a cvar "sv_truerotation" "1" - mods would stuffcmd it if they want the feature. would need to be non-archived and not meant for players to change or save to cfg's.
-a checkextension so the engine can report it is supported.. although if a map wants the feature and the engine doesn't have it, the map will probably be broken. 

Even the player? 

I think this feature is just about doing collision against rotated BSP models; entity bboxes like the player still have to be axis aligned (guessing here). 

my main concern about it is that the current implementation (from a few years ago) assumes the expanded hull is still valid when rotated. Since the hull is expanded a different amount on each of six axes, if you rotate it 90 degrees onto its side (e.g. a drawbridge) the player will experience being able to get too close to it or not close enough depending on which side they are touching.

I think the perfect method would takes hull0, decompose the bsp into "brushes" for each solid leaf, and then expand those at run time using a quake2-style method. I don't know how hard that is and i don't know what potential problems will crop up with it. (e.g. collision glitches due to leafs being weird shapes.)

On the other hand the example method from a couple years ago has the advantage that it actually exists and has a reference implementation. 

From reading through posts, it seems all of you were in favor of supporting true rotation. And QS itself had the experimental version - link didn't work anymore :(

Looks like the only thing holding this back from going forward was the logistics of how to include it? Minimizing the consequences? 

Is it sufficient for a new mod to set the angle and set SOLID_BSP? This wouldn't break hipnotic style rotation in existing mods since those mods makes the rotating bsp model non-solid. 

@metl - Hulls. Good point. Will monsters think they can walk on a rotated bridge, etc. Hmmm.

ericw has a simple test map that the RMQ engine fails on in the thread at inside3d ... ironically of all things my implementation in ProQuake works fine and seems to work all the test maps. But do I trust that entirely? Haha ... no.

@damage - There is an entire release with rotation. http://quakeone.com/~images/news/spdemo3_1.jpg <--- the drawbridge there in the first rotates down. Remake Quake - By ijed, gb, supa, MH, rickyt23 and others ... I have memory block, there was another mapper whose name started with an "S", but isn't scragbait or scampie. Came with a custom engine. Has underwater warp, hurt blurs, first engine with BSP2, etc. 

possibly an entity key "_true_rotation" "1" to enable for an entity

I'll have to re-remember/re-investigate what hints the map compiler expects and from what.

opt-in

Already had planned that ;-) My thoughts were a worldspawn key.

cvar "sv_truerotation" "1" - mods would stuffcmd it if they want the feature. would need to be non-archived and not meant for players to change or save to cfg's.

I just wanted to mention this because I've hated this in other engines for a long time, long before Quakespasm ever existed. Engines would add CVAR_ROMs. A concept that makes no sense.

If you have a read-only console variable, how is it even a console variable? It's not variable at all. The user can't change it. How is it even a cvar? Why is it a cvar?

"god", "noclip" aren't cvars.

Anyway, that's a broken concept because really what someone wants to do is in QuakeC extension check in this particular case.

But if the engine doesn't support BSP2, you won't even get far enough to load the map for the progs to even run the QuakeC, haha ;-)

And the whole failed thing about the QuakeC extension system, is a progs.dat prepared to handle a situation where some of what it wants is available but not others? And even DarkPlaces isn't very consistent from version to version. Plenty of mods that an older (or newer) DarkPlaces says based on QuakeC extensions that it's ok --- and it don't work.

/Little bit of explanatory rant in there towards the end. Since Mark V does Nehahra and had to deal with a mod does all kinds of things it shouldn't do ... haha ... does bad design tick me off? 

Baker, yeah it's a good point that the feature is already in use in released q1 content (even if the RMQ releases were labelled as "demos"), and several engines implement it (darkplaces, fteqw). There is a door that swings open in e3m3rq from rmqwinter11 (right at the start of the map, after pressing the button); that map is unbeatable without this feature.

So an argument against making it opt-in is it would create a fork in the feature.

metl, good point about the hulls, didn't consider that. 

I think the time for rotation is now.

Just in firewalled form, to limit any possible side-effects.

And we'll just see where it goes!! Haha.

/I have a great implementation in mind. Should address most, but not all of the above --- certainly not the hull concerns. 

@Baker: Yes, I have most, if not all, of the RMQ content archived, great stuff there. A ton of cool features.

I admire more than you know everything you guys do. Last time I consolidated it all it totaled about 15 Gb's plus. 

With my current drivers(375.95) and a gtx 1060 the RMQ "2011 Singleplayer demo" is completely borked.

HOM's everywhere and brushes just gone missing. I don't think it's my setup. I just put my two .pak files in an id1 set -game and go.

I wanted to look at it again. 

But I can see an implementation of the following:

"If you have a read-only console variable, how is it even a console variable? It's not variable at all. The user can't change it. How is it even a cvar? Why is it a cvar?"

The user can check what the value is via the console.

The user is prevented from changing it as a function within the game changes it, OR a current state of the program prevents it from being changed.

sv_cheats comes to mind. 

So your example of a read-only cvar is one that isn't read-only?

] sv_cheats 2
You must restart the level for setting to take effect.
] sv_cheats
sv_cheats is 2 

Console variables in Quake have no restrictions on the value. I can do the following if I choose ...

] skill "Blue is my favorite color"
] fov 243030303

Console variables in Quake are not a reflection of the current state.

If you want to see this in action, type "vid_width 720" in the console. By itself, without a vid_restart command, changing the vid_width does not have any effect. 

CPU architectures, Kaby Lake, Zen and beyond, being tied to a version of Windows? Shitty as fuck right.

I just learned about this: http://www.pcworld.com/article/3112663/software/microsoft-made-em-do-it-the-latest-kaby-lake-zen-chips-will-support-only-windows-10.html 

I was working from memory, it was a poor example.

My point was that I could imagine a few instances where it would be acceptable to allow the player to read - but not modify - the variables directly. 

Yet another reason to boycott Losedows 10! Once assholes, always assholes I guess... 

https://www.youtube.com/watch?v=UR4DSgjPVWg

I came across this today. It's a short demo of a rendering engine early in development. It might be interesting to follow where it goes in the future. 

Reminds me of this vapourware: https://www.youtube.com/watch?v=BpT6MkCeP7Y

These "Real Time Raytracing" engines never seem to catch on these days. As good as that demo looks, I'd have to see a lot more to believe it'll actually "happen". A downloadable demo for instance would be nice. Right now everything on their site is just "coming soon", which isn't exactly confidence inspiring. 

In the past they've only worked well for tight scenes where the bounces are rather confined and for lower poly stuff.

The promising thing about this is the claims it is "hybrid" raytracing. So perhaps traditional methods are being used on the more difficult with raytracing assisting.

I've been hanging out for realtime raytracing for over a decade now, I'll not hold my breath. 

I am not sure what Pritchard meant in #28560, but I would like to clarify that the ray-tracer engine from my link does have a demo you can try out. It's built into the "3D modeller" package that is on the downloads page. (It's not much of a modeller yet in this bare-bones demo. It just reads text files with scene descriptions.)

http://www.infinity3dengine.com/get-infinity/3d-modeller

You will probably find that the demo doesn't really give you very impressive frame rates for even mildly complex scenes. Until the author comes up with the benchmark he is promising, it's hard to say what reasonable applications this engine could have. I'm a little curious to see what he does with it, but you don't obviously have to be :) 

Euclideon??? 

I didn't think to check the link for the 3D modeller, I just went to the other two pages on the dropdown, since I assumed that it wouldn't be anything like the demo video on YT. It's about 50% of that at least but considering you can create more scenes than just the chess board that's pretty decent. Listening to my CPU fan spin up was fun.

It'll be interesting to see what comes next for this, I do want to see a decent realtime raytracing solution in the future. Perhaps even one that can be used for games!