# Basic Course Plotting Done

Hey Folks! I had another solid prototyping day today, and was able to keep plugging at the flight computer.

Today's work included a fix to the ship projections overshooting or backtracking due to precision errors in the code. I also added code to make the planet projections match the same time steps as the ship course, plus one extra to represent the planet's final position when the ship arrives. (Ideally, at the same place.)

I also added code to make "snap" work when moving the crosshairs around the system. When enabled, the crosshairs snap to the nearest celestial object and track it until something else becomes closer. I also made it work with the "lock" button so the player can lock-in the destination and pan the map without disrupting the course. Part of this work involved making sure the crosshairs snap to the planet's projected position at arrival, and not the current position.

I fixed-up with ship cursor to match projected thrust directions during the trip (i.e. towards target for first half, away for last half). And in so doing, I discovered and fixed a bug that caused the ship to move at a different time rate than the rest of the system. (I was feeding the ship the total current time instead of delta time since last update).

With all that done, we can pretty handily plot various courses to the planets in the system, or just choose points in empty space. We can dial-up or down the number of projected steps for finer/coarser step sizes (useful if something crosses the ship's path). We can also adjust the map's time passage rate to play, fast-forward, reverse, or pause the system and see where things are and will be.

Overall, it's a pretty powerful tool for plotting courses! But now we get to the dirty details.

For one thing, the planet will be moving (and fast!) at the point where we arrive. So simply rolling up to a full stop will mean it either blows by us, or (more likely) we crash into it. Also, everything so far has assumed the ship begins at rest. So executing the plotted course will cause the ship to arrive with the same relative velocity as when it started, which could be any direction or amount.

So the next step is to compensate for this relative velocity difference. In addition to traversing the distance between here and there, the course also has to change the ship to have the same final velocity as the planet at arrival.

The concept here is pretty simple, actually. Finding the thrust needed to change from starting to ending velocity given a time t is an easy equation. And since we know t based on the plotted course, we can just add the course's thrust to the velocity change thrust and voila: a total maneuver thrust that gets us there!

Unfortunately, this simple addition of thrusts means we end up accelerating faster than we should, depending on the difference in velocities we need. If I want to limit ship thrust to 1g, this might result in 2g, for example, violating my limit.

The real solution involves a bit more vector math and solving a system of equations. I.e. finding a thrust and trip duration that solves both the velocity change and trip distance equations. And my brain fizzled out before I could tackle that this afternoon.

Still, this is a fine problem to have! Instead of building rudimentary systems, this is making more complicated systems work together. So I'm looking forward to it.

Now, however, time to rest. Have a good weekend, all!

## Comments

Doesn't that mean, that when the required thrust is too high, the course needs to be recalculated with smaller steps for the ship?

Ran around with a clown mask before it was cool

The step size doesn't impact the course calculation, it's more of a visualization tool. I.e. if the course were a ruler, the step size is the tick marks on the ruler. Could be 2 halves, could be 4 quarters, but it always adds up to a whole. It just controls how many "ghost" ships we see along the planned route.

The "thrust is too high" was a comment on my lazy way to calculate the combined thrusts. The course calculation already assumes maximum thrust to get from point A to B, so any additional thrust needed to arrive at B with the correct velocity violates that limit.

In other words, I can't simply add the trip thrust to the velocity-matching thrust because it may exceed total allowed thrust. And I can't just scale-down the combined thrusts to equal max allowed, because then it might not reach point B in time (trip takes longer).

Dan Fedor - Founder, Blue Bottle Games