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. 

You may find it useful to read through the QuakeC tutorials on http://minion.planetquake.gamespy.com/index3.html

He covers how to build several different multiplayer oriented game modes in QuakeC. You'll probably get a good grasp on how to approach doing a CounterStrike mod. 

Well its not really counter strike. I am taking quake engine and making and Terrorist vs Counter-Terrorist game. So i have to make my own textures, i have to change the engine a little, need to edit the weapons, i have the models already. So if anyone wants to help me out email me hawkins83@gmail.com 

hopefully you're not getting tired of doing math... hehehe, there is still a problem with it :P

first: there were some brackets missing. i added them in as best as i could figure out, and i have:

b = (((30 * v) / (t*t)) - ((48 * x) / (t*t*t)));
c = (24 * ( ((3 * x) / (t*t*t*t)) - ((2 * v) / (t*t*t)) ));
velocity = vector * ( ((1/2) * b * k*k) - (t * b * k) + ((1/3) * c * k*k*k) - (t*t * c * k) );
(got quake to sub it for me, yay!)

i think you're really close now. the movement is look good, but it goes to much to fast a speed, as well as goes in the wrong direction. i'm guess it's just a couple of bad constants and possibly a flipped sign? i hope anyway...
i'm actually surprised quake can handle all that math... i was bracing myself for some kind of error: zomg, let me shoot grenades already!

i'll make sure there's a big phat thank you in the read me. :P 

I think I've spotted a constant that's wrong, change c to
c = (12 * ( ((3 * x) / (t*t*t*t)) - ((2 * v) / (t*t*t)) ));
Having looked at the graph of this function, I still get the feeling it's not working correctly, I'll have another think. 

...in the Chapters pack, upon returning to the start map once a level was completed the entrance to that level was blocked. Is this a hack? If not, is the code required incorporated into Quoth? If not, might you or necros slip it in...as I'm beginning to toy with an Id base start map. 

it is part of the quoth progs. see the quoth tutorial: mapindex info on how it works. 

necros or kell!!!

http://trinca.no.sapo.pt/why.jpg

monster spawn right away :| and only should when trigger are active!!! any idear? 

because you don't have the right spawnflags set. i see the vore's spawnflags are set to 7, but the trigger_spawn flag is 64.

spawnflag 7 means bit 1,2 and 4 are set, but bits 2 and 4 aren't anything at all. i see the ambush flag is set, so the true spawnflag value should be 65 (64 + 1). 

got it ;) thks!!! 

Cheers, Kell :) (from before) 

...thanx necros 

A lack of understanding on my part...

When sound files are pre-cashed how does the size of the file i.e. 450k or 4.5M or 45M, affect the engine.

The reason for the question is that I have some music that I want to add to a map, and I then thought I would add several pieces of music, which totals about 45M. What bad things might I be doing to the engine that will/may affect the playability of the map.

Any pointers regarding the use of sound files will be appreciated. 

It is a good question as I'd like to add some custom sounds to a future project.
to summarize I'd like to know what are the limitations of engineds regarding sounds pre-caching ? 

I'm not sure about the memory load, but I'd guess that the sounds go into the Quake heap, so you might need to increase heapsize. 45M just for sounds is a bit much ...

As for amount of precached sounds, it's 256 in normal engines, 1024 in mine and possibly even higher in DP. You can use the soundlist command to check current load.

The amount of sounds are protocol limited as with models, so it's not just to raise the limit. 

Thanks aguirRe for these informations !

OYOH, I'm looking for a good (free) wave editor that would allow me to edit / modify / save sounds... I also would like to make .wav "loopable" (i.e data chunk addition). Which tool would you recommend me ? And where to download as well ? ;P 

I like using:

http://audacity.sourceforge.net/ 

Thanks, I have it... but where can I make a .wav file "loopable" ? I still didn't find the option... 

Yup, another lengthy set of calculations from Preach. Feel free to skip to the good bits marked in white : - )

Ok, so I looked long and hard at the algebra, and eventually managed to bash out something that works - in a limited way:

x' = (a * k^3) + (b * k^2) + (c * k)

where
a = ((12 * x)-(8*v*t))/(t^4)
b = ((15 * v * t)-(24 * x))/(t * t * t)
c =(-3 * a * t * t)-(2 * b * t)

Same idea as last time, just with the maths correct. So I tested it out with t = 2, x = 10 and v = 10 and the graph looks just fine. Then I decided to test it with 2, 128 and 64. It doesn't work. So I'm about to go back to the drawing board when...

If you look at the values of v=64, t=2 and x=128 there, you notice that they are the of values x and t if the object had a constant(or "average") velocity of v. So if the object starts at rest, it must spend some time at low speeds. Consequently, any solution which starts at at rest and ends at x must spend some time at a speed above v to keep the average speed at v. So the only solution which never exceeds v is the one with constant velocity.

(exercise for the keen mathmo - prove from the definition of a continuous function and the Riemann integral that a continuous function of the form we require cannot exist!)

So, that doesn't seem too good, but the question does arise - what combinations of speeds, distances and time will allow for a solution? And of these, how many does our current solution allow for?

Well, the first thing we want is for the rate of change of the acceleration to be negative at time t. If it is positive, we've already had negative acceleration and it's going back into positive at this point.

So we look at
6 * a * t + 2 * b
If this quantity is positive then we are not going to get a solution that stays below the final velocity. In terms of the original parameters this gives
4*x - 3*v*t < 0, or v > 4/3*(x/t)

So that's a good condition, x/t is the average speed and if we're starting from 0 we'd better allow the maximum speed to be 4/3 of that. Well, it makes sense that it's some fraction of the average speed, it's much harder to see why it should be 4/3.

So that's one restriction. The other problem is that if you take the final velocity to be too large, the solution will go negative at the start in order to accomodate this - taking a run up if you will. So what's the condition for this to not occur? Well, the acceleration is a quadratic in time, so it takes the value 0 at 1 or 2 points(we've defined it in such a way that k = t is one such solution, some quadratics of course have none). So the problem arises when the other solution is positive, but less than the one we want of k = t.

Ok, so we want to factorise the expression for the acceleration:

x'' = 3*(a * k^2) + 2*(b * k) + c = 0

This could be tricky except we know one root, t:

3*(a * k^2) + 2*(b * k) + c = (k - t)(3ak + r)
= 3*(a * k^2) + (-3*a*t + r) * k - r*t
for some constant r. Hence

r - 3*a*t = b
We want -r/3a(the true root of this equation) to be negative. Plug the expressions for a and b in and you get the condition:
(6*v*t*t - 12*x*t)/3*(12*x - 8*v*t) > 0

Be careful! If you multiply through by the denominator you might think you get v > 2*(x/t). However, if the denominator is negative you must reverse the sign of the inequality when you multiply though. So we require either
12*x - 8*v*t > 0 AND
v > 2*(x/t) or
12*x - 8*v*t < 0 AND
v < 2*(x/t)

Phew, ok, those are the rules for this solution to not have negative acceleration for its duration. It'll still work for any given boundary conditions, but it'll do wierd things like speeding up above the final speed(often not so bad) or going backwards first(probably worse). In a bit I'll post some more about alternative models that are less restrictive, and ask the question "when is there no solution at all?".