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. 

Al would appreciate a link. 

http://www.btinternet.com/~chapterhonour/tut/pusher/pusher1.html this right?

i had forgotten about that. i'll be honest with you though, it kind of went over my head. :S
i guess helpers are just easier to keep track of because they're so much simpler. just set your .ltime high so that the bmodel is active and go to town. :P 

Since the helper stuff works and the helper ents could potentially be used for other stuff (play sounds, for example) I might keep them. 

i just reviewed a map on quaddicted and it brought me back to the map page! cool! ^_^ 

Yeah, I fixed that a while back. There are still duplicate ' though, minor fix but me and motivation... 

How do you get the pointfile data to show in Radiant? 

 

http://kotaku.com/5588678/indie-dev-says-epic-can-fk-off 

http://kotaku.com/5588678/indie-dev-says-epic-can-fk-off 

Hey look, Tim Schafer got publicity from calling industry figures names, maybe I can do the same (Robert Kotick is a prick btw).

Having said that (and despite not having met the man), I seem to have it in my brain that Mark Rein is a dick based on some shit from years ago altho I can't for the life of me remember what said shit was... (any ideas?).

Anyways, surely creating one loyal customer through a relatively small amount of effort/good relations with the public is a good way to go for indie devs, and certainly more human (and more decent) than creating a mass market product aimed at the lowest common denominator and then using an expensive advertising campaign to promote it... (indies can't afford tv slots ;) 

It's a question of scale. For Epic, wooing and converting a single person is a waste of time. For Cliffski, it's worth it. 

Oh of course, that was the majority of point (albeit expressed in an aggy 'I haven't had my coffee yet' way).

But in which case it's probably not the best thing to scoff at when at an indie dev panel discussion...