half-life rotation and quake2 rotation are easier becuase they support "origin" brushes, which define the rotation point. Without that, we need the "info_rotate" entity.

however, I have a theory that it would be possible to have origin brushes supported in quake simply by adding support to qbsp.

And then you could write your quakec rotation code to take that qbsp change into account (should be much easier -- rotating brushes in quake are totally hacked and becuase all bmodels have their true origin at the center of the world.) 

Preach, i just used your monster spawning code from i3d. Very straightforward. Thanks!

http://www.inside3d.com/showtutorial.php?id=171 

http://members.home.nl/gimli/doors.7z

can't time them to shut, though they turn at the same time. 

This is a video of the problem I have:-

http://www.mysharefile.com/v/2534536/rotate_judder_v2.avi.html

(It's 6meg so if you are on dial-up it's probably not worth it, and my apologies for the 12 secs delay before you can download)

In-game the judder is much worse, at least twice as bad - the video capture program affects the fps so this extract may not come across as anything to worry about.

Both doors are set up the same with the exception of the direction parameters. 

You have your rotation bits slightly mixed up.

I think this is what you want: from the player's point of view whan you walk on the button the two doors open inwards and stop until the second button is walked on (actually, either button toggles the doors).

{
"classname" "rotate_object"
"target" "t10"
"targetname" "right_door"
{
//"0000" "0"
( 16 0 -272 ) ( 16 88 -272 ) ( 16 88 -400 ) DR05_2 384 -128 0 0.25 0.25
( 0 0 -400 ) ( 0 88 -400 ) ( 0 88 -272 ) DR05_2 0 -128 0 1.0 1.0
( 0 88 -400 ) ( 16 88 -400 ) ( 16 88 -272 ) DR05_2 -64 -128 0 1.0 1.0
( 0 0 -272 ) ( 16 0 -272 ) ( 16 0 -400 ) DR05_2 -64 -128 0 1.0 1.0
( 0 0 -400 ) ( 16 0 -400 ) ( 16 88 -400 ) DR05_2 -64 0 0 1.0 1.0
( 0 88 -272 ) ( 16 88 -272 ) ( 16 0 -272 ) DR05_2 -64 0 0 1.0 1.0
}
}
{
//"0000"
"classname" "info_rotate"
"targetname" "t10"
"origin" "0 88 -272"
}
{
//"0000"
"classname" "func_rotate_door"
"target" "right_door"
"rotate" "0 1 0"
"targetname" "door_mover"
"origin" "0 88 -272"
"angles" "0 -90 0"
}
{
"wait" "2"
"classname" "func_button"
"target" "door_mover"
"angle" "-2"
{
//"0000" "0"
( -120 72 -396 ) ( -120 -72 -396 ) ( -120 -72 -400 ) FLOOR01_5 0 -456 0 1.0 1.0
( -64 72 -400 ) ( -64 -72 -400 ) ( -64 -72 -396 ) FLOOR01_5 0 -456 0 1.0 1.0
( -64 -72 -400 ) ( -120 -72 -400 ) ( -120 -72 -396 ) FLOOR01_5 -8 -456 0 1.0 1.0
( -64 72 -396 ) ( -120 72 -396 ) ( -120 72 -400 ) FLOOR01_5 -8 -456 0 1.0 1.0
( -64 72 -400 ) ( -120 72 -400 ) ( -120 -72 -400 ) FLOOR01_5 -8 0 0 1.0 1.0
( -64 -72 -396 ) ( -120 -72 -396 ) ( -120 72 -396 ) FLOOR01_5 -8 0 0 1.0 1.0
}
}
{
"wait" "2"
"angle" "-2"
"target" "door_mover"
"classname" "func_button"
{
//"0000" "0"
( 112 -72 -396 ) ( 56 -72 -396 ) ( 56 72 -396 ) FLOOR01_5 -8 0 0 1.0 1.0
( 112 72 -400 ) ( 56 72 -400 ) ( 56 -72 -400 ) FLOOR01_5 -8 0 0 1.0 1.0
( 112 72 -396 ) ( 56 72 -396 ) ( 56 72 -400 ) FLOOR01_5 -8 -456 0 1.0 1.0
( 112 -72 -400 ) ( 56 -72 -400 ) ( 56 -72 -396 ) FLOOR01_5 -8 -456 0 1.0 1.0
( 112 72 -400 ) ( 112 -72 -400 ) ( 112 -72 -396 ) FLOOR01_5 0 -456 0 1.0 1.0
( 56 72 -396 ) ( 56 -72 -396 ) ( 56 -72 -400 ) FLOOR01_5 0 -456 0 1.0 1.0
}
}
{
//"0000"
"angles" "0 90 0"
"origin" "0 -88 -272"
"targetname" "door_mover"
"rotate" "0 1 0"
"target" "left_door"
"classname" "func_rotate_door"
}
{
//"0000"
"origin" "0 -88 -272"
"targetname" "t10"
"classname" "info_rotate"
}
{
"targetname" "left_door"
"target" "t10"
"classname" "rotate_object"
{
//"0000" "0"
( 16 -88 -272 ) ( 0 -88 -272 ) ( 0 0 -272 ) DR05_2 -64 0 0 1.0 1.0
( 16 0 -400 ) ( 0 0 -400 ) ( 0 -88 -400 ) DR05_2 -64 0 0 1.0 1.0
( 16 0 -272 ) ( 0 0 -272 ) ( 0 0 -400 ) DR05_2 -64 -128 0 1.0 1.0
( 16 -88 -400 ) ( 0 -88 -400 ) ( 0 -88 -272 ) DR05_2 -64 -128 0 1.0 1.0
( 16 0 -400 ) ( 16 -88 -400 ) ( 16 -88 -272 ) DR05_2 0 -128 0 1.0 1.0
( 0 0 -272 ) ( 0 -88 -272 ) ( 0 -88 -400 ) DR05_2 384 -128 0 0.25 0.25
}
}

If you move your existing doors, buttons and entities out of the way and then save the map, you can then copy and paste the above straight into your map file, it should work.

The func_rotate_door is not the door but the entity that causes the door to move. The door itself, the bit that you see move in the game, is called rotate_object.

I've copied this from the map file I just created based on your sample, so it is not in any sort of order but once you see it in the editor it will probably make sense.

Let me know if this is OK but if not, I can always e-mail the map to you. 

By 'inwards' I mean that the doors open away from the player. 

half-life rotation and quake2 rotation are easier becuase they support "origin" brushes, which define the rotation point. Without that, we need the "info_rotate" entity.

however, I have a theory that it would be possible to have origin brushes supported in quake simply by adding support to qbsp.

And then you could write your quakec rotation code to take that qbsp change into account (should be much easier -- rotating brushes in quake are totally hacked and becuase all bmodels have their true origin at the center of the world.)

What?! that'd be... well, awesome. i would absolutely love to know how this is done. :o 

thanks for your replacement of the map.
it works better now.

I saw your question, and as I'm also working with a hipnotic.qc I wondered why you couldn't get your doors open similair. So I compiled this map as explain.

But in your avi I understand the problem. Seems as if one of the func_rotate_door and info_rotate won't correspondent.
As if they are not on the same axe, but I think that was also the reason of your question.

Odd, Can't think of something else.
Maybe the Paroxysm mod tutorial can help, although I couldn't make it work. 

OK, I can see what's wrong.

The info_rotate entities should be unique to each door. So, the "targetname" "t10" needs to be changed to "targetname" "left_info" on the info_rotate for the lefthand door, and to "targetname" "right_info" on the info_rotate for the righthand door. Then make the left and right rotate_objects target their respective info_rotates.

No judder, super smooth.

If this is a little confusing, I can send you a working example. 

but this has been pissing me off all day...

acceleration = ((v*v) - v) / ((2 * delta_d) - delta_t);

v is final velocity

this should give me an acceleration that would accelerate an object to v in delta_t time, simultaneously making it such that it attains those two criteria after moving delta_d distance... right?? 

just regarding the function, it is not consistent in term of units

In extenso:

acceleration should be in m/(s^2)
delta_t is a time in s
delta_d is a distance in m
v is a speed in m/s

So I heavily guess there is an error in the math: where did you pick up this function ? 

... to calculate acceleration surely you need to know the change in velocity, not just the final velocity. Therefore, I would expect to see a v1 and v2 in there somewhere.

But what do I know? 

You are rigth ;) 

Woo, some maths to break wrath's scrollwheel with.

I'm guessing you want a constant acceleration that will take an object starting at rest to a position delta_x at time delta_t with velocity v, where all three of these are constants you wish to specify. Sadly, that isn't going to be possible, one of the three will be beyond your control.

Let x(t) be the position at time t.

x''(t) = a (constant acceleration)

x'(t) = a * t + v(0)(integrate up)

Starting from rest, we get that v(0) = 0
x'(t) = a * t

So now we can calculate the required a to reach speed v at time delta_t

v = x'(delta_t) = a * delta_t
a = v / delta_t

But now we have specified the entire system, as we only had the parameter a to vary. So integrating a second time we find
x = 0.5 * a * t^2 + x(0)
so substituting
delta_x = x - x(0) = 0.5 * (v / delta_t) * delta_t^2
= 0.5 * v * delta_t
Which is what you'd expect if you consider the 'average speed'.

So, what can you do? Well, we need to vary the acceleration over time in some manner, and the easiest way to do that would be a linear acceleration over time.

x''(t) = a + b * t

x'(t) = a * t + 0.5 * b * t^2 + v(0)
(integrate up)

Starting from rest, we get that v(0) = 0
Substitute v, delta_tand rearrange:
v / delta_t = a + b * delta_t (1)

Go back to the expression for x'(t) and integrate again:
x(t) = 1/2 * a * t^2 + 1/6 * b * t^3 + x(0)
Substitute for delta_x, delta_t and rearrange:

delta_x / delta_t^2 = 1/2 * a + 1/6 * b * delta_t (2)

Now, we have simlutaneous equations for a and b in terms of our three constants, so we eliminate a
0.5 * (1) - (2) gives:
b = 3 * [v / 2 * (delta_t^2) - delta_x / (delta_t^3)]
and then from 1
a = 3 * delta_x / (delta_t^2) - v / 2 * delta_t

Plug those values into the original acceleration formula

x''(t) = a + b * t

That should do it. It's by no means the only solution to the problem, the choice of a linear acceleration was arbitrary. The sum of any two independent functions of t would work, but that's probably more complicated than necessary. 

Nice demonstration... Err BTW, are you a math teacher ?? 

hehe, we just covered this in multivariable calculus :) 

.. I saw that many years ago in University.. it was in... hmm.. 1992 .. wow... already 14 years... OMG, I'm old !!! 

I'm just a maths student who does tutoring occasionally. I always jump at the chance to put it into practice on here though... 

i knew not doing calculus would come and bite me in the ass one day...

*sigh* i didn't understand half of what you put up there, but i'll be attempting to plug in your equation you put in...

just to check, is it: x''(t) = a + b * t or x''(t) = (a + b) * t ? 

x = delta_x (constant)
t = delta_t (constant)
k = current time (from 0 to oo)
v = max speed (final velocity)

i have:
acceleration = ((3 * x/(t*t)) - (v/2 * t)) + ((3 * (v/2 * (t*t)) - (x / (t*t*t)))) * k

then i set velocity via:
velocity = normalizedvector * acceleration * k

is this the wrong way to do it? is there a way to go directly to velocity without having to do acceleration before hand? am i just too stupid to comprehend this (lol)? :P
i think imma be taking calculus next year... 9_9 

It is x''(t) = a + (b * t)
The formula for acceleration you have there is almost correct, but the second 3 is in the bit of the brackets, and a few other things are bracketed ambiguously. Both of these things are probably my fault, so here's the corrected, unambiguous notation:

acceleration = ((3 * x/(t*t)) - (v/(2 * t))) + (3 *( (v/(2* t*t)) - (x / (t*t*t)))) * k

So that's all correct now, and will give you the exact acceleration you need. But...

It's not the way to do what you want. The rule
velocity = acceleration * time
is only true when acceleration is constant. The proper way to treat it is that velocity is the integral of the acceleration with respect to time. If you've not done calculus that won't mean anything to you, but don't worry about that for now. The integral of
a + (b * t)
is
(a * t) + (1/2 * b * t^2)(here treating t as time, not the delta_t constant).
This expression gives you the velocity you want without having to think about the acceleration. So plugging the values of a and b into this gives(switching back to your notation x,t,k,v)
((3 * x/(t*t)) - (v/(2 * t))) * k + (3 *( (v/(2* t*t)) - (x / (t*t*t)))) * k * k

Then multiply the normalised vector by this quantity and you're ready to go.

A final warning on accuracy. I'm guessing you're doing this in a quake mod, and that you're going to be changing the velocity of the entity every frame/think cycle. If you are doing that, it's not going to be 100% accurate. These calculations are a kind of mathematical ideal where you imagine the velocity changes perfectly smoothly. If it only changes every 0.1 seconds, it's going to cover less ground that it would have in this model. Quake doesn't support anything else natively though, but if you need higher accuracy than this, just ask. It's a more interesting problem, at least. 

yeah, i suspected there would be inaccuracies, since, yes, i'm only setting velocity every 0.1 seconds. i'm probably going to just make a check each time and if the discrepancy is over a certain threshold to just reset the origin to the correct position.
once i can get this going to see how big the 'jumps' will be and how often the position will need to be corrected, i'll be able to judge if furthur accuracy is needed.

i'm still having problems with the velocity though.

when i watch the speed, it seems to dip slightly over the max speed, then lowers back to max speed (in this example, 64), so it'll go to about 66.8 or so, then go back to 64.
also, it still doesn't travel the proper distance in the alloted time, in this case, it's a little less than 32 units short.

if you want some numbers, here's what i'm testing with atm:
t = 2
x = 128
v = 64
k = 0 to 2 (in this case in 0.1 increments)

at the end of 2 seconds, it's only moved 96.3 units (so 31.7 units short of the mark).
this seems to be quite a large discrepancy, more so than i would have thought would be the result of setting velocity every 0.1 seconds. i tested with setting to 0.01 seconds (with host_maxfps 100) and the result is identical. 

Does anyone know of a cut-scene module for Quake1SP apart from the Custents one? 

Yeah, that's probably because I'm a muppet and can't do simultaneous equations. So the expressions given for a and b are wrong by a few constants. If you solve them correctly, you get
b = 12*( (v / (2*t*t)) - (x / (t*t*t)) )
a = ( (6*x) / (t*t) ) - ( (3*v)/t )

Plugged into the expression for velocity, that gives you:

velocity = (( (6*x) / (t*t) ) - ( (3*v)/t ) * k) + 0.5*12*( (v / (2*t*t)) - (x / (t*t*t)) )*(k*k)

Obviously 0.5*12 can be simplified, but it's clearer where the terms come from like this. I'd expect maybe a few units out, but certainly not 30, if it keeps doing that I'll take another look. 

using the new eqtn, it now starts with a speed of 192, decelerates to 0, then goes to -192 in the 2 second span. o.0

sorry to do this to ya, man... o.o