Just Browsed To Func Using Lynx

Works pretty well, gave me bad ideas though, like piping the output to quake so I can browse in the console

QuakeOS :) All terminals paned vertically in the (transparent?) console, notifications in the sbar and graphical apps in the game... with demos in the background if not playing. 

Kindly redirecting misguided guy about QuakeC stuff in wrong thread to instead post into correct thread and providing link. 

Yeah, I know the rules by now. If I can help other newbies avoid making my early mistakes, all the better. 

Okay so I just did my first test map for rotating objects using the AD .fgd! Wow, that was kind of a letdown for obvious reasons(no collision/fake collision).

Not a knock on AD as it's fantastic Mod made with existing tools and played in existing engines.

But why haven't the main compilers and engines incorporated rotation with collision into their source?

I guess I mostly mean Quakespasm and Eric's tools. I know about DP already but hmap2 is not widely used so not a consideration really.

I googled and saw several examples were it was incorporated, is more elegant and is much simpler to set up mapping wise. But those projects perished.

Jus' curious... 

I think most of that stuff is handled by quakec rather than the engine itself.

Also the compilers want to be as "feature agnostic" as possible. They want to be able to compile whatever is put in front of them while only worrying about the base geometry. Additional features are still passed through to the end bsp, but will be handled by the engine / progs.

I think the idea is largely for backward compatibility and to ensure that mappers design vanilla maps to be playable in dos or winquake. For example, if I make a map for quakespasm-spiked with rain and snow, etc. It should still be able to be run in winquake or dosquake (probably with some console warnings).

Big ol' caveat here: I'm a layman and have nowhere near the knowledge of others here, who I encourage to correct me if I'm wrong :) 

Brush rotation with correct collision would be an engine thing.

Compilers wouldn't need to do anything - it's just another brush model to light.

Backwards-compatibility with vanilla engines seem to be less and less important these days because it seems almost every major release breaks vanilla limits in some way.

The key problem would be ensuring support and identical behaviour across a number of recent engines (DP, QS, MarkV etc.). 

I'm sure this has come up numerous times. And after I posted I found in this very thread where it was discussed in 2014.

gb said he submitted the changes needed for Quakespasm, if they wanted to implement it, and he also posted a link on quaketastic that has everything.

I loaded it up in DP's "Oct 12 2016" build and everything "worked". Not flawlessly though. To be expected of course.

Anyway, I just thought that with the advancement of engines, tools and mapping that this would be another cool little feature to have. Sans the clumsy hip-rotate method. 

thanks for the clarification Kinn 

E3M3 -- the freaking map itself --- has angles. It's true.

So does a distrans sp release? dis_sp3?

Supposedly messes with the spikey ball in the Quake END map (the Shub).

Messes with something in Nehahra somewhere.

So if someone cares about compatibility, it must be done right.

Rotation has consequences. 

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