You don't need to modify the sprite, you just need to remove the animations you coded in the QC code.

If you don't use makestatic() in your torches, they will consume more network bandwidth and can generate packet overflows. And if you use makestatic(), your QC animation code will not work. Framegroups solves this problem, by making their animations client-side.

Also, from Fimg's help:
The sprite format used by Quake is the first game sprite format supported by Fimg. However, some of the design ideals of Fimg and a few aspects of the Quake Sprite Format are in conflict. As a result there may be a few things you need to know about Quake sprites before you use Fimg to edit them.


Quake sprites are composed of a number of frames. Each frame either consists of a single, unpaletted image or can be in a 'framegroup' where it is then composed of 1 or more unpaletted images. If the sprite contains no framegroups, Fimg will load the sprite as a simple animation sequence under a Fimg group titled "[no group]".


Fimg was designed to support a more general method of grouping frames where each group is an named animation sequence composed of a number of frames. As a result, if a Quake sprite has any framegroups, it will be loaded differently than previously described, where each 'frame' of the image is treated as a seperate animation sequence group. Each frame will in turn be named "Group X". where X represents the original frame number of the animation.


If Fimg loaded the sprite as a simple animation sequence, the only group will be named "[no group]". The Quake sprite saving routines look for the name "[no group]", and if found and it is the only group present, the animation will not be grouped. Therefore, if you'd like to group the frames for the animation, simply choose Groups->Rename from the menu.


When in a framegroup, each frame has a "Duration" key that indicates the delay for the frame. See the Properties Editor for more details. In addition, all frames have Origin values. See the origin tool for more details about this.


In addition, there are global properties for the file. For clarification, they are:
· Beamlength = Appears to be unused within the engine and is related to Doom style upright sprites.
· Radius = Is normally auto-calculated. If the size of the sprite changes, it is recommended you delete this property so Fimg will auto-regenerate it.
· Synchronous = When auto animating in a grouped frame, should the engine synchronize all instances of this sprite? If, for example the sprite is a fire, having all fire sprites start on the same frame would look ugly and obvious.
· Orientation = How the sprite will orient in game. The only two modes supported by GLQuake are "Oriented" which means the sprite will obey it's orientation and will appear as a flat plane, and VP Parallel, which means the sprite will appear as always facing the viewport.


These can be found by clicking the File Properties button or by clicking File->File Properties. 

That clears up a lot. I'll see through it.

I exported all frames from the sprite back into FimG and it was declared as (nogroups).
All flames turn into one frame, but no warnings,
:P 

Hello, I would like to make flight physics for player in quake. I mean gliding in the air while player is falling, so it shouldn’t be just slowing down while falling, it should be something like paraplane or paraglider physics.
What I want to realise:
https://youtu.be/vJouxKs7T9c
How it can be done in games:
https://youtu.be/w5Es-kXif7k

I use sv_player.qc for working with player physics. Also, I am using dpextensions.qc as I am trying to make that on darkplaces engine.

I found some information and documentation about QuakeC on insideqc but still nothing helped me.

Does anybody knows how to realize gliding physics on quake? 

Maybe one chance for something similar is to find Zerstorer QuakeC devkit and see what the "wings" powerup does.

I tried it once but can't remember what it was like to use it. Is it in any of the Zersteror single player maps? I can't recall, but I'm not too much of a "find every secret" type. 

There are Parachutes and Skateboards in the Malice code.
Maybe a good chance to start.

Malice-QuakeC-master 

lMalice.qc 

i think basically, every frame the player is airborne you want to reduce negative z velocity to a target falling speed, and accelerate forwards up to a max forwards speed.

if you look at the ladder code in rubicon 2 you can see that i'm modifying player velocity whenever player is on a ladder. You can remove the ladder check and add check for onground, and then do your velocity modifications the same way. 

Sure, I heard of Parachute in Malice, but that is not really what I need. I also should work with horizontal velocity and vertical velocity to make dependence between them like in real glider. I don’t need just to “slow down falling” 

...thought wings were in Nehahra. Every time you tapped jump you lurched up a bit and you slowly drifted back down. Kind of like an infinite double jump. 

You could also set player .gravity to something like 0.4 or 0.5. 

What you want is a MOVETYPE_FLY that's slightly affected by gravity, and with lower friction.

I don't know if sv_friction affects MOVETYPE_FLY, or if the aerial friction is hardcoded. 

I thought about things that should be realized so it could work:
1. I should make flight vector. This vector should follow view angle vector but with a small delay. That makes our flight more realistic. Also it allows to set maneuvering.
2. When player falls down he accelerate, when he looks forward he slows down.


I have some suggestions how it can be done:
1. vector fly_direction, float m;
makevectors(fly_direction);
makevectors(self.v_angle);
if(fly_direction != self.v_angle)
{
if(fly_direction_x != self.v_angle_x)
{
fly_direction_x += (self.v_angle_x - fly_direction_x)/m;
}
if(fly_direction_y != self.v_angle_y)
{
fly_direction_y += (self.v_angle_y - fly_direction_x)/m;
}
}

//acceleration
float coef;
//fly acceleration coefficient
coef = ((self.v_angle_x-45)/90);
velocity=acceleration*coef; 

Please help me to translate that into quakeC properly 

Here's what I'd do, roughly:

//convert current velocity into speed and direction
speed = vlen(self.velocity);
olddir = normalise(self.velocity);

//convert angles into a normalised heading
makevectors(self.y_angle);

//add a small amount of the heading to the current direction of travel
newdir = normalise( v_forward*frametime + olddir*(1-frametime));

//preserve the speed we had, but change the direction
self.velocity = newdir * speed;

//reduce the strength of gravity based on how level we are currently flying
self.gravity = 0.1 + 0.9*abs(v_forward*'0 0 1');


Some of the values might need tuning here and there, but that should get you started. Player movetype should be left as default, because we want gravity to apply (subject to the last line reducing how fast we fall. Haven't tested this, so it may be rubbish... 

makevectors(self.y_angle);

should of course be

makevectors(self.v_angle); 

use dotproducts:
upspeed = self.velocity * v_up;
fwdspeed = self.velocity * v_forward;
rightspeed = self.velocity * v_right;
(vec*vec is a dotproduct).

You can then get back to the original velocity vector with:
self.velocity = v_up*upspeed + v_forward*fwdspeed + v_right*rightspeed;

Of course, if you change some fraction of the force exerted on the underside of your glider before reforming the velocity then you'll reduce the effects of gravity while horizontal, and return to normal when facing vertically down.
Of course, that energy should normally go somewhere - if you add to fwdspeed anything you subtract from upspeed then you should get something a bit glidery.
you'll also need to include some friction somewhere, in order to get some terminal velocity. and yeah, the conversion should probably also not be 100% efficient either, nor should it convert ALL the energy.

but yeah, dotproducts are great if you want to compare two directions. trying to do stuff like this without using them is just going to leave it feeling really hacky.
Unfortunately there's no real way to control the camera from ssqc, but csqc can override the camera angles without changing the client's 'desired' angles. you should be able to implement roll that way, somehow. 

Had a go with the code from my post on Saturday, it worked pretty well for a first attempt. I did find that it wasn't responsive enough until I doubled frametime everywhere it appeared. One big tip for testing it - use e1m8. Firstly because its one of the few ID maps with enough vertical and horizontal space to glide in properly, secondly because it's low gravity so it's much more fun!

It's got most of the effects you'd want to see in glider physics - you can dive down to gain speed then level off and carry the momentum forward, and if you look up you'll gain height but bleed forward speed. You can look straight up, and you'll quickly stall then crash to the ground. Also if you collide with walls etc your speed is lost which tends to end the flight pretty quick.

One advanced trick: you can accelerate in Quake while in the air. If you're gliding, strafe left while turning in an anticlockwise circle and you'll gain speed (same principle as bunnyhopping works on). You can use this to offset the loss of speed while climbing, and gain height by moving in a big spiral. 

Hi Preach, yesterday I arrived to my PC and I got an error after compiling your code. May be I have done something wrong. Could you please post a full file with your code so I could test it out? I think that would be useful for all the community. 

Maybe if you post the error you're getting we can help you out ... 

I tried to post it as skeleton code so that you'd get some practice hooking it up. One thing I did unintentionally was to misspell (well, anglicize) a built-in function name, so make sure you change the spelling to normalize. If that wasn't the error that's stopped you, post it like c0burn says and we can suggest fixes. 

Still no result. I try to use this code if no flag on_ground is false but nothing works. 

Hi Reyond. It sounds like it's a bit further on if the compiler error has gone away. What function are you running the code in? I ran it in PlayerPreThink so that it would happen every frame. You're right to disable the code when the player is on the ground, but from your description I don't know whether the code you have is right.

I used: if(self.flags & FL_ONGROUND) to see if the player was on the ground. I also turned the code off while the player was in water using the check if(self.waterlevel) (although that's a detail to add once the basics work.

If that doesn't help, post the whole text of the code you're using and maybe we can spot what else it could be... 

Found an old tutorial from Legion with an Xman version of a FlySimulator. Maybe helpfull as a guide. 

Allright, I found an error. Here is how I use the code:
else // airborn
{
vector fly_direction; vector new_dir; float fly_speed;
float fly_velocity; '
float koef;
/*
if (wishspeed < 30)
f = wishspeed - (self.velocity * wishdir);
else
f = 30 - (self.velocity * wishdir);
if (f > 0)
self.velocity - self.velocity + wishdir * (min(f, sv_accelerate) * wishspeed * frametime);
*/
fly_speed = vlen(self.velocity);
fly_direction = normalize(self.velocity);
makevectors(self.v_angle);
new_dir = normalize(v_forward*frametime +fly_direction*(1-frametime)); self.velocity = new_dir * speed;
} 

Yes, actually it looks a little bit like gliding but I can’t understand how the code works. Why do I use frametime if this function works every frame? How this code affects the gravity (in-game gravity is 100 now). And how can I improve this code to make it work better?

Also, I would like to make it works without changing the standart “800” value of the sv_gravity variable. Is that possible?

Also, thanks to Preach and to everyone who helps me in making player gliding in quake.