Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Aardwolf on June 23, 2008, 05:42:09 pm
-
I haven't figured out how to insert this into the code myself, so I'm posting it here.
This is in 2D, but adding a third dimension should be a piece of cake.
Ah screw it, I'll do it in 3D:
void Missile::steer(float timestep, Position3D *target)
{
float dx = target->x - x, dy = target->y - y, dz = target->z - z; //Calculate vector from missile's position to target
float distanceToTarget = sqrtf(dx * dx + dy * dy + dz * dz); //Calculate magnitude of that vector
//Find the direction to accelerate in, in the moving reference frame of the target
float dvx = dx * preferredSpeed / distanceToTarget - (vx - target->vx);
float dvy = dy * preferredSpeed / distanceToTarget - (vy - target->vy);
float dvz = dz * preferredSpeed / distanceToTarget - (vz - target->vz);
float inv = timestep * acceleration / sqrtf(dvx * dvx + dvy * dvy + dvz * dvz); //Used to normalize the acceleration vector
//Normalize it
vx += inv * dvx;
vy += inv * dvy;
vz += inv * dvz;
}
The missile attempts to maintain constant speed (and possibly velocity) relative to the target's motion. So it will lead automatically, making it very hard to avoid. I would recommend using a weapons.tbl flag, such as "Newtonian Missile".
What this doesn't do is take into account the heading of the missile. Realistically, the missile would either have to be changing heading rapidly or have a bunch of small steering thrusters. However, since it's FreeSpace, I think we can get by with letting modders put fake steering thrusters on their missiles.
Also, this would go well with an $Accel entry for secondaries, to control acceleration used in the formula.
-
This missile will travel at a speed greater than it's preferredSpeed if chasing a target moving away from it, so collision detection might need to be aware of the missile flag or something.
-
Now get Newtonian ships. :yes:
-
Better than a missile flag, make it a homing option for HEAT, ASPECT and JAVELIN.
-
Better than a missile flag, make it a homing option for HEAT, ASPECT and JAVELIN.
What's Javelin seeking like?
-
That's not really a missile, though. It's more like a ball that follows a ship. Given what you've coded there, it doesn't have to worry about rotating for its main thrusters to face a certain direction; it can use its full acceleration in any direction instantaneously. It actually won't even turn with the current code.
The technology required to create a device that moves like that would probably surpass Newtonian principles, and it's not really what people are gonna think of when they think of 'Newtonian missiles', so I would call it something else. However...I like the idea. I'd like to see some more types of homing missiles than what's there already. Check out weapon_home for the homing code, and vm_vec_* for FS2_Open's built-in math library. Specifically what you're doing looks like it could use vm_vec_sub, vm_vec_dist, and vm_vec_normalize.
-
Are those assembly optimized?
-
Oooh, interesting. This code might help me with the match speed/vector option I want to make for gliding. And ...dare I say... given enough time and thought and work, maybe even AI glide use? :nervous:
WMC is right... this is no mere missile, it's a horrible Unescapable Drone of Doom :D
What's Javelin seeking like?
Javelin locks on to the engine subsystem, and doesn't lock if said subsystem is not in 'sight'. Thus, you get heat seeking (or rather 'engine-seeking') missiles that still need a lock to fire. Javelins are originally from Wing Commander.
-
What's Javelin seeking like?
Javelin locks on to the engine subsystem, and doesn't lock if said subsystem is not in 'sight'. Thus, you get heat seeking (or rather 'engine-seeking') missiles that still need a lock to fire. Javelins are originally from Wing Commander.
I knew it. I was thinking about the Javelin HS from wing commander as I read that :D
-
Now get Newtonian ships. :yes:
all you'd really need is a "force newtonian features" which would turn on gliding permanently for that mission, and also force additive weapon velocity, and any other already implemented features that simulate newtonian physics.
the script approach doesn't seem to work very well. i think breaking of the collision detection only happens if your real speed is higher than your max speed. i learned this while testing the drone missiles i made for the early cockpit demos i put on youtube. i assume you can edit the tables and allow a max speed of like 1000, then hack the script to cap your velocity at 1000, then in theory scripted newtonian would work. i still need to add newtonian torque though, which is something im not entirely sure how to do. also atmospherics could be done. you could make it possible to do reentrys and launches on low gravity planets as well as smal scale orbital mechanics. you couldnt deal with an earthlike scenario because the thrust required for escape velocity would easily throw you to the mission bounds in a heartbeat once orbit is achieved and your out of the atmosphere's drag influence. could do things like supplying boosters that only have enough deltav for for orbit, then make the ships engines an order of magnitude less powerful. or by limiting fuel. of course you could also do planar gravity and atmo (for pure atmo missions), or spherical gravity and atmo (for missions involving orbital maneuvers).
-
I'm somewhat sure that to do the kind of orbital mechanics the engine would need to support a floating point space ergo instead fixed point, "integer" values for position you store this position data with an ever decreasing precision the further you get from your reference point. This float space then collapses into a fixpoint bubble around you to allow precise calculations like collision detection. This is how I-War does it AFAIK.
The problems arise since you have to keep track of a lot of things, and if your shots/missiles etc. leave your fixpoint bubble and interacts with stuff in floating point space very weird stuff can start happening.
....and this would only work for single player, for multiplayer or any scenario where simultaneous events have to occur with great accuracy you'd need to handle several "fixpoint" bubbles at once and do the the coordinate conversion between bubbles with great enough accuracy.
I have a vague recollection that someone already experimented with this, he (she?) was one of the new coders who appeared about 1/2 a year ago. I don't have enough time to go thread diving, but it was mentioned earlier that I'm sure of.
-
Are those assembly optimized?
No, but they are used everywhere else in the code and some of them are defined as preprocessor defines (so there's no overhead from calling the "function").
I know someone was making things more OOP friendly, but I don't know if he's still working on it or what the progress of that is. Regardless, it's a good idea to use the vm_vec_* functions for consistency's sake, they'll be replaced if/when something better comes along.
-
to do full scale orbital mechanics, yes, theres not enough space to do a whole solar system, but a small planet and some moons, or asteroids, can be simulated.
yea there was a thread somone started claiming they wanted to do a large space modification to the engine complete with procedural planetary terrain and alot of cool features. but it turns out the freespace engine would need a major rewrite for it to work. essentially all vectors would contain, aside from the 3 floating point numbers, a set of 3 long integers. each integer vector would represent a sector of space about 100,000 or so meters across. you would to 2 passes of rendering, first rendering all non-local sectors as a background, then local sectors would be rendered. large objects in all sectors would be xformed with integer precision (sence decimal sizes there would be indistinguishable at the ranges associated) and rendered first. objects in the current sector as well as adjacent sectors (if youre near an edge) would xformed (with decimal precision) and be rendered. or something like that.
-
That might have been razorjack (tried to implement a planetary engine) but said it was impossible, or, at best, nearly impossible.