idea: turn as fast as possible along hyperon thing and then thrust as thrust-direction becomes perpendicular to wanted trajectory vector.

Roughly, though thrusting perpendicular to the current velocity (to turn it toward the desired one) might be better. That is what my algorithm above does. I'm not actually sure which is better, and I think the benefits may depend on the situation. We can simply try both as they are very similar.

Anyway, thrusting perpendicular to the goal (or velocity) has issues once you become pointed in roughly the right direction. Thus, as the velocity vector approaches pointing toward the goal, thrust should shift to speed control rather than steering as steering is no longer needed. My algorithm does exactly this by using the weighted averaging system built into the AI.

Now, if we do not make assumptions when using torque, and want to work with a non-constant torque (due to torsional acceleration)

Constant torque causes torsional (rotational) acceleration. Torque/moment of inertia = rotational acceleration. They are proportional.

Again, don't worry about doing the math. We only need a simple algorithm (like your idea at the bottom, thats the kind of thing we need). We have a physics engine to do all the math for us to see how well different algorithms work :).

]]>I know that the fastest way to make a 3-D directional-change is to start turning in the direction of the required vector/direction, and only start thrusting forwards once the angle from the required direction and your spaceships direction of thrust is less than 90 degrees (otherwise you are thrusting away from where you want to go).

Now, if we do not make assumptions when using torque, and want to work with a non-constant torque (due to torsional acceleration), then we would ideally want to maximal torsional acceleration while turning the spaceship to face the required direction. Unfortunately, if the spaceship stops turning when it is facing its required direction, it will not actually be going forwards, but rather, diagonally (due to its original direction of movement).

Erm, what I'm proposing (separate from the above ideas) is that we can also have a method of swinging the spaceship towards its required direction, swinging past that direction, so we are thrusting to negate any movement that is not in the required direction (like flying into the wind, except instead of a wind, we have a previous direction of movement that we want to get rid of, because it is not in the required direction).

The problem with this is deciding when to right the direction of the spaceship. At which point does a spaceship reverse its torsional acceleration, so that it will swing back in alignment with the required direction at the exact same time of its cancelling all movement/momentum that is not straight-on with its required direction (ie. stop going diagonally, and start moving forwards at the exact same moment that the spaceship's torque becomes zero (stops turning)).

Good grief, I'm trying to draw a diagram, but I have no idea how anyone could do any of the math without quaternions.

idea: turn as fast as possible along hyperon thing and then thrust as thrust-direction becomes perpendicular to wanted trajectory vector.

]]>Yes, the angles (orientations) are 4 dimensional, and are stored on quaternions which basically are how we store orientations and rotation in 3D space. Thats all you need to know. We never act on their 4D internals directly (well, thats almost true. Occasionally I do a few things).

I was thinking on a small scale. I wanted to design this turn for ship-combat, or just to have neat ship responses for changing-directions (a smooth arc instead of "stop, turn, unstop").

Of corse. With stopped not being defined, and having realistic physics, there is really no other choice. The physics wont allow it. Smooth arcs are the only way to go!

You can do weighted averages of quaternions very easily. Just use the SetBetween method I think it's called.

Following your points, the radius of the circle could based on the maximum forward-thrust of the spaceship instead of the speed of rotation.

Yes, assuming it can keep the ship pointed the right direction with intelligent torque control. Constant torque means constant rotational acceleration and thus increasing rotational velocity.

Also, don't ever thing about X,Y or Z, it just makes everything hard. Think in vectors. Then the coordinate system does not come into play.

FG needs loading screens

Never. We will not load! Everything will be super smooth! (thats the plan) The only "load" delay will be at login when the client is waiting for it's first time stamped message.

The not about processing power does not apply as the oversimplified version (which the engine and torque rule will try to model) can not be run directly. The physics (so the engines work) and collision detection etc. will take way more time than the engine control AI, so processor use is insignificant (I think).

once the initial computations are done (some trigonometry and division), then the ships already knows what to do for the next five secons (does not require new instructions for several seconds).

Yes, but it still needs to compute the torques and run the physics so that it actually turns. Even if it knows what it will do in the future, it still has to do it. Also, don't think about computing the flight path, as we will simply be running a rule that decides what to do. It will cause a flight path, but it wont ever be computed.

I will answer the rest of your post soon, I have to go. Anyway, good work.

]]>Craig: I see no distance d.

I meant that the length of the green line will not make θ1 > θ2

Phenoca: no acceleration due to gravity

Craig: This means orbits don't work, and thus it is impossible to leave a ship near a planet (the planet will simply move away or straight into the ship!)

I was thinking on a small scale. I wanted to design this turn for ship-combat, or just to have neat ship responses for changing-directions (a smooth arc instead of "stop, turn, unstop").

Craig: Also, you can divide a pie, but not divide by it. Consider pi (π)

Yeah, pi, not pie :)

Phenoca: rem change in angle required = angle between spaceship's direction and direction of destination, + 90 degrees (because spaceship is pointed towards the centre of the arc that it turned in)

Craig: Angles are 4 dimensional, so adding pi/2 is not really defined. I don't really understand this.

Angles are 3-dimensional?

The reason I'm using simple angles with 2 variables at a time (ie. x and y) is because I have no idea how to do 3-dimensional angles, so I broke things into components (x and y handled, then z handled separately by doing two separate turns to change the ship's direction).

Craig: Same as Ship.Velocity is tangental a sphere around goal.position.

Yes.

Phenoca: 2)there is a way to derive a spherical trajectory using a 2D circle trajectory plus a required change in the z-axis (if assumption 1 is false)

That quote does not make sense to me either. What I'm trying to say, is that:

if the Ship.Velocity is not tangential to a sphere around goal.position, then there is a 3-dimensional arc that the ship can travel in, to change its x, y, and z velocities towards the destination.

By circle, I meant a 2D arc with the end-result of a directional-change changing x and y velocities.

By sphere, I meant a 3D arc with the end-result of a directional-change changing x, y, and z velocities.

Craig: Problem: Assumes that ship has enough thrust to keep the circle's radius to what you intend. This is not always true. Also, more thrust may be available which would allow for faster turning. Also, in a torque based system, there is no max rotational velocity.

I'm assuming that torque remains constant (direction of thrust is always perpendicular to direction of momentum, so that ship is travelling in a circle until thrust stops).

I had meant to add-in the required-thrust assumption.

Following your points, the radius of the circle could based on the maximum forward-thrust of the spaceship instead of the speed of rotation.

Ok, here:

In seconds 9 to 14 of this video, the spaceship is thrusting towards the centre of a circle, in order to travel in an arc, in order to change directions.

A video of the way I visualize space-physics.

That reminds me, FG needs loading screens, multiplayer ability, and bouncing walls, in order to be the pinnacle of gaming :)

Craig: Also, one of the hardest parts (that is very critical) is arriving as a reasonable speed. We can fake it with relative breaking, but that is quite lame.

Well, I had meant for this to be a combat-maneouvre. The reason this turning method is beneficial is because it takes extremely-little processing power, due to the assumption that the velocity of the destination is negligible.

If a small fighter-ship is doing multiple hit-and-run attacks on a larger ship, then all that this method requires is one (possibly two) arcs towards the target spaceship, and the direction-change is complete.

Craig's solution: Determine steering and speed control priorities. Save the orientation of each (as quaternions) along with their priorities (in their AI classes). Those are desired thrust directions.

Whoa! I wanted to learn about Quaternions, but they were too complicated to understand from a casual study!

How are you saving steering and speed as a quaternion? I assume you are modelling this with respect to time?

!!

You can do a weighted average of a quaternion?

Or what did you mean by "do a weight average"?

Craig: The actual flight path that it would cause the ship to follow is roughly what you outlined, and works on same principals, but should be more efficient (quicker), easier to program, more adaptable, and control the arrival velocity.

How often must the flight path be updated?

The reason I proposed a preset "turning-arc" for ships to change direction is because first, it was popped-into my mind, and secondly,

once the initial computations are done (some trigonometry and division), then the ships already knows what to do for the next five secons (does not require new instructions for several seconds).

With what I know (not using quaternions, or how to do a 3-dimensional arc)

For example, the ship prepares for its first arc by rotating, it then thrusts for a certain amount of time (based on speed, torque, and maximum thrust) while maintaining its torque (which was based on speed and maximum thrust), and is now travelling in the correct x and y vectors.

It then repeats the process, turning along the z-axis (like a loop-de-loop) in order to correct for its z vector (because I can't do code for arcs along the surface of a 3D sphere, or for quaternions).

If I spent one-hour figuring things out, I could probably base a 3-dimensional arc, which would be extremely efficient on processing-power, and have an accuracy that increases with respect to the spaceships thrust (a quicker turn).

Ah. Spaceships… I want them to look dynamic. Do funny things in combat, at a fast-pace, while conforming to physics.

Using two 2-dimensional arcs, or one 3-dimensional arc, the spaceship can be travelling in the direction of its target, do a strafe, and only have to update its thrust-instructions when it has completed the strafe.

With a two or three nested if-statements, it would also allow for the spaceship to have its turrets facing the target, once the arc is complete.

*and another if-statement to check if the target has moved further-away during this time, requiring a second change-in-direction.

I like quaternions, I think that they are beautiful, but I don't know how to use them.

If we have a simple equation for processing a spaceship's change in direction, then we can have combat with 40 vs. 40 spaceships.

The reason I'm so stubborn about the method I mentioned is because it requires an insignificant amount of processing power for spaceship thrust (excluding gun-aiming and collision-detection).

However, since the spaceship's direction of thrust is pointed away from its target, this also allows us to make simple assumptions for collision-avoision :)

If the spaceship is not firing while it turns, then this also allows us the server to make the assumption that it knows where the ship will be after the turn is complete, and all the rest of the processing can be graphical-processing by the client.

Now, tell me how quaternions store torque and orientation.

Quaternions would definitely be the way to have accurate physics and direction-changes.

But can quaternions be used to code for other maneouvres, like zig-zagging, and dynamic (environment-based) ship-formations?

Gah, I am arguing. I'd like someone to bring me into the light about quaternions, because while I understand that they are an awesome mathematical equation, I have no idea how Craig is manipulating them to store and analyse mathematical data, nor how much processing-power they require.

I also have high-expectations for inter-fleet combat, since it is only limited by the Physics Engine (which already works perfectly) and the coders (who are very smart).

I visualize random, dynamic combat, with formations flying through each other, smaller ships doing strafes, and capital ships clustering around each other to protect the more vulnerable (or tactically important) ships.

There are meat-shields, damage-dealers, and specialized ships (such as fighters, shield generators, colony ships, and carriers).

The damage-dealers are easy to make ideas for (formations are simple).

The meat-shields just have to protect the damage-dealers, and make decisions based on the direction of enemy-firepower.

The specialized ships, and smaller, faster, cool-looking attack ships need to not have limits to their combat maneouvres.

No matter what AI system(s) is/are decided-on, we should be able to release a new attack-formation every 1-2 months (once the game is in Beta, and the critical bugs are fixed).

Formations should be better than what we see in Star Wars, cooler than what we see in Age of Empires (or any other medieval RTS), and almost as complex as what we see in Battle For Wesnoth (which can become more complicated than chess, once more than two players are in a match).

Sorry for my opinionated views.

]]>The variables that I use are:

x, y, z coordinates of destination

x, y, z coordinates of spaceship

x, y, z component-velocities of spaceship

We can use vectors to keep things simple, as well as dot notation. Goal.Position, Ship.Position and Ship.Velocity

My assumptions are:

speed of destination is negligible

Planets move very fast. Mercury moves about 600 km per second (Earth is about 30 KM/s) for example. If we speed things up orbitally so you can see the (earth like) planets move over days/weeks not months/years, it will be much worse. Also, one might want to send a ship to a moon, a fleet (yours, an ally's or an enemy's) or an astroid.

initial speed of spaceship is greater than zero

Not a safe assumption, but can easily be handled.

travelling the distance d (see diagram) will not affect the angle between the spaceship and its destination

I see no distance d.

the spaceships engines are at the spaceship's centre of gravity

Actually, as long as engines are alined so that the force is toward or away from the center of mass, it is equivalent.

torque can be altered instantaneously (can be changed later)

Ok, so we assume a ship rotation ability, easy enough, and keeps things simpler.

no acceleration due to gravity

This means orbits don't work, and thus it is impossible to leave a ship near a planet (the planet will simply move away or straight into the ship!)

the distance between the spaceship and destination is much, much greater than ((360 degrees / maximum turn rate in degrees per second) * speed of spaceship in units per second) / 2(pie)

We will want to handle other cases, and thus a general solution will be needed, but we can assume this for now. Also, you can divide a pie, but not divide by it. Consider pi (π)

rem change in angle required = angle between spaceship's direction and direction of destination, + 90 degrees (because spaceship is pointed towards the centre of the arc that it turned in)

Angles are 4 dimensional, so adding pi/2 is not really defined. I don't really understand this.

My most important assumption:

Either:

1)the direction of the spaceship's velocity is perpendicular to the direction of the destination

Same as Ship.Velocity is tangental a sphere around goal.position.

or

2)there is a way to derive a spherical trajectory using a 2D circle trajectory plus a required change in the z-axis (if assumption 1 is false)

I don't get it.

My end-product is:

The spaceship rotates for one second so that it is now moving sideways through space

The spaceship is pointed towards the centre of a circle, where 2(pie)*radius = perimeter = (360 degrees / maximum turn rate in degrees per second) * speed of spaceship in units per second

The spaceship turns for time = change in angle required / maximum turn rate in degrees per second

The spaceship is still pointed towards the centre of the circle, and its top, side, or belly is facing the destination.

The spaceship is moving towards the destination, but not really

for example, if the spaceship is travelling in the direction of +x, and the destination requires it travel in the directions -x, -y, -z, then:

1) the spaceship can turn in a circle, correcting its direction of movement to -x, -y

2) the spaceship can turn in a circle, correcting its direction of movement to +x, -y, -z

3) the spaceship can turn in a spherical trajectory (see important assumptions 1 and 2)

4) the spaceship can undergo two maneouvres!!! The first arc will correct x and y vectors, and the second arc will be a circle tangent to the z-axisNumber 3 is too hard for me to program, since I've never learned spherical vectors.

Number 4 will make the spaceship look it is doing the loop-de-loop (silly).Rem Speed remains constant throughout the entire process.

Problem: Assumes that ship has enough thrust to keep the circle's radius to what you intend. This is not always true. Also, more thrust may be available which would allow for faster turning. Also, in a torque based system, there is no max rotational velocity.

I have some trigonometry (angles) and time variables mapped out in my head (spaceship turns during the second before it begins its arc).

Unfortunately, I don't know Craig's equations for the displacement of a spaceship when given a circular trajectory (with radius and acceleration and location of circle's centre given).

There are no such equations. There are no circular trajectories, no centers, just forces and masses.

I think I finally get what you are saying, and I have to say that it is well designed, but (sadly) not how we need to look a the problem.

The proper (in my mind) approach would to handle everything in the coordinate system centered on the destination (yes, that means in motion). Then, everything will be handled with relative velocities. (Basically forcing your first assumption to be true) Then, a single rule (not a step by step process) is needed to determine what to do. Basically, a method that accepts the ship stats, position and velocity, and sets the torque and thrusters. Your method can conform to this, but the way that you are thinking about/describing it does not fit well. Also, one of the hardest parts (that is very critical) is arriving as a reasonable speed. We can fake it with relative breaking, but that is quite lame.

My solution is as follows (assuming a coordinate system relative to destination)

Ship front=Direction in which the ship can get maximum thrust.

Decide to speed up or slow down (based on current speed, max thrust and distance to goal)

Decide desired direction to thrust for steering purposes: Perpendicular to the velocity in the plane containing the velocity and Goal, and on the goal side of the velocity.

Determine steering and speed control priorities. Save the orientation of each (as quaternions) along with their priorities (in their AI classes). Those are desired thrust directions.

Use the desired thrust directions and ship ship front to get desired orientations.

Also include desired orientations for aiming weapons and such. (At later times there will also be desired rotational velocities)

Compute the desired torques for each of the desired orientations and do a weight average

OR

Do a weighted average of the desired orientations and get the desired torque.

For every thruster, if thruster points within pi/2 radians (90 degrees) of the thrust direction then fire at full power.

This system is easily doable and fits right in with the current AI system. It will also allow easy additions of things such as obstacle avoidance, staying in formation, pointing at (and shooting) enemies, compensating for gravity and stuff like that.

The actual flight path that it would cause the ship to follow is roughly what you outlined, and works on same principals, but should be more efficient (quicker), easier to program, more adaptable, and control the arrival velocity.

]]>speed of destination is negligible

Unfortunately this will almost never be he case. Let's say that the "destination" in your diagram is actually the intersection of two vectors.

]]>I've thought of a (relatively) simple way of getting spaceships to change directions, but I don't know Craig's equation for moving along a circle.

The variables that I use are:

x, y, z coordinates of destination

x, y, z coordinates of spaceship

x, y, z component-velocities of spaceship

My assumptions are:

speed of destination is negligible

initial speed of spaceship is greater than zero

travelling the distance d (see diagram) will not affect the angle between the spaceship and its destination

the spaceship's velocity is tangential (same direction) as its "front", so that if it sped-up, the direction would not change

the guns of the spaceship are facing 90 degrees away from the direction of its velocity (thus, guns are mounted on the side, top, or belly of the spaceship, facing away from the spaceship's centre of gravity)

the spaceships engines are at the spaceship's centre of gravity

torque can be altered instantaneously (can be changed later)

no acceleration due to gravity

the distance between the spaceship and destination is much, much greater than ((360 degrees / maximum turn rate in degrees per second) * speed of spaceship in units per second) / 2(pie)

rem change in angle required = angle between spaceship's direction and direction of destination, + 90 degrees (because spaceship is pointed towards the centre of the arc that it turned in)

My most important assumption:

Either:

1)the direction of the spaceship's velocity is perpendicular to the direction of the destination

or

2)there is a way to derive a spherical trajectory using a 2D circle trajectory plus a required change in the z-axis (if assumption 1 is false)

My end-product is:

The spaceship rotates for one second so that it is now moving sideways through space

The spaceship is pointed towards the centre of a circle, where 2(pie)*radius = perimeter = (360 degrees / maximum turn rate in degrees per second) * speed of spaceship in units per second

The spaceship turns for time = change in angle required / maximum turn rate in degrees per second

The spaceship is still pointed towards the centre of the circle, and its top, side, or belly is facing the destination.

The spaceship is moving towards the destination, but not really

for example, if the spaceship is travelling in the direction of +x, and the destination requires it travel in the directions -x, -y, -z, then:

1) the spaceship can turn in a circle, correcting its direction of movement to -x, -y

2) the spaceship can turn in a circle, correcting its direction of movement to +x, -y, -z

3) the spaceship can turn in a spherical trajectory (see important assumptions 1 and 2)

4) the spaceship can undergo two maneouvres!!! The first arc will correct x and y vectors, and the second arc will be a circle tangent to the z-axis

Number 3 is too hard for me to program, since I've never learned spherical vectors.

Number 4 will make the spaceship look it is doing the loop-de-loop (silly).

Rem Speed remains constant throughout the entire process.

I have some trigonometry (angles) and time variables mapped out in my head (spaceship turns during the second before it begins its arc).

Unfortunately, I don't know Craig's equations for the displacement of a spaceship when given a circular trajectory (with radius and acceleration and location of circle's centre given).

**Help!**

Here is a diagram of what I have so far:

The spaceship is in blue, pointing in the direction of the vertice of the blue arrow.

remember that because the destination is so far away, θ1 = θ2

green line is the distance the spaceship travels while turning (and NOT accelerating)

in total, the spaceship travels 270 degrees - θ1 (270 degrees is an arbitrary value based on the spaceships initial direction)

note: if the guns were on the left-hand side of the spaceship, then the spaceship would turn in a circle to the right 180 degrees - θ1

once the required turn is complete, the spaceship stops accelerating, and is travelling towards its destination (if θ1 = θ2).

circle radius (red) = ((360 degrees / maximum turn rate in degrees per second) * speed of spaceship in units per second) / 2(pie)

Remember that this only accounts for x and y directions (or x and z, or y and z).

I cannot due spherical coordinates, so I need help!

I like this method of movement because when the spaceship wants to dodge a projectile fired from the destination (say it is targetting a ship) then the spaceship is in the optimal direction to thrust forwards and dodge this shot (like in the game Asteroids, you have to turn away from an asteroid before dodging).

That was a heck of a post, and I didn't even start any trigonometry.

I'm starting to see that Fragmented Galaxy is a large-scale project.