6DOF Quake1

[Hypersonic]

@Spike

So movetype 12 is movetype_follow?
Ya, I'm about to abandon MOVETYPE_SIXDOF, and just go with a flag, FL_SIXDOF.
Is there an open flag that's not being used by something else?
There are 32 flags total right, it'a a 32bit int?

Writing code for rotating bbox seems to be more work than it's worth.
Ya, I think Descent1and2 just used spheres for collisions.
It's probably best to just use a cube bbox, and put the eyes the same distance above the origin as the gun is below the origin.
A cube acting pretty much the same as a sphere, equal on all sides.
A cube is one of the set number of bbox sizes that can correctly collide with the world, I hope?

At the moment I assume the player bbox mins/maxs to be hard-coded in the engine, can qc mods change this?
Can qc mods only change the skin of a player, but not the model?
I still haven't tried this in multiplayer, I don't know how the models show up at various orientations.
I know it places the model at 1/3 the view pitch angle, that would have to be changed for sixdof.

@Baker
I felt like that when trying to follow the math on rotation matrices!
I'm not sure if my method is the same as rotation matrices.
An overview of what I did:
-convert view angles to orientation vectors
-rotate around each of the 3 orientation vectors, 1 by 1.
-convert the new orientation vectors to view angles
-store the new view angles for next time (rather than store new orientation vectors and making sure they are orthogonal to eachother)

Each rotation is based upon a new orientation from the previous rotation, so it's going to be slightly off, but with small time slices, not by alot.
(it won't be off at all when just rotating 1 axis)
I'm not really sure how Descent does it, if it somehow does each rotation simultaneously, but I believe it always stores the orientation as vectors.


I was thinking about a flying cycle powerup, so you can run and jump around, or hop on a flying cycle and perform 6dof maneuvers!
The FL_SIXDOF flag would be set when you have the powerup, and provide a way to drop the power up to go back to run and jump.
Like Q2 had the flag model attached to a player, perhaps a bike model could be attached to the player.
Like the 6dof game Forsaken (there is a PC version)
Forsaken Screenshots for PlayStation - MobyGames
Forsaken Screenshots for PlayStation - MobyGames

Apparently Forsaken's source code is also out: Forsaken Video Game

[Spike]

QC uses floats to store the flags, so you're limited to only 23 separate flags.
You could define your own field for it, which would avoid all conflicts, but is a little more involved. Alternatively you could use some high bit in .movetype and mask it out for all other uses, which may be more invasive than desired.
Note that the issue with using bits in .flags is with mods rather than other engines, so high flags are probably better than low, but I really cannot tell you which ones are free.

The problem with bboxes is that its really the QBSP that defines the VEC_HULL_MIN and VEC_HULL_MAX, not just the engine. VEC_HULL_MIN is used by the engine as an offset for bbox traces such that for world traces, the entity's bbox is aligned to its minimum position, and if the entity is taller than 56 units, its head will go into the ceiling. As that rule applies only for BSP/BBOX interactions, you can still stand on its head properly.
so use a bbox max of '16 16 8' and view_ofs '0 0 -8' and you should get a true cube without breaking compat with other mods, but you need to hack up the qbsp too, which will break compat.

Personally I'm kinda tempted to try some run-along-walls type mod, but that sort of thing would really need spherical interactions with the world.

[Spike]

anyway, this topic inspired me to have a go at wall walking/climbing.
I added a new movetype to FTE ('give self.movetype=31' at the console in a single player game will activate it) that activates it.
basically what it is is that it checks your 'downwards' direction (ie: angular down, rather than real down) to find surfaces, and then uses the normal of that surface as your gravity direction.
This results in the player comfortably sitting on the wall as if its the ground, so you can run right up walls and across the ceiling.
Angle changes are currently 6dof-style angles which automatically roll to match the surface, which kinda resolves abrupt angle changes like jumping straight down from the ceiling.

clientside expectations of player angles, view_ofs, and bbox sizes are all lingering issues. I'm thinking of sending the gravity direction to the client and offsetting the rendering so that the feet are at least not in the wall.

[Baker]

Is the QuakeC hiding in your SVN somewhere? I want check this out.

[golden_boy]

What Spike did is pretty awesome, I tried it out the other day and I can see lots of uses for it, especially if the flag/movetype can be triggered on/off via QC or mapper-placed triggers, and if the gravity can be rotated to point in all cardinal directions plus up or down via trigger or button, just like in Prey.

I would totally want this for a powerup, or for prey-style puzzles activated by trigger or button, in RemakeQuake.

And by the way, we already have a modified version (TxQBSP2 etc) of the map compiler toolchain, so what's another modification for sphere-based world collision or whatever is needed... we just need someone who can implement this.

[Baker]

I'm thinking of sending the gravity direction to the client and offsetting the rendering so that the feet are at least not in the wall.

Send scale info so sideways Quakeguy fits in his hull.

Sure it might be a bit weird that Quakeguy standing on wall is very fat but only in a single direction and not so tall ....

Could add to the intimidation factor!

Maybe BSP2 needs a couple of extra hulls. The impact of such things is a bit beyond my current knowledge of the guts of the BSP but I think you said Hexen II had quite a few hulls.

[Spike]

hexen2 has 8 hulls, but only 5 are actually used.
making the bsps contain spheres instead of bboxes could work, but I'd rather the brushes were directly available and then we can ditch the whole distinct hull sizes thing entirely.
Its also tempting to open up the .map file instead and directly grab the brushes out of that - if hull 0 exists, the brushes can fairly easily be inserted into the hull0 bsp tree at the appropriate node, which would also mean qbsp could skip hulls 1+2 and finish faster.

[Mindf!3ldzX]

I want to play Clan Arena DM3, with the ability to walk on walls and ceilings. Ultimately letting me camp anywhere, obv

[Bloodshot]

You know, that just made me think - what if you couldn't just fly anywhere with this, but actually walk up walls? And what if it was a powerup(like the biosuit except boots or something). That would be pretty interesting.

EDIT: Didn't see GB's post :/