Shrugger! Unity!

[keith.lamothe]

Of course, this is all on a 2D plane; if you're not clamping all units to the ecliptic or whatever that gets messier

Why would I do that? The point of 3D is having three dimensions!

I hope you can find a species capable of reacting in a fully 3D environment, so that someone can actually play your game

So...yeah. I'm probably going to spend most of tomorrow experimenting; I doubt I'll be able to make do with placeholder systems when an actual solution seems so close at hand. Any last tips regarding the transformation of your code to something three-dimensional? 

What I wrote doesn't even fully handle 2 dimensions, as it basically only handles turning in one direction.  In 3D you have rotation in two dimensions and such.  Honestly I don't know where I'd start   But you can probably at least make it not do excessively dumb things.

[Draco18s]

Of course, this is all on a 2D plane; if you're not clamping all units to the ecliptic or whatever that gets messier

Why would I do that? The point of 3D is having three dimensions!

I hope you can find a species capable of reacting in a fully 3D environment, so that someone can actually play your game

They'd have to be some kind of bird.  Or fish.

Reminds me that I played (about an hour) of Evachron Mercenary.  3 axis of movement and rotation is a pony.
(Ended up crashing myself into a planet because warp drive :V apparently "slightly away" from a planet sized object is not enough)

[Shrugging Khan]

Fish? Animals, including humans, evolved from aquatic creatures, didn't they?
At any rate, it's supposed to be a strategy/tactics game with OPTIONAL first-hand control of the ship.
Rank progression is planned to be along the lines of

• Coal Shoveller
• Crank Cranker
• Cargo Carrier
• + Spotter
• + Cannon Loader
• + Security Guard
• ++ Gunner
• ++ Engine Vectoring Specialist
• ++ RCS Operator
• +++ Tactical Analyst
• +++ Navigator
• +++ Strike Craft Pilot // This is where you actually get to handle something in first person
• ++++ Fire Control Coordinator
• ++++ Chief Onboard Bureaucrat
• ++++ Subfleet Commander
• +++++ Capital Ship Captain
• +++++ Inspector reporting to the Admiralty
• +++++ Chief Factory Officer
• ++++++ Local Fleet Commander

These are just examples, of course. The player would start out as a lowly cog in the machinery of a ship or facility, then work his way up towards responsibility, with piloting a vessel being one possible task. Almost all of the others would mostly relate to operating machinery, gathering data or giving orders.
This way, a player would have to get to know his (procedurally generated) fleet before actually wielding any authority.

If he isn't KIA, that is. Permadeath!

----------------------------------------------------------------------

That said, I'll probably end up using a mixture of safety margins, approximations and angular-drag-related cheats to make things work until I wrap my head around the actually correct mathematics of the issue. I get a feeling this will end with lots of blood, Quaternions and broken PIDs.
Right now I'm using a magical Flywheel to grant ships limited Angular Drag in exchange for lots of energy expenditure, while having the AI RCS operators do some very suboptimal calculations based on "we can turn roughly THIS fast without getting ahead of ourselves". It's distasteful, and has //PLACEHOLDER written all over it (seriously), but I have to make some flashy things happen to keep my brother interested - can't spend all week telling him to correct my physics calculations.

That's not to mean that the correct formulae are off the hook; this particular affair is simply postponed until I'm back at the university.

[Shrugging Khan]

So the code to determine whether or not to flip acceleration currenty looks as following:

Code: [Select]

float brakeTime = ship.angularVelocity.magnitude / shipInfo.maxRotationAccel;
float brakeAngle = 0.5f * shipInfo.maxRotationAccel * Mathf.Pow (brakeTime, 2);
float angleToTarget = Vector3.Angle(ship.transform.position - targetPosition, -ship.transform.forward);

if (brakeAngle > angleToTarget) {
return true;
} else {
return false;
}It doesn't work yet - at all. The ships keep twisting around like drunk dancers. I'm guessing that maxRotationAccel isn't calculated correctly; but could someone take a look at the method above? Does the formula look about right like that, or might the issue be contained therein after all?

Thankee ~

[keith.lamothe]

So the code to determine whether or not to flip acceleration currenty looks as following:

Code: [Select]

float brakeTime = ship.angularVelocity.magnitude / shipInfo.maxRotationAccel;
float brakeAngle = 0.5f * shipInfo.maxRotationAccel * Mathf.Pow (brakeTime, 2);
float angleToTarget = Vector3.Angle(ship.transform.position - targetPosition, -ship.transform.forward);

if (brakeAngle > angleToTarget) {
return true;
} else {
return false;
}It doesn't work yet - at all. The ships keep twisting around like drunk dancers. I'm guessing that maxRotationAccel isn't calculated correctly; but could someone take a look at the method above? Does the formula look about right like that, or might the issue be contained therein after all?

Thankee ~

Can you put in some debug logging to sanity-check the results of those first three lines?  Particularly angleToTarget.  Do the results make sense?

brakeTime looks fine.  Though bear in mind you don't have to write "Math.Pow(brakeTime,2)", "brakeTime*brakeTime" works just fine.  Hopefully Math.Pow recognizes that case and does exactly that, but if it doesn't the more general-case calculations for Pow are much slower.

Is angleToTarget always between 0 and 360 (not including 360)?

What units is maxRotationAccel in?  How about Vector3.Angle()?

Make sure all angles are in either degrees or radians, mixing them doesn't work so well.  I speak from the experience of doing that MANY times

Also, as I think I mentioned this really only considers turning one way: if it overshoots by much then this logic will just send it around in another full revolution.  You can avoid that by having it run the computation twice: once with maxRotationAccel, and again with -maxRotationAccel.  Of course, that's purely for 2D-plane, so I hope you're at least doing these tests with everybody on the ecliptic or something like that   Get it working in the simpler case, then move to the more complex.

[Shrugging Khan]

Sanity checking is in, and angleToTarget actually calculates incorrectly. Which is funny, because an almost identical formula yields correct results in a different method. I'll just use the values from that latter one.

maxRotationAccel and Vector3.Angle are both in degrees (AFAIK), while rigidbody.angularVelocity is in radians per second. I've added a conversion in the current version of the method above, but it didn't help much.

angleToTarget is always between 0 and 180 degrees.

--------------------

My thinking regarding the three-dimensionality of it was that Flip() would not carry out the full flip, but only slow the rotation a bit, then let the normal RotateToIntercept() take over again. Repeating this process would progressively correct the course. Does...does that work the way I think it should?

Anyways, which line exactly do you mean when you recommend calculating things with -maxRotationAccel instead of maxRotationAccel? Both?

And one further observation: My ships really like to spin around their z axis. I do not know why.

[Draco18s]

almost identical formula yields correct results

Key words, "almost identical"

[Shrugging Khan]

They're getting their data from different pointers, but ultimately they're supposed to be using the same variables 

I realised I was calculating the counter-rotation meant to cancel out the angular velocity without factoring in the radians-degrees conversion. Corrected that. Didn't help. Ships still doing an awful lot of turning around the Z axis 

Edit: Made sure that the gameObject's centre point and the physics' rigidbody.centreOfMass are aligned. Didn't help.

Edit2: HAH! The calculated angle was right after all; it was just displayed as being off because the value to be displayed was being overwritten by another instance of the GUI script attached to a different ship. IT TOOK ME ONLY HALF THE WEEK TO FIND THIS.

Edit3: So the issue with how much force was applied was due to an error in the radians-to-degrees-to-radians-to-degrees-and-again conversion. Huh. Still doesn't correctly calculate when to derotate, though.

Edit4: Turns out the problem never was when to derotate, but how strongly! Just needed to multiply the negative torque with the strength of the rotator device, and presto...it works. A MIRACLE!

[Shrugging Khan]

Following yesterday's burst of genius, I'm stupid again.

How do I calculate the time needed to accelerate and decelerate in order to rotate by a certain angle?

Scenario: Flying roughly towards a target, but possibly too fast. If the ship needs to decelerate - meaning turn around and fire the main thrusters along the velocity vector, which implies a near-180 degree turn - it will first have to actually turn around. The time to turn will have to be factored into the calculations discerning whether or not the time to brake has come.

I'm guessing it'd be something like

Code: [Select]

angleToGo / (0.5 * angularAcceleration)But that's pure guesswork.

[keith.lamothe]

How do I calculate the time needed to accelerate and decelerate in order to rotate by a certain angle?

As before, d = 1/2*a*t^2, so t = sqrt(2d/a) (if I did that right). 

So if you want to turn 180 degrees and have an angular acceleration of 5 degrees thats:

t = sqrt(2*180/5)

t = sqrt(72) ~= 8.49 seconds

Of course, that's to rotate 180 degrees, but at that point you'll have an angular velocity of 42 degrees per second and spin right on by.


So you if you instead target 90 degrees:

t = sqrt(2*90/5)

t = sqrt(36) = 6

So in 6 seconds you'll hit 90 degrees, and then if you switch to max angular decel you will come a stable 180 degree heading in a total of 12 seconds from the beginning of the maneuver.


So overall the time to go from angle start to angle end, assuming an initial angular velocity of zero and an angular accel of acc, would be:

t = 2*sqrt(2*((end-start)/2)/acc)

Or more simply:

t = 2 * sqrt( (end-start) / acc)


Though remember, I should not be trusted with math   I probably made some big boo-boo in there.

[Shrugging Khan]

Thanks again!
I'll just experiment a bit, so we'll see rather soon how much boo-boo is in there.

I assume start-end represents the total angle to be traversed? 

Edit: Obviously, it does. Sorry, not really all that conscious today 

[keith.lamothe]

I assume start-end represents the total angle to be traversed? 

Right.  If going from start to end involves crossing the 360-degree boundary then obviously you'd actually want 360-(start-end) instead of end-start.

Edit: well, it depends on which way you're going I suppose; anyway, that part of the math is relatively straightforward once you break it down into the different cases

[Shrugging Khan]

I'm trying to keep it simple but functional for now. If the AI can turn, brake, intercept, rendezvous and match velocities reasonably well, then I'm quite happy to be able to move on to different subjects - advanced navigation can wait until shipbuilding, group tactics, ship functionality, crew abilities, performance-friendly physics and correct fleet-ship-component-crew-information interactions are done.

Lotsa work 

[Draco18s]

Just don't start doing things like thruster damage and have to calculate your accel and deccel with different max values!

[Shrugging Khan]

Oh, but I do. Effective thruster output is recalculated every time it's damaged, its fuel is changed, or its fired - on account of the mass of the ship changing. Of course, if the crew has no-one tasked with doing these calculations, then the maximum thrust won't be updates in the ship's internal information system and the navigator will be having trouble.

Granted, at present all damage is instantly fatal, there is only one fuel type and fuel isn't actually used up (to simplify testing), but eh - it's all somewhere in the unused code.