I had a try installing all content to another computer. When decompliling it looked it had a windows version of its own included.
When started this version my computer was able to download the models (with baseskin frame included) maps and textures.
When I tried to start the arcade version my computer freezed and I had to make a new win install.

It seems as you could actually win money with it! 

i want my xmass crate! 

 

China has the biggest banana stock!

He who has the most bananas,
has won the world!!

Fyffez. 

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

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.