I really appreciate that you're looking into this, and feel free to laugh at me if it's just me doing something really stupid!
Your map makes me realize I ought to implement a spawnflag for bidirectional rotating doors
Currently I'm able to walk through the door freely, which is somewhat disconcerting
Too tired to look into this more right now, will debug the engine code later today.
And no, nothing wrong with your map
Nah map is just awful. Add a couple of flashing lights and I'll end up in an insane asylum
Been testing some stuff regarding this today but unfortunately my skills are not up to the task ... yet!
Seems like rotating doors have become my obsession . Never liked sliding doors
Still feels like I'm overlooking something or doing something wierd.
Yeah I suspected that .
And nothing to be sorry about since as far as I know you do this for free on your free time so I didn't really expect it to be fixed instantly (unless it was an easy one to fix of course).
So don't worry about it, would be cool if it's fixed one of these days though
It's starting to come together. So you'll need the QC for it, the engine support which should largely be there, and map compiler supporting origin brushes.
Since I wasn't around way back when, I don't have the full overview over QuakeSrc stuff. I'm reading up though.
I think bjptools' treeqbsp supports quake2 maps, so hopefully it'll only be a small hacking maneuver to get origin brushes supported in Q1.
goldenboy wrote:Right. Wouldn't it be simplest to rip the rotating door from Half-Life or Q2, and add support for origin brushes to one of the map compilers?
I haven't really looked into it, but does quake2 simply save the original brushes, and every frame rotate them and regenerate the clipping hull? That would explain the amount of jittering when walking on a rotating object in quake2 (e.g. Lava Tomb's devilish rotating drum thing)
If that's the trick, engine support would simply be a matter of decompiling the visible hull for each entity at load time, and then any time an entity rotates, using the decompiled brushes to regenerate hulls. (and then do whatever physics hacks are necessary to keep players from ending up stuck inside a solid object)
No, the map compiler destroys the origin brush and stores its center into the entity as the origin key, which in turn causes the geometry to have that position subtracted from it (recentering it on 0 0 0), it's the same method used in all Quake1/2/3 engine games.
The jitter you speak of is network compression most likely, combined with the prediction of rotating floor objects (standing on a rotating bmodel).
LordHavoc wrote:No, the map compiler destroys the origin brush and stores its center into the entity as the origin key, which in turn causes the geometry to have that position subtracted from it (recentering it on 0 0 0), it's the same method used in all Quake1/2/3 engine games.
So, how does collision work? I don't think you can just rotate a clipping hull...
LordHavoc wrote:No, the map compiler destroys the origin brush and stores its center into the entity as the origin key, which in turn causes the geometry to have that position subtracted from it (recentering it on 0 0 0), it's the same method used in all Quake1/2/3 engine games.
So, how does collision work? I don't think you can just rotate a clipping hull...
Well technically you could rotate another object into the hull's space (being aware that the space in question is 4D - it changes orientation over time).
But Quake just keeps the player bbox aligned to the model, totally bogus but for rotating doors it actually behaves alright - tilting floors and such can get a bit screwy but again no one is likely to notice.
So Quake is just tracing a straight path from frame start to frame end through the model, it's very approximate, and it only "works" because the model in question is a pusher, it pushes the player out of itself as needed.
spinduluz wrote:Sorry I've opened this topic again,
I finally got a door to rotate in a DP Q1BSP map using dpmods info_rotate and func_rotatingdoor. However it doesn't look like the door is handling collisions, it simply kill me and I get a message that I "was in a solid"
Am I doing something wrong or is it some limitation with the Q1 bsp format?
Fixed hmap2 bugs with compiling rotating doors, try again.
a lame way to make the colision part of a rotating door is this:
- don't do it.
Make the door a solid, no one can cross, and make is unsolid wen you start the animation that open it. Lets say.. is binary: is closed and solid or open/opened and nonsolid, the opening animation just eyecandy.
. Never liked sliding doors 