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?". 

can make your wav's loopable. It's free.

http://www.softpedia.com/get/Multimedia/Audio/Audio-Editors-Recorders/Cool-Edit-Pro.shtml

for small wav's 3Dinside has a small tuttorial.
http://www.inside3d.com/showtutorial.php?id=108 

Yes it is a fre trial version... I'll test ir.. Thanks :) 

OK, I opened a .wav and I tried to converted it into a loop .wav file... Nevertheless, when I try it in Quake (using the Quoth ambient_generalpurpose item) there's a message stating "sound <path/sound.wav> not looped" o_O ..
So, from where comes the issue ? Is the .wav format having an effect on the engine (sampling time is 22kHz, mono mode, loop enabled)? 

this whole thing was so i could make accelerating and decelerating doors like in Doom3. you would specify movetime, acceltime and deceltime.

movetime being the total movement time and acceltime and deceltime taking up chunks of time from movetime (so movetime=8, acceltime=2, deceltime=4 means 2 seconds accelerating, 2 seconds moving at constant velocity and 4 seconds decelrating)

surely the math can't be so complex?? i mean, i'm sure the iD guys are smart, but that seems overly complex! is there some way to fake it without this massive amount of operations? it just seems to me like it's more trouble than it's worth :( i mean, appreciate what you're tyring to do, but i don't want to tie up all your time on this stuff :x

i'll have to look into getting some D3 source code stuff, maybe the secret can be gleaned from there... :S 

no point having 22khz, since quake only supports 11khz, it'll downsample it itself and you're just wasting memory.

i noticed that quake uses different markers for looping sounds. usually music programs use 'sustain' loop markers for looping, but quake seems to use region markers. 

Because the thing there is, you are allowed to control the constant velocity to be anything that you like. Picture(in fact, draw a copy, it'll help the explanation) a trapeseum for the graph of velocity against time, with constant slope upwards for the accelerating portion, constant slope downwards for the decelerating portion, and a horizontal line joining the two. You now need a simple result from calculus to tell you that the distance travelled is the area beneath the velocity curve and the line
v = 0.

So, we calculate the area of this trapeseum. Divide it into two right-angled triangles and a square. The triangles have base acceltime and deceltime, so the area enclosed is 1/2*(acceltime + deceltime)*v, where v is a constant speed that we will calculate later.

The square has base movetime - (acceltime + deceltime) so the area is [movetime - (acceltime + deceltime)]*v. Sum all these areas and we get:
[movetime - ((acceltime + deceltime)/2)]*v = delta_x
So, solve this for v by dividing through.
v = delta_x / [movetime - ((acceltime + deceltime)/2)]

It's not worth doing this calculation every time the door moves, do it once when the door spawns and store it in the door's .speed field.

This gives us the constant velocity for the middle section of the motion, but we still need a simple formula for the velocity at each end. It's what you'd expect:
x'(t) = v * t / acceltime for the accelerating phase and
x'(t) = v * (movetime - t) / deceltime for the decelerating phase.

And that's it, very short and sweet.

So how does it relate to the other problem? Well, imagine that we didn't have the freedom to choose the velocity for the constant speed, but we can join the origin and the first part of the horizontal line by any curve that we like(or any strictly increasing curve if you prefer). Ignore the decelerating phase at this point.

We have to choose the shape of this curve so that the area underneath it plus the area below the constant velocity section adds up to the right distance. We can see that we're limited already as the curve isn't allowed to go above the horizontal line for v, and it can't have negative area. So we've got v*acceltime area to play with, and in theory we can come up with a curve for any area between 0 and v*acceltime, ie distances between 0 and v*acceltime have theoretical solutions.

Now, I think that in theory the area under a function of the form
((a*(acceltime-t))^p + (b*x')^p)^(1/p) = v will take any area from 0 to v*acceltime, for the correct value of p between 0 and infinity. For instance with p = 2 and the correct scaling you'd have the equation of an ellipse through the origin and (acceltime,v), and p = 1 is the straight line solution we've already seen. I'd hazard a = v/acceltime and b = 1 as the right scaling but don't hold me to it.

Anyway, that's all academic really as you'd have to solve for p, which isn't easy under the best of circumstances. QC just isn't going to cut it at all. But it's nice to see it can be done in theory : - ) 

It seems that you need to be able to divide the total time that the door operates into segments. In the secret door code functions you already have an example of this available (first second cues sound, second second the door is pulled backwards . . . etc).

The first part of the problem would be to add a factor that allows you to
predetermine the length of time it takes to arrive at the destination.
If it takes 1 second to reach 64 units then plug in an equation that divides the total number of unit segments that need to be moved and then divides that result by the movetime.

So a door that moves 128 units whose move time is 8 is traveling at a constant of .25 seconds. Once you have a constant, you can plug in variables that will give you the acceleration and deceleration you are looking to add.

The movement code in the secret door function is in this bit of code.

SUB_CalcMove(self.dest1, self.speed, fd_secret_move1);

you'll need to get it to use movetime as a countdown (The loop controling the function would look something like this) a = 0, if a > movetime then stop!, a = a + 1) so you can force it to plug in a change for the self.speed for each segment of the movetime countdown. 

yeah, none of that was the problem. it was just solving the change in acceleration such that it would arrive on time. 

keeping things simple, you would gauge deceltime with acceltime so we can easily balance this factor out of the equation and all we have to deal with is the time of constant velocity.

dt/at

Then you will need to find the difference between the constant .25 with the 2 seconds
of constant velocity divided by the number decel seconds, and add to the dec modifier which you use to decriment the speed in the last four seconds.

so if the basic aceltime unit is self.speed = self.speed + .2 than 4/2, .2/2, the the first variable for the decrement in deceltime will be a convenient self.speed = self.speed - .1.

Now for the second variabl in the decrement equation.

Constant velocity reached self.speed + .4, times this by the number of seconds of constant velocity and you get .8, then divide by number of seconds of decelaeration (4) = .2.

So we add this to the first total and adjust the deceleration speed to self.speed = self.speed - .3 and that will get us there in 8 seconds.