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 

There's a 3 where it should be a 2 in the expression for a, I'll get there in the end...

b = 12*( (v / (2*t*t)) - (x / (t*t*t)) )
a = ( (6*x) / (t*t) ) - ( (2*v)/t )


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

I'm not entirely convinced that's going fix the behaviour you described though. I can't see how the velocity can start at anything but 0, since both of the velocity terms are multiplied by at least one factor of k...anyway, try that and see, it might get the velocity to -128 at least. 

No, I see the other problem, there's a bracket in the wrong place in the velocity equation. The entire a term should be multiplied by k, not just the latter half

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

it's definatly getting there. time, velocity and position are all pretty much in sync (off by about 0.3 units) but there is still the problem that the velocity passes the max velocity for a bit before coming back down to the max velocity.

max = 5
it's like: 1, 2, 3, 4, 5, 6, 6.5, 6, 5, done
instead of: 1, 2, 3, 4, 4.5, 5, done

in any case, thanks tons for helping me out here with this. i couldn't have figured this math out on my own. :) 

Does it reach the maximum of 5 at the correct time before it goes over? At the moment, the equations don't have any consideration for a "maximum speed" as such, they are set up just to reach the right speed at time = t. What they do after that I hadn't thought about - I assumed they'd just get faster and faster until they reached the maximum quake speed(2000 units normally). If you want to clamp the speed at v, then you should just check if k > t, and if it is forget the calculations and set velocity equal to v.

There's probably a better design for the original acceleration model so that it goes to zero as the velocity tends to v. Then again, it would probably involve an exponential function, which isn't good for quake - numerical approximations in quake c are expensive operations. I might have a think about that tomorrow... 

In another attempt to change the subject, what's up with Worldcraft confusing textures?

I have "karch1" and "karch1l" (Hi, Kell) in a map but only "karch1l" ever gets used. The map looks fine in the editor but, when I try checking the Face Properties on a "karch1" brush, I always get "karch1l" :| Anyone out there figure their way around this one? 

After some simple renaming, "karch1l" to "karch1_l," all seems to be made right...Does that count as modifying a texture? If so, I should probably get permission (o_0) 

it goes over the max speed before the correct time, then it reduces speed so that it's at the right speed at the correct time. if i were too simply cap the speed at a maximum, it wouldn't move far enough, because it wouldn't get that 'boost' in distance from going over the limit. 

I have "karch1" and "karch1l" (Hi, Kell)

Hi generic

Does that count as modifying a texture? If so, I should probably get permission

Heh, you have my permission to modify the texture. You also have my permission to slap Worldcraft's texture browser :P 

The final velocity shouldn't be thought of as the "maximum velocity", there's no reason that these equations should lead to strictly increasing speed. From what you describe, it sounds like if you evaluate the values of a and b, you'll get a positive and b negative. I should stress that this is only because of the particular values of v, x and t you have chosen. Set v = 200, t = 6 and x = 600 and you'll see not only a constantly increasing speed, but in fact you'll find the acceleration is constant(b = 0). When I get back, I'll post a solution where the final velocity is a maximum. 

Ok, did this in the gap between lectures today.

To make sure the velocity is a maximum at time delta_t, we want there to be no acceleration at delta_t. This is another constraint to the problem, so we're going to add a third term to the acceleration. I'll do using t for the time variable and delta_t as the interval required because it's more natural:

x'' = a + b*t + c*t^2
We can already solve for a in terms of b and c, as we know x'' = 0 at t = delta_t
0 = a + b*delta_t + c*delta_t^2
x'' = b*(t - delta_t) + c*(t^2 - delta_t^2)

Integrate
x' = (1/2 * b * t^2) - (delta_t * b * t) + (1/3 * c * t^3) - (delta_t * c * t)
x = (1/6)*b*t^3 - (1/2)*delta_t*b*t^2 + (1/12)*c*t^4 - (1/2)*delta_t^2*c*t^2

Then you plug in delta_t, delta_x and v to these two equations, and if you still trust my ability to solve these after last night, you get:
b = ((30 * v) / (delta_t^2)) - ((48 * delta_x) / (delta_t^3)
c = 24 * ( ((3 * delta_x) / (delta_t^4)) - ((2 * v) / (delta_t^3)) )

You can then plug these into the equation for x', but I'll summarise both of these things in terms of the variables v,t,x and k:

velocity = ((1/2) * b * k^2) - (t * b * k) + ((1/3) * c * k^3) - (t^2 * c * k)
where:
b = ((30 * v) / (t^2)) - ((48 * x) / (t^3)
c = 24 * ( ((3 * x) / (t^4)) - ((2 * v) / (t^3)) )

For safety's sake I've not substituted the values of b and c into the velocity expression, you're free to do that of your own accord.


Ok, so that's the actual content, the rest of this is just rambling. One nice feature of this is that the acceleration is now a continuous function in the sense that it reaches 0 at time delta_t, which is when you stop applying the velocity equation and fix the velocity constant. If you didn't do this, then it would start slowing down again, in fact going down to negative velocity with no limit. We set the acceleration to 0 so the point delta_t would be a maximum, and it is in fact the maximum positive velocity, but not negative :- ).

My only other comment would be a possible improvement to the scheme if you needed improved accuracy. The idea is this: use the expression for distance rather than velocity(!)
What you do is calculate the point that the projectile *should* be at in 0.1 seconds time(the moment you next think). Since you have the equation in full, this is quite possible. Then, since you know you're going to be travelling at a constant velocity until that point, work out the distance between your current location and that target spot, and use the normal equation for working out constant speed:
speed = distance / time

This velocity should very closely match the calculated one, but because it takes into account the position you actually reached, it'll be better at matching the positions given by x. Will it be perfect?

Well, no, it won't, even if you ignore floating point precision. The problem is that when you tell quake to think in 0.1 seconds, it actually thinks at the start of the next frame which is rendered not less than 0.1 seconds later. This could be different from 0.1 by 1/fps - and in fact this affects everything in the quake world, monster animations, player attack rates. So there's still that extra 1/fps * velocity that you'll overshoot by. The important thing about this iterative method is the next think will take into account the overshoot you performed, so you should only ever have one frame's worth of inaccuracy.

You could even attempt to correct for this factor by assuming that the framerate at the time of the nextthink will probably be similar to the current framerate(in QC the global float frametime denotes the time taken to render the last frame). Of course, there is such thing as taking it too far...

The last, is it only four paragraphs? - aren't actually suggestions you need to impliment, the velocity method you've been using before should be fine if you just use this new formula with it. It's more just me putting some ideas out there on how inaccuracy in quake thanks to the framerate can be handled better. And if you do decide you want the extra precision, do let us know how it goes, most of these thoughts are theoretical... 

My brain don't 'alf 'urt! 

I am making a counter strike mod for quake. And i want to make a new func_ brush for the escape zone for VIPs how would i go about doing this? 

(i need time to digest that...)

in response to 5515:
you could probably just use the trigger_multiple code and change it so that it can be triggered only by monsters (or in this case vips).

however, the question is so general in nature, it's really hard to help beyond that. also, why would you make a counter strike mod for quake? it doesn't seem to make sense, since the original counter strike was for Half life, which itself was an updated version of the quake engine, you're basically taking a step back. just play the HL version. that's just my gripe, anyway. :P

now, on to the math... o.o 

maybe the radiosity used for lighting in the original Half Life makes his eyes bleed and he is looking for something more sedate for his optical nerves.

But, still, Counterstrike ? Just kidding. It could present some interesting AI challenges but the game isn't my cup of tea.