[headdie]

I have been thinking of an option that might help make external weapons operate a little more believably and that is to have the an option in the ship table to have missiles move slightly away from the ship model a moment before starting to move forward.  Atmospheric missions would benefit from more expected behaviour and even in space you want your missile to move clear of the hull before shooting off in the distance.

[Dragon]

Using the particle script, you could have the missile spend it's free flight time unpowered and fire it's engine at a few meters distance from the launcher.

[karajorma]

I remember stumbling across a attempt to do this in the code. They'd disabled it because they couldn't get it to work correctly for some reason.

[Dragon]

Interesting. Any chance of re-enabling it?

[Nuke]

it would probibly be easier to do this with the weapon models. when they were originally implemented they had a reload animation where they translated forward along the z axis. it was thought that this would be a good idea as thats the way the missile racks in the freespace universe works. i adapted the feature to work for external weapons, simply by maiking the cargo size of all external weapons 1, and make sure that the missile capacity in the ship table was equal to the number of firing points in the model. this caused the animation to not run.

i dont see it being all that different from translating the missiles down slightly before firing. you would have to place the firing point accordingly. there might be a problem because most people include the pylon in the weapon model. and you would need a separate model for the pylon, or need to include it in the ship model.

[headdie]

it would probibly be easier to do this with the weapon models. when they were originally implemented they had a reload animation where they translated forward along the z axis. it was thought that this would be a good idea as thats the way the missile racks in the freespace universe works. i adapted the feature to work for external weapons, simply by maiking the cargo size of all external weapons 1, and make sure that the missile capacity in the ship table was equal to the number of firing points in the model. this caused the animation to not run.

i dont see it being all that different from translating the missiles down slightly before firing. you would have to place the firing point accordingly. there might be a problem because most people include the pylon in the weapon model. and you would need a separate model for the pylon, or need to include it in the ship model.

the issue with weapon side is if from bank 1 you want the missile to drop strait down and bank 2 you want it to move at an angle a weapon side implementation would be very limiting while on a ship side you can implement it on a bank by bank basis per ship

[Nuke]

what about another paramater for the free flight feature. essentially a free flight vector. currently the weapon normal*free flight velocity is used, but add a free flight vector to indicate the initial path a weapon follows prior to launch. weapons point to the firing point normal but fly along the free flight vector until the end of free flight time, and then carry on as usual. this is of course weapon side. ive always used different weapon classes for internally mounted and externally mounted versions of weapons. this is likely not practical for all mods. actually if we had weapon templates it would lessen the organizational issues, but still counts towards weapon limits.

it would be really cool if you could configure a weapon bank type, like in a table containing settings for various banks, like weapon model animations and other bank related settings (like whether the bank is interneal, external, if its allowed to be rearmed, free flight vector, provisions for destructible ammo, you could do lots of stuff with this), and apply the bank type to each bank in a ship entry. you can configure a bay launch, or a pylon launch. or buff/cripple weapons when placed in certain banks.

[Rga_Noris]

It would be nice to be able to set an absoute vector as well, one not relative to the ship. That way the missile can always drop downward for atmospheric missions.

[Nuke]

what if you try to launch when youre upside down, you could hit yourself with your own missile.

i was thinking of it in terms of a local ejection velocity, you can always apply other physics to missiles in the free flight phase, or perhaps during the whole flight. i dont know what current provisions there are in the game to simulate atmospherics. in my atmo script i just applied physics to weapons as soon as they were spawned. not sure what other scripts/engine modifications have been made since then. no reason you cant apply two vectors either, one for ejection velocity and an acceleration for gravity that changes the velocity over time. rough approximations of physics never look right anyway, i always thing that ggravity is best dealt with in a realistic matter even if you fudge the atmo desnity, thrust, lift, and other variables for playability, and staying within the engines limits.

[Aardwolf]

It would be nice to be able to set an absoute vector as well, one not relative to the ship. That way the missile can always drop downward for atmospheric missions.

If you were going to do that, I think you would want to do it using the built-in gravity feature.

It does exist, right? 

[Nuke]

somone did some landing physics and somone did a gravity script (i remember because i fixed a bug in it). nothing as ambitious as my own script though. too bad i never got the weapons to not crash the game when they hit things. also freespace enforces caps that i want to break, and this causes some phantom forces to manifest.

[JGZinv]

There was also the GravityCube.... that no one attempted to try... *cough cough*

[Nuke]

gravity cube? i hadn't heard of that before.

[JGZinv]

Oh really...

http://www.hard-light.net/forums/index.php?topic=64090.msg1265948#msg1265948

[Nuke]

lol, sounds like a hack.

let me reiterate how easy gravity is as far as physics goes, just apply an acceleration vector every frame. you might cap the total velocity to simulate terminal velocity through an atmosphere, though thats not totally realistic since its possible to do a powered dive for example where you could exceed terminal velocity, its a good enough approximation for a game though.

[-Norbert-]

But wouldn't such a model ignore aerodynamics and always pull the fighter down, no matter the wing form or forward speed?

[JGZinv]

Most new "features" still in use today, were once "hacks."
Those of us not in code work with what we have at the time.

[Nuke]

But wouldn't such a model ignore aerodynamics and always pull the fighter down, no matter the wing form or forward speed?

pretty much. you must counteract gravity with another force, lift or thrust for example. missile can generate lift purely from thrust, but because of their speed, they can also produce non-trivial lift. aircraft have wings for lift, and vtols have lift engines. flight is essentially the balance of four forces, and my solution was to simulate all four accurately while under newtownian physics. drag can be fudged with velocity caps and thrust is already in, so you really only need to simulate lift and gravity. gravity is applying a uniform acceleration vector to all objects in the game.

lift is a little more complicated. its always perpendicular to airflow so if you crossed airspeed vector with lift force vector (in world space) the resulting vector would be parallel your local x axis (in world space), but rotated about airflow z to point in the lifting direction of the wing. angle of attack also plays a role, every degree of positive aoa increases lift coefficient (cl) by roughly 0.11 (this value is common to all known airfoils), and every degree of negative aoa decreases the cl by the same amount, up till the min and max stall angle where it falls off with a nice rounded curve to zero (no lift). here is the basic math:

lift = 0.5 * air density * velocity^2 * wing area * lift coefficient

my script uses a more complicated formula i think. if i were to make a modder friendly lift force feature i would fudge wing area and cl into a single float for each ship, call it lift factor. velocity would be the ships forward speed, and you would probibly want to set atmo density somewhere else (like when you enable atmospherics with a sexp, script, checkbox in fred, whatever). you would also want to specify an aoa range. min aoa to max aoa where lift is stable (my script has another cariable to discribe how rapidly the curve falls off from there, but you can omit this for simplicity and use a fixed curve, something proportional to the aoa range). multiply aoa in degrees by 0.11, and 1 to it, and multiply it into the total lift. so modders only need setup 3 or 4 variables for the ship, and one for the environment. so the math then becomes:

lift = 0.5 * velocity (velocity vector magnitude, not the vector itself) ^2 * lift factor * (1+(aoa * 0.11))

this is (i think my math may be funky) a close enough approximation for lift force. figure out what the direction of lift as a normal vector and scale it by lift. divide (i think) by ship mass to get an acceleration vector to apply. while your doing that apply your gravity acceleration vector as well. you may also want to do some angular stuff like simulate the tendency of an aircraft to resist turning due to drag. but thats another matter entirely, even my script doesnt do that corractly yet.

[-Norbert-]

I always thought that atmospheric flight models would never be in FS2, even more so than shadows, but it seems I was wrong in both regards

[Nuke]

my atmo script has been around for several years. it just has issues that ive been unable to resolve. mainly it breaks collision detection. and weapon impacts cause crashes. but other than that its a pretty accurate flight model. you can get it from my svn.