the jvm has too many advantages, and i'm not even sure if there are good machine code compilers around.

Also, I'm not sure how much of a hurdle it is. It's one additional install that most users will already have anyways... 

Had you said .NET, then sure... 

To all intents and purposes, this is the same map on two different machines (I can't actually explain the minor differences.)

On the left, Intel P4 with standard fast vis. On the right Intel i7 with standard fast vis and 8 threads.

http://img375.imageshack.us/img375/9563/comparey.jpg

I'm not sure how fast 0:00 minutes is as I didn't quite see it happening, but it seems quite fast!

"QI, my boy" 

people will be bugging you to vis their maps for them. :P 

http://forums.inside3d.com/viewtopic.php?t=2376

Example mod with QC and engine source, testmap and mapsource:

http://www.quaketastic.com/upload/files/misc/rmqrotate.zip

Why is this better than hiprotate:

1) easier to use - only rotate_door and an info_null needed to set it up

2) has its own collision - no more func_movewalls, no more laggy collision, no more stairstep effect, no more painstakingly faking the collision - very large rotating bmodels no problem

3) Key doors etc.

You need a supporting engine:

Darkplaces, FTE, Proquake, Qrack, RMQ engine (the latter is based on Quakespasm/FitzSDL for you Fitzquake lovers, and included in the test mod)

A supporting map compiler (only QBSP, you can use whatever vis and light you want):

right now only Lord Havoc's hmap 2 (qbsp stage), because it seems a fix is required

A custom progs.dat:

doors.qc needs a couple provisions related to rotating doors, and one new file with the spawn functions needs to be added, or its contents placed in doors.qc for example.

How it works:

This method exploits a map compiler hack (present in all compilers that support Hipnotic rotating entities, which are practically all of them) where an entity whose name starts with "rotate_" gets its origin from something it targets. In hipnotic, rotate_object uses this same hack.

The engine then supports the bmodel having an .avelocity (angle velocity) just like grenades etc. already use, and makes it collide properly.

The additions to the engine are pretty minor.

The map compiler fix that Lord Havoc did is also pretty minor, but I haven't fully understood it yet. I think it could be added to Tree / Txqbsp as well, by someone who understands those a little better.

I sincerely hope that support for rotating bmodels will be added to Fitzquake, or Quakespasm which seems more actively developed and is based on Fitz.

I also hope that standard mods like Quoth will support this, it's not that much code to add to a progs.dat and it's clearly better than hiprotate.

Right now we're still hunting one or two minor bugs, and there's no rotating train that uses this yet. However, it definitely works, and engine support is growing.

Give the testmap a try, perhaps. 

Patch: Make START_OPEN and triggered linked rotating doors work correctly

http://kneedeepinthedoomed.wordpress.com/2010/07/12/half-life-style-rotating-doors/ 

mappers, does this make rotating things easy enough for you (tool and engine support aside)? Suggestions what to do with the bounty since this was great team work? 

I can see two obstacles for most:

1. custom progs.dat required

2. doesn't work with AguirRe's or Tyranns's compiler 

yeah, but there is no alternative to 1, right? 2 should be solvable. :) 

no, there's no alternative to 1.

2 is solvable, but not trivial. Good coder needed.

The number of things that need to be fixed in AguirRe's compilers is rising. This, lit files, hint/skip...

I think the last release is 3 years old... 

He's the highest authority of Quake rotation. 

Necros Decides
He's the highest authority of Quake rotation.

i haven't actually looked at it yet. i was away for the weekend getting shit faced and my head still feels a little heavy atm so it's hard for me to get excited about anything right now.

still, this is kind of a no-brainer for the most part. anything to make rotaters easier to set up and improve the abysmal hip collision method is good in my mind.

just looking at it on paper, this should be fucking awesome because anyone who's done hip rotaters knows they are goddamn stupid to set up. and yeah, anything with collision is going to be fairly sketchy to begin with and just downright annoying to deal with in an editor because you'll have all these movewall chunks floating around.

the progs side is basically a non-issue (for me anyway, and getting real rotaters is worth it), although, getting it into quoth may not be possible.
but even for a non-coder, they can just use the progs provided above-- it's not a big deal for mappers to make their own pak0.paks these days (ie: with only the rotation changes).

i think the biggest hurdle will be having to deal with a different bsp compiler and then after that, a different engine.

otoh, aguirre has always had his compilers as open source, so assuming this overhaul isn't insanely complex (and gb implies that it isn't) then someone could haxor it into aguirre's bsp like willem did for multi-thread vis thereby making it a moot point.

how does lighting and texturing work with these though? are they still moved to the origin and textured there, or are they textured where they are as they appear in the editor?

engines are easier to deal with as most of the good custom ones give you enough flexibility to tweak them however you want, although i will say i myself will probably wait until it appears in (at least) quakespasm, if not fitzquake itself. otoh, fitzquake doesn't actually work for me because of 64bit multicore timing issues, so mostly it's just quakespasm that i'd really want.
however, i'd like to beg any engine coders who add this to remember that it's not enough to just support it but to support it well. this means more accurate angles is basically a must and avelocity interpolation on bsp models as well. i know darkplaces does this already and it makes even old style hip rotaters fucking sweet to look at. watching large gears start from a standstill and accelerate slowly is downright sexy.

i'm a little fuzzy on why this only works with .avelocity though... does this mean that if you set .angles manually, the player could get stuck then? i guess that actually makes sense, since you'd get stuck if you setorigin'ed platforms too. or do you mean the collision breaks if you set .angles manually..?

honestly, this new rotation method would probably bother me more than the average mapper because i have a dozen or so custom rotaters that rely on setting .angles manually. :P

but... if this works as well as it says on the tin, i've got some ideas for rotating rooms and rotating rooms inside rotating rooms...
summon bigger rotating room indeed.

btw, this is baker's work right? the i3d forum thread implies that anyway since he's the OP. 

i know it sounded like it, but i'm not having a dig at the hipnotic guys at all. what they did back then was insanely clever and extremely cool. it's just that in this day and age, and especially with the crazy cauldron of ideas bubbling in the back of my head, it just doesn't really cut it anymore. :( 

just tried it out in an april 2010 darkplaces build.

the bugs are a little more serious than is intimated. it's possible to walk or fall right through rotating doors if you walk against them while they are moving.
also, the axis of rotation doesn't appear to be very precise as you can see the top edge of the rotating bridge slide around as it goes through it 90 degree rotation.

still, it's proper rotation with bsp walking collision preserved (when not experiencing the bug i mentioned) so it's still really good.

i wouldn't use it in a map in it's current state though because it's fairly easy to walk/fall through them, but aside from that they seem pretty good. 

Point for point...

getting it into quoth may not be possible

... hmm, it's not really a lot of code to add. Our progs is probably way bigger than the Quoth one already, I doubt there are any issues with technical limits.

otoh, aguirre has always had his compilers as open source, so assuming this overhaul isn't insanely complex (and gb implies that it isn't) then someone could haxor it into aguirre's bsp like willem did for multi-thread vis thereby making it a moot point.

Since his compilers are originally id's work, and contain work by other people as well, like the "author" of TreeQBSP, sure they can be modified. Adding the necessary fixes isn't trivial though, at least for me. Here's the diff, at least I think this is what it is:

http://svn.icculus.org/twilight/trunk/hmap2/brush.c?r1=5708&r2=9834

how does lighting and texturing work with these though? are they still moved to the origin and textured there, or are they textured where they are as they appear in the editor?

My experiments say they are textured at 0 0 0, but lit at their place in the map. Look at rotatetest.bsp, the rotate_continuous has the shadow from the bar above going across it.

engines are easier to deal with as most of the good custom ones give you enough flexibility to tweak them however you want, although i will say i myself will probably wait until it appears in (at least) quakespasm, if not fitzquake itself. otoh, fitzquake doesn't actually work for me because of 64bit multicore timing issues, so mostly it's just quakespasm that i'd really want.

RMQ engine is based on Quakespasm SVN, with their blessing, and is available at kneedeepinthedoomed; I also sent a diff containing the changes to the Quakespasm crew. This engine is also contained in the testmod I posted.

The smoother rotation affects the protocol though; this would explode protocol 666, ie Fitzquake and Quakespasm, *unless* you use Baker's solution where it's only done during singleplayer etc.

RMQ uses a new protocol, hence that was simpler for us.

accelerate

Hah. Right, I'll add this to the TODO list. Forgot about that.

i'm a little fuzzy on why this only works with .avelocity though... does this mean that if you set .angles manually, the player could get stuck then? i guess that actually makes sense, since you'd get stuck if you setorigin'ed platforms too. or do you mean the collision breaks if you set .angles manually..?

I'm not sure about this. Try it?

btw, this is baker's work right? the i3d forum thread implies that anyway since he's the OP.

It's a group effort - Avirox did it in Quake-Life (probably based on HL or Q2?) and posted a tutorial on how to do it in QW, a bit later him, Urre, Lord Havoc and me made some testmaps and fooled around with it via IRC, LH added the compiler fix during this phase, later Baker did the conversion of Avirox' tutorial to Netquake with possibly fixed QC originating from Quake-Life, and another testmap (the Rubicon one), and then I remembered what Urre and LH had tried to tell me all along and mixed Baker's version with the info_null method, and fixed up the QC further (keys, spawnflags, linking etc) and made the base-style testmap.

The engine code, I'm not sure, I think it may have originated in one of the old QSG tutorials, but I could be wrong. I didn't follow that too closely.

I think that is roughly it.

the bugs are a little more serious than is intimated. it's possible to walk or fall right through rotating doors if you walk against them while they are moving.
also, the axis of rotation doesn't appear to be very precise as you can see the top edge of the rotating bridge slide around as it goes through it 90 degree rotation.

Which testmap and which mod did you play? The one I posted, or Baker's version?

There is no rotating bridge in my testmap/mod.

http://www.quaketastic.com/upload/files/misc/rmqrotate.zip 

avelocity interpolation on bsp models as well

Step by step :)

I bet Darkplaces has something like this - for us other mortals, a real engine coder would have to do that I think. I only hack engines because no one else does it for me and I'm, er, not completely free in my decision making regarding engines. :-P

Also, it is quite simply the case that you pay a price if you don't want to use Darkplaces or hmap2. You could just switch, you know. /irony 

I bet Darkplaces has something like this

yeah it does. i have a long term map i'm working on with a lot of rotaters and it's gorgeous to watch it start going in DP with the smooth angle interpolation.

Which testmap and which mod did you play? The one I posted, or Baker's version?

oh ok, i somehow missed your version and went to the i3d thread and got that one.

i seems as though this is a more advanced implementation of it as there were none of the problems i saw the first time. (maybe my version of dp is old too... april is a little while ago now).

it's a pretty solid implementation and very very cool.
of course, now i feel like an ass for asking, but could we get player .v_angle rotation when standing on rotaters? ^_^;

i'll see how hmap2 goes i guess. i guess it must be a pretty advanced compiler itself too, so it's at least worth a look. if it works out, i think i may just plug this into my mod. gods, the things that could be done with this... 

Yeah, well, the rmq version exploits a map compiler "hack" that was used for hiprotate, and has to do with setting the origin (combination of rotate_* and a targetted point entity). This might account for some stability, since it's road tested, although I haven't got an idea why. Baker's version ran OK for me, or maybe I don't have the eye for it :-)

This whole hiprotate deal was what Urre and co. tried to explain to me originally. They'd go on saying "you can just use a rotate_banana and an info_null" and I kept not getting it, until recently. :-)

could we get player .v_angle rotation when standing on rotaters?

Yeah, we've discussed this already and I think this might be possible, even if I have to bug more knowledgeable people. I'd like to see this as well.

Right, overall this isn't quite finished yet, but in principle it works. The acceleration/deceleration should be doable, as well as the player view angle rotation and finally the rotating train.

BTW, you can use AguirRe's light program in combination with hmap2 - it's only the QBSP stage that is needed, so instead of Tree/TxQBSP you use hmap2.

It does do a couple things differently, I had trouble when I took two large maps and switched from TreeQBSP to hmap2, probably because TreeQBSP allowed me to make a mistake somewhere... I don't know. Of course in general, hmap2 is also based on id's compiler, so it's not really a world of difference.

It makes BSPs, which is what counts.

And it is actively developed, which is a huge bonus. 

that's one fucked up pointfile.

i'm not even gonna bother trying to sort out that bullshit. :P maybe next map. 

hmm - hmm, yeah, it looks as if hmap2 isn't too friendly towards maps that were built with a different compiler in mind. :-/

Do complain to Lord Havoc, maybe something happens :))

anyway,

accelerate

works now, both with and without reverse spawnflag set. It is indeed sexy - imagine what it'll be like standing on an accelerating brush with the corrected player view angle. The room will spin faster and faster.

You can build centrifuges, or carousels of doom. I need to ask QuakeMatt to add a centripetal force to Gyro O_o

Only a small step until there. For now, it'll just push you around insanely fast, which is also fun.

Will update demo mod soonish. Tree/Txqbsp support would be neat - I can try my hand at it, but I'll probably fail gloriously.

Dying with mouse in hand -> you go to Shub-Niggurath's Pit and become a shambler. 

http://www.quaketastic.com/upload/files/misc/rmqrotate_patch3.zip

map and progs with the acceleration stuff 

ah i see you had to create helper entities for acceleration. i was wondering how you would do that since i ended up having to do the same thing with accelerating movers because of that whole .nextthink i was talking about earlier.

btw, you may want to link the helper entities to the main PUSH entity so that when .blocked is called on it, you can toggle some flag on your helpers to halt acceleration for a moment or something.

anyway, very cool stuff. i just wish hmap2 was more compliant so i could get started now. 

GMTA.

Yeah, I should do the blocked support on the helpers. *scribbles it down* 

btw, Spike told me that with the self.think = SUB_Null; self.nextthink = self.ltime + 9999999; but I don't exactly remember why it has to be like that. I only know that was required to get the rotators to work at all.

I opted for "no experiments" with the helper thing. I'm sure it could be simplified, like having one function to rule all helpers. Hmm, I should do that.

It would probably be half the size if Supa or Lardarse coded it. :-) 

Check the tutorial I posted a few weeks ago for acceleration with no helper ents at all. I'm sure it could be adapted to the rotating entities fairly easily.