I tried flying to the moon as quickly as possible, so I accelerated up to the halfway point, then flipped and decelerated.

That's all I do, only it's usually interplanetary distances for me. The chances against hitting the target planet in that scenario are literally astronomical so I use the autopilot to aim the ship, then use set speed. When flying to something as close as the Moon, I advise pointing your ship not directly at it, but as close as possible. When travelling to a planet with this method I arrive somewhere near it then use the method again to get closer. I usually engage the autopilot for the final approach and docking. This uses a lot of fuel, but you can get to a destination quicker than the autopilot. If you overshoot, note the distance at which you stop and do it again.

Surely there is a more scientific method than suck it and see?

i experienced similar.

but i guess we have to take two additional factors to account:

1.

you approach to a guessed halfway point i.e. the distance is shown as 10.5 AU, x.5 AU that's even quite a distance.

theoretically one assumes if i flip the ship at a distance of 5.25 AU it should work, but i guess x.x5 isn't shown and it gets rounded up to x.3 or down to x.2 and you have a slight error,

but still 0.01 AU is quite a distance (1'495'978 km ~ 1.5 million kilometers that's not nothing)

2.

one also has to take to account that you are, how far ever (resp. until you reached the equilibration point) from the central star or "gravpoint", under influence of it's gravital field, that's just a slight force but measured on 10AU

it's a force witch has a influence on you course and also on the relative speed to the "gravpoint" (star).

we can assume that the "turning point" isn't exactly halfaways, resp. half of the way and you overshoot.

when decelerating this force still pulls on your ship in direction of the "gravpoint", which for certain means you would have to deccelerate by the amount of the force earlier.

also the effect of the gravital force gets stronger as closer you get to the "gravpoint" (cubic or ^3).

i guess to calculate that get's difficult, you would have to know exactly how strong this force is in this system with this course at this timepoint, inclusive the fact that the force gets stronger as closer you get.

your course to it would also play a role.

a passing by to a large body such as a gasgiant dwarf star or a star (sometimes you pass the central star to reach the target) will have influence on the course and speed as well, usually it will speed you up,

depending on how you pass this object (let's say a "unwanted" sling shot).

ever tried a sling shot? i mean just for the fun of it, it doesn't have to be a calculated one, just do it, fly as close as possible to a star and let your ship get accelerated by gravity only,

once you reached the escape velocity you get thrown out in space with exact this velocity. this could be very fast and under certain conditions you find yourself in "no time"

hurled from sun to jupiter, as example and just to show how strong this force is.

we can assume that any passing by to a heavy mass object will accelerate your ship.

if we take all this to account, the slight error because of rounded numbers and the influence of heavy mass objects it get's obvious that calculating of the turning point isn't easy.

and sorry i neither have a better idea as marcel, as to experience it, i point directly on the object but i turn usually 0.1 to 0.5 AU earlier as thought, still i overshoot sometimes and sometimes

i arrive ~1 AU "to early" (i play often without autopilot, if you would start my version of the game you have no autopilot, sometimes you can't even fit one).

in your specific example "earth to moon" one would assume it would have no influence because the mass of moon is little.

i can't tell you how strong this influence will be, but it's never 0 (0 doesn't exists for speed and distance, only parts of 1 and even the infinite part of one doesn't equals to 0).

if that all would be so easy a recent space vessel wouldn't have to orbit the moon before it can take course on the landing target.

it's under recent conditions wise to let the vessel get caught by the gravity of the object instead to accelerate to it.

i'm pretty sure else they would overshoot the same.

however, the force is still strong enough (how little ever) to have influence on the "point of no return" or for pioneer "point 0" and it will never be exactly halfway.

even not if the object is as tiny as phobos.

another problem i see in the "relative speed to", because as soon you leave the frame for i.e. earth the relative speed is measured to "system", as soon as you enter the frame of i.e. moon

the relative speed is measured to moon.

for certain maneuvres i.e. if a spacestation is set as low as possible in orbit the station "moves" quite fast and to reach the frame of the station is then pretty difficult,

because you have to "hunt" the station with i.e. 100km/sec (rel. to the planet) but as soon as you reach the frame of the station 100km/sec is way to fast and you have nearly no time left to deccelerate before you leave the frame of the station.

similar, if your set speed was relative to "system" and soon as you enter the frame of "body x" yor relative speed is way to high for "body x".

the result is a overshooting (especially if the time accel. is high).

example of a geostationary orbit and a "closest possible" orbit:

(has no relation to your Q, but i post this here because prob. someone will find this of interest)

CustomSystemBody:new('Jobs Spaceport', 'STARPORT_ORBITAL')
inclination(math.deg2rad(0))
semi_major_axis(f(272903,1000000000)), -- orbital period ~1day ~geostationary (rel. to earth)

CustomSystemBody:new('Gates Spaceport', 'STARPORT_ORBITAL')
inclination(math.deg2rad(90))
semi_major_axis(f(51163,1000000000)), -- closest orbit (rel. to earth)

the code shows also which settings get accepted by a spacestation, the rest has no influence

(except it seems we have population now for stations, would that mean "life" get's even accepted by a station? or is it simply bound to system or parental bodies pop.?

however it's not of interest for this example)

with "seed" one could change the model of the spacestation

"inclination" influences the inclination of the orbit relative to the aequator, a station can orbit over the poles i.e. (inclination 90°, 180° equals again to 0°)

"eccentricity" is obvious, it's the eccentricity of the stations orbit

"semi major axis" is what you need if you like to make a station (almost) geostationary

(almost because it's not possible by the rounded data to get exactly to one day, it's a estimated value and i tried to get as close as possible

to the point where it changes from 0.9 days to 1.0 days. practically it can never be exactly geostationary, slight corrections will always be needed after some time,

else satellites wouldn't loose their orbit after some decades. of course this could be calculated as well, but i don't make myself a blown head just for something

which isn't precise anyway)

"rotation period" (daylength) has absolutely no influence on a station (still all stations contain this value, whatever the one who made this thought, this can't work)

just think right "rotation period" means how fast a object rotates along the own axis, for a station this is set in the specs of the station.

"rotation period" has no influence on how fast a body orbits around the parental body.

this is proper because the only way to control the orbiting speed of a object is the distance (semi major axis) and its mass.

likewise our orbit of ~365 days around sun is bound to the distance 1AU and the mass of 1EM.

(stations have "no mass", some 100'000tons isn't to calculate, we have 9 cyphres after the floating point that's the maximum of precision,

0.000000001 EM ~ 60'000'000'000'000 tons, i hope i made no floating point error, besides "fixed 1,1000000000" is exactly the same,

a higher precision isn't to reach, any cyphre more as "9th" behind "1" will be disregarded)

"orbital phase at start" would work for stations to, it won't make a sense here but look at the example below

---

because this is a "spoiler" i add this "irrläufer" setup,

the station covers the distance to the kuiper belt,

i used here "orbital phase at start" to set the station at it's farest point at start of the game.

"eccentricity" is set to the maximum which is allowed.

the distance of the station will range between 91km! and 1000 AU (to sol)

the orbital period is 1200 years!

local kuiper = CustomSystemBody:new('Kuiper', 'STARPORT_ORBITAL')
inclination(math.deg2rad(0))
orbital_phase_at_start(fixed.deg2rad(f(90,1)))

i guess in reality the station would leave sol at its farest point, since it passes over the equilibration point.

of course one could use this to simulate a comet,

try, i await results for "halley"

i will see if i find the expression someone made once to calculate "point 0" for FE2, the physics are the same the expression should work more or less even for pioneer.

however, halfway can't work.

---

we had in the beginning a different measuring of "relative speed to".

the relative speed to "body x" was used as soon as you selected "body x"

it's solved now by relative speed to "body x" is used as soon as "entering frame of body x".

which one of both makes more sense or is more accurate i can't tell.

hmmm... i guess the old system has made some sense, but i'm not sure if it's accurate.

but it looks to me as it wouldn't matter?

if that is true the old method would be better for manual flight.

Thanks for the reply. 

However I was hoping for a simple equation that would give a deceleration point by feeding in acceleration of the spacecraft,  and the gravity of the Earth and Moon.

How does one determine the direction of rotation of a star when performing a sling shot?

This might be helpful:  http://www.projectrho.com/public_html/rocket/torchships.php

Although treat those as approximations, since you burn a whole lot of propellant, so your acceleration will increase over time.

good link,

the site has grown since i last visited it

what i remembered was simply the FE2 manual.

excerpt from the FE2 manual:

 

MECHANICS OF SPACE FLIGHT

==========================

FLY BY WIRE

As starship designers through the ages have found, space craft have so many

potential  degrees  of  freedom  they  are  impractical for a mere human to

control  to  the full unaided.  Logically a free flying combat craft has at

least  five  independent  directions (or vectors) to control, Those vectors

are:

1. Facing vector (unit magnitude) F

2. Velocity vector V

3. Thrust vector T

4. Camera viewing vector C

5. Weapon vector W

It  is  clearly  logical  to  combine  some of these, but the more they are

combined,  the more functionality is lost, Faulcon de Lacy (and indeed most

ship  manufacture)  combine  (1),  (4)  and  (5)  and  control  (2) and (3)

automatically,  leaving  the  pilot to control only (1), with the option of

disabling  the  automatic control of (2) and (3) when necessary.  Even this

seems  a  handful  for  a  species  evolved  to move in only two and a half

dimensions  (up  and down are very much secondary to north, south, east and

west).

The  pilot  is assumed to have a desired velocity vector D along his or her

facing vector, the magnitude of which is the desired speed s they have set.

Hence: D = sF

      and thrust to achieve velocity D T = mf (D-V)

      where f is a factor chosen for fuel efficiency

      and m is the mass of your craft

A  maximum  value is given to f (about 1).  to avoid wasteful thrusting and

possible oscillations.  This is why your craft will slowly settle down over

the landing pad even with a zero set speed.  At higher speeds the limits of

the  power  of  the  thrusters  effectively  restrict  the value of f.  The

desired  thrust is resolved into components along each of the ships working

thrusters and if any of the these cannot provide sufficient thrust then the

value  of f is reduced appropriately (preserving the direction of thrust is

more important than its magnitude).

FRAMES OF REFERENCE

The  problems  of  the  fly-by-wire  technique are further complicated when

considering the frames of reference in which velocities are measured.  When

a  vehicle  moves  slowly  along a street, say, the driver does not want to

know  that  both  the  street  and  the vehicle are moving sideways at many

thousands  of kilometres per hour (due to the velocity of the planet around

the  star, and the rotation of the planet).  Indeed, if the vehicle were to

face  the  way  it  is  travelling, then its motion along the road would be

almost irrelevant.  What the driver wants is to face along the direction of

travel  in  the  frame of reference of the planet, which is both moving and

rotating.

Hence  D = sF + R

       where R is the velocity of the frame of reference

       and ideal thrust T = mf ( D-V )

       T = mf ( sF + R-V )

Your  on  board computer automatically selects the body you are most likely

to  want to define a frame of reference for your motion.  This is usually a

planet  or  moon,  but  can also be a space station or large ship.  It also

decides  whether it would be more intuitive to use a rotating frame or not.

For  space  stations,  it  is  only sensible to use a rotating frame in the

docking  tunnel  otherwise your ship continually thrusts to attempt to move

in a circle in time with a similar point on the station.

CHOICE OF FRAMES OF REFERENCE

The  body is used to define your current frame of reference is shown on the

bottom  right  of  your  head  up  display  this  is  chosen by a weighting

function.   For  planets  and  stars  this  is based on mass, thus a star's

sphere  of  influence  generally extends way beyond its planets.  For other

bodies it is based on their dimensions.

You  may  notice  your  ship's  engines  suddenly starting to thrust when a

different frame of reference is chosen.  This is not a fault with your ship

but  is because your set speed has suddenly appeared to change as it is now

measured relative to the new body.

the main difference to the recent pioneer is, that for pioneer's "fly by wire" the "relative speed to body x" is used as soon as you reach the frame of "body x", while in FE2 it was as soon as you selected it as a target.

besides i really guess you don't have to calculate it, to my own surprise the results of a little test flight i made right now was good and i "stupidly" used half of the way.

the game was a pioneer alpha30 and the ship a weak shuttle (sort of),

the first trip was from mars to pluto, where i let the autopilot set curse and speed, since the ship has a rather high fuel consumption resp. a very low thrust the autopilot flipped the ship quite early,

the rest of the trip i made in free fall until excactly the difference between start and the point the autopilot flipped the ship.

engaged engines and set speed to 0 and finally arrived 0.25AU to "early" which isn't bad, the difference of 0.25 reflects the extra way i needed for the curse correction.

of course the autopilot did the job here, but i just wanted to see if i can depend on time(way) to accel = time(way) to decelerate, which is the idea behind.

my second trip took me from earth to moon, like in your example and it worked out fine,

the ship was again the low specced "m.c.u" and i only accelerated up to 100km/sec, waited to halfway, flipped the vessel, set speed to 0

and arrived just right, still a little to early, i didn't entered the frame of moon but she's close on the screen

i assume when you overshoot then it's a matter of inaccuracy,

i used such a low specced ship because i assume if i use a ship which reaches a high end speed the error will be much bigger.

i guess right now on a long trip the orbit of the body you like to reach has most weight, much more as a little gravity.

you can assume that a planet you like to reach either moves towards you or away from you, though if like or have something to take to account then it's this.

but, imho the error based on the usually quite high end speeds is much bigger in the end,

while as slower i travel the movement of the bodies will have more weight.

---

to the slingshot,

rotation plays no role only gravity (besides, i guess stars don't rotate in pioneer it's not of relevance),

it's i guess a bit unrealistic in pioneer? at least (i don't know if this is still the case) it's not possible to reach the surface of a star,

i tried this once long ago, even with some other stars as sol to see if a higher or lower mass would get me a different result,

but no matter, if you let the ship get caught only by the gravity you get accelerated from a certain point on very rapid to the escape velocity,

no matter if your curse was straightwards to the star, you get strangewisely always "repelled".

but on the other hand i'm not sure, you rarely reach a 100% straight curse to the center, the angle you have could be enough for this effect.

usually one won't use in this way, i strongly assume you would get roasted far before you reach the escape velocity.

and i'm not the one who likes to calculate a slingshot, it has no use in pioneer except to see "it exists", you can do it if you like to.

also it was just ment as example that gravity can play a role, but i really guess it's deniable, except you pass a star relatively close.

N.B. This is a work in progress. This post will explain how to travel very long distances that require some 'coasting' time. I'll update once I've got a set of equations for shorter distances.

OK, so I found myself with a couple of weeks time off so I thought I'd give this question a shot.

With Pioneer, we are dealing with rocket science, and the associated equations.

So I'm assuming the following:

i) The force provided by your rockets remains constant while they are firing.
ii) Related to i), the rockets eject reaction mass at a constant rate. Refer to the ejection rate as B (supposed to be the greek letter beta...)
iii) Mass (m) is measured in kilograms (kg). At time (t) = 0, this is the mass of your ship plus the mass of your propellant, refered to as m0.
iv) Force (F) is measured in Newtons (kgms-2)
v) Acceleration (a) is measured in metres per second squared (ms-2)
vi) Speed (v) is measured in metres per second (ms-1). N.B. I make a distinction between speed and velocity. Velocity is a vector that describes speed and direction. Speed is a scalar quantity expressing magnitude only.
v) Distance (s) is measured in metres (m)
vi) Time (t) is measured in seconds (s)
vii) I am choosing to ignore gravitational forces, as these are generally negligible compared to the force generated by your ship's engines

So, to begin, under acceleration, your ship will eject a constant mass ( B) of propellant every second.

Therefore, as a function of time, your ship's mass can be determined using the equation:

m = m0 - Bt <--(1)

Force = Mass x Acceleration, therefore we can substitute (1) into the force equation to get:

F = ( m0 - Bt ).a

Making acceleration the subject we get:

a = F / ( m0 - Bt ) <--(2)

Equation (2) basically tells us that the acceleration experienced by our ship is dependant on the length of time for which it has been accelerating. As time increases, acceleration increases. It is for this reason that the simple method of accelerating to midpoint, spinning around 180 degrees and decelerating for an equal distance doesn't work. On the deceleration phase, due to your ship's lighter mass, you will wash off speed more quickly that when you were accelerating. You will take less distance to stop and will most likely stop short of your destination.

If we integrate (2) with respect to time, and assume the resultant integral constant is such that when t = 0, then v(t) = 0, we get the formula for speed:

v = ( F / B ).( ln( m0 / ( m0 - Bt ) ) ) <--(3). ( ln = Natural Logarithm )

Integrate (3) with respect to time, we get the formula for distance (the working out for this got quite hairy), again assuming the resultant integral constant is such that when t = 0, s(t) = 0:

s = ( F / B ).( ln( m0 ).t + ( F / B^2 ).( m0 - Bt ).( ln( m0 - Bt ) -1 ) - ( F / B^2 ).m0.( ln( m0 ) - 1 ) <--(4)

Now, these equations are a starting point for determining the turnaround point. First let's gather together the constant values that we know.

The first location is the ship.lua file. This file is located in the dataships folder. From this file we get the following:

Forward and reverse thrust, in Newtons (kgms^-2). Plug this value into the F variable.
Hull weight (t)
Maximum fuel tank capacity (t)
Maximum equipment and cargo capacity (t)
Exhaust velocity (ms^-1)

Secondly, we need to be able to convert km to Astronomical Units. A quick web search will grab this for you (149,597,871.7km).

Finally, in game there's the F3 page that display's the ship information:

Percent fuel remaining (this is potentially more accurate than using the fuel weight figure).

I've created a spreadsheet that puts all these values together. You can download it via this link: https://app.box.com/s/0ancxt0768dixhqoqssf

Using the spreadsheet
=====================
Bear in mind, this is a work in progress. I have a feeling that the motion equations above should be expressible in such a way that the time variable can be eliminated.

So far, all this spreadsheet does is tell you the expected ship speed and distance travelled for a given time period, assuming that you have correctly provided the input parameters.

So, for the Sinonatrix, we have the following figures:

Item Units Amount
Fthrust kgms-2 5,500,000
Rthrust kgms-2 1,200,000

Hull t 20
FuelMax t 30
Cargo t 35

ExhaustV ms-1 19,500,000

AU km 149,597,871

Weight empty t 20
Capacity used t 25
Fuel weight t 29
All-up weight t 74

Fuel % 99
Delta-V kms-1 9,947

Faccel ms-2 72.37
Raccel ms-2 15.79

Assuming that after arriving at the Sirius system, we find ourselves needing to travel 36.73 AU. Our Delta-V upon system arrival is 9947kms-1. Half this distance is around 18 AU. We don't have enough delta-v to accelerate continuously for 18 AU. Therefore we should calculate the maximum speed to which we should accelerate so that we have enough delta-v to decelerate and perform our final manoeuvers. For starters, let's assume we can use 80% for our initial burn (that we hope will take us to within a few percent of our destination). So let's set our maximum speed to 40% of our delta-V, about 3,900km/s.

So we accelerate to 3,900km/s, (which should take about 0.60 AU), then hit F3 to grab the figure for % fuel remaining. This figure we plug back into the spreadsheet, and look down the velocity and distance columns to find the distance required to decelerate from 3,900 km/s given our reduced mass.

From the F3 ship information page, we see we have 54% fuel remaining. So we put 54 into the Fuel % cell in the spreadsheet, then look down the velocity column to find the figure closest to 3,900km/s. For this velocity, the deceleration distance is about 0.50 AU, so that's the point at which we should flip 180 and begin slowing.

This allowed me to stop around 3.6 million km from my destination, which considering that's less than 1% of the total distance travelled, that's actually not too bad.

Nice. I have to try this one out. Maybe even putting it into the game via lua.

Hey Nozmajner, did you have anything specific in mind?

I've put together a formula that gives time required to accelerate to a specific speed (basically, made t the subject of the speed formula). From this I've derived a formula that can calculate the distance required to stop given a specific speed.

I'm having a go at building a spreadsheet that will calculate the Vmax and deceleration point required when traversing a specific distance. The calculations are becoming rather complex and would probably be easier to implement in code.

How difficult would it be to display the available delta-V and distance to stop via the cockpit view rather than on the F3 page?

Everyone, I've reworked my motion equations to enable the calculation of stopping distance given an initial velocity.

TL;DR - an updated spreadsheet that does the calculations for you can be found here: https://app.box.com/s/0ancxt0768dixhqoqssf

Using the spreadsheet
=====================
My apologies if the attached spreadsheet is not self explanatory - I set this up mostly to test the formulae. Ideally, I'd want to create (or have created, hint, hint) a mod that will display the distance to stop for the current velocity. The mod would be able to take advantage of being able to retrieve accurate Force, Mass, Speed and mass flow parameters directly from the game.

I've tried using this spreadsheet to travel without the autopilot and I'm finding that it can land you within a few percent of your destination, but bear in mind that if your travel distance is of the order of astronomical units, a few percent is still millions of km.

Not so short version
====================
For those who came in late, here are the initial equations:

m = Current mass
m0 = Initial mass
B = mass flow (thruster mass ejection rate)
t = time
F = force
a = acceleration
v = velocity
s = distance

Formula for mass as a function of time:
Mass(t) = m0 - Bt <--(1)

Force = Mass x Acceleration, so substitute Mass with (1) and make Acceleration the subject to get Acceleration as a function of time:

Acceleration(t) = F / (m0 - Bt) <--(2)

Integrate (2) with respect to time to get the velocity formula, and derive the integral constant by assuming that when t = 0, v = 0:

Velocity(t) = ( F / B ).ln( m0 / ( m0 - Bt ) ) <--(3)

Integrate (3) with respect to time to get the distance formula, and derive the integral constant by assuming that when t = 0, s = 0:

Distance(t) = ( F / B ).ln( m0 ).t + ( F / B^2 ).( m0 - Bt ).( ln( m0 - Bt ) - 1 ) - ( F.m0 / B^2 ).( ln( m0 ) - 1 ) <--(4)

Now, the above formulae give us ship mass, acceleration, velocity and distance travelled for a given time. What would be more useful when piloting in Pioneer is to have distance to stop given an initial velocity.

If we take equation (3) and make time the subject, we get the following formula:

Time(v) = ( 1 / B ).( m0 - U ) <--(5)

Where U = e^( ( F.ln( m0 ) - B.v ) / F ) <--(5a)

So now if we take equation (5) and substitute it into the distance equation (4) (and I'm not going to reproduce that here), then we end up with a formula that gives us distance to stop from a starting velocity.

If you want into the lua side and play around, you can initially just add the functions you want to data/ui/InfoView/OrbitalAnalysis.lua, and then in data/ui/InfoView.lua comment back the uncommented line, and you'll have a new tab under F3.

Check the pioneerwiki for Lua API.

Come by IRC if you need help.

@Impaktor - once I get myself organised (hopefully this weekend), I'll jump onto IRC and have a chat about the planetary scan widget. Then I can try building in some sort of GUI that will display the results of the formulae that I've derived above.

Everyone,
I've had more of a play with the formula for calculating stopping distance above and have found that on average I tend to overshoot my destination by a few percent. I'm guessing this discrepancy is due to gravitational forces (which have been ignored in the calculations), and/or inaccuracies in the value for remaining fuel mass that I'm plugging into the formula.

To get around this, I accelerate to Vmax using the forward thrusters at 100%, then decelerate using either the reverse thrusters or the forward thrusters on reduced power. For example, starting from a speed of 3500km/s, I decelerate to 3000km/s, then recheck my stopping distance using the new fuel % remaining figure. If the formula says I'm going to overshoot, then I use the forward thrusters at 100% to wipe off a further 100km/s, then check again. By periodically checking the stopping distance and adjusting your deceleration rate accordingly, it becomes possible to stop at your destination within < 10,000km.

Eventually, I'll mod this stopping distance calculation into the game to make it easy to identify whether you are going to overshoot or not.

Wow I assumed this to be a simple request, but it turns out to be a PhD thesis.

But it has to be said it would be kinda useful.

As would an indicator on screen of one's predicted trajectory, so that one could see when one is going slow enough to be gravitationally captured, which would save a whole lot of flipping to the map screen, which does have that information.

Apologies for the thread necromancy...for various reasons this little mod has stuck in the back of my mind and this week I thought I'd have a go at getting the 'Distance to Stop' calculation to appear in one of the F3 pages.

So far I've taken Impaktor's advice and enabled the Orbital Analysis page, and I've been able to display the player ship's remaining Fuel in tonnes and as a percentage of full.

local FuelMassLeft = Game.player.fuelMassLeft
local FuelMassLeftPC = Game.player.fuel

These values are then displayed in a table (I basically copied the code from the existing table in the OrbitalAnalysis.lua script).

I've had a look at the API ( via http://eatenbyagrue.org/f/pioneer/codedoc/files/LuaShip-cpp.html ) to see if I can get some of the remaining values I need for my calculations.

I just can't seem to get the syntax right to get values out of the ShipDef object (for example).

The values I'm requiring are:

Forward and Reverst thrust values (in kgms-2)

Hull mass

Maximum Fuel mass

Current Cargo mass

Exhaust velocity

Empty weight

Capacity used

Fuel weight

All up weight of ship

As a bonus I'd love the current speed of the ship relative to the current reference body

If I could get an example of the code required to pull data out of the ShipDef object, I think I'll be well on my way to getting this little mod sorted.

Any help?

Cheers.

I've pinged the IRC channel to see if there's anyone around to help, if not PM me at the weekend and I'll try digging through the code myself.

@Bugbear please check data/ui/StationView/ShipMarket.lua. It's actually used in very many places, like all mission scripts that send ships your way. And Pirates.lua. Those are all in data/modules/

If you come up with something useful, and feel like contributing, let us know, maybe we/you can improve the Orbital Analysis tab so we can have it activated again?

I started to work on a similar mod a while ago, but I got stuck, because I had to calculate the velocity. Fluffyfreak did something about the velocity in lua a while ago, maybe that can be helpful.

Here's where I got.

I put the whole thing into the ShipInfo page, so I can check the value simply by pressing F3, and also there's a lot of input to the console, so the numbers can be checked.

I managed to get out almost all the data from the game except the speed if I remember correctly.

The way I wanted to get the needed distance is to iterate the calculation several times, so the changing acceleration due to expelling mass can be taken into account.

There are some comments where I put in my stuff, but I'm not sure how clear they are. 

And I can't really code, so I'm sure this whole thing is quite cringe inducing for somebody knowledgeable. 😀

Hope it helps.

 

 

I've made some progress with gathering the data I need to calculate the distance to stop given a starting velocity.

Turns out all I need are the following:
Fuel remaining --> Game.player.fuelMassLeft
Ship mass (excluding fuel) --> Game.player.totalMass
Exhaust velocity --> ShipDef[Game.player.shipId].effectiveExhaustVelocity
Forward thrust -->ShipDef[Game.player.shipId].linearThrust.FORWARD
Reverse thrust --> ShipDef[Game.player.shipId].linearThrust.REVERSE
Current velocity --> ???

So as you can see all I need now is the current speed relative to the current frame of reference.

I think that you should be able to use "Game.player:GetVelocity()" as it's quite new, and the API reference might be out of date, it might not be on the API listing.

it returns a LuaVector

 

/*

 * Method: GetVelocity

 *

 * Get the ships velocity

 *

 * > ship:GetVelocity()

 *

 * Availability:

 *

 *  April 2016

 *

 * Status:

 *

 *  experimental

 */

static int l_ship_get_velocity(lua_State *l)

{

Ship *s = LuaObject<Ship>::CheckFromLua(1);

LuaVector::PushToLua(l, s->GetVelocity());

return 1;

}

it might not be on the API listing.

Most likely isn't, since API is only updated manually, very rarely, when we kick our biological (rob)ot down under.

OK, I'm still a little dense (I'm still fairly new to Lua).  How do I access the components of the LuaVector object?

(In the menatime I'll keep reading up on Lua basics...)

Here's a first draft of the 'Distance to Stop' calculations.  You can download the various required files via this link: https://app.box.com/s/0ancxt0768dixhqoqssf

I've also included some screenshots in that link so you can see the results of the calculations.

Bear in mind that this is an initial draft and the presentation of the data is not quite where I'd want it.

Also, at this point I haven't worked out how to get the current ship's velocity so I've just hard coded 1000km/s for now, just so you can see the calculations in action...

** edit ** While I think of it, if I can get access to the distance to the selected destination, I should also be able to determine the turnaround distance and speed - this would also take into consideration the amount of fuel (propellant?) that you have in the tank...

Dammit, I can see this mod getting bigger...

Neat! A quick test gave me the good ballpark estimate of .10AU from the Barnard's starting position.

Are you sure you want to put all this data into the Orbit Analysis page? It might be more accessible in the ship info page, so you can check it quickly by pressing F3. (Sans proper customizable flight UI top put into)

You can access the propellant flow of the ship: ShipDef.thrusterFuelUse. I saw you are calculating it. Don't know which method is better though.

Hey Noz...

I'll see how I go putting my data on the Ship Info page.  Now that I've done it once in the Orbital Analysis page, editing the other .lua files should be straight forward.  I'll put my calculations under the 'acceleration' data.

I want to make the output much more concise than I've done so far in my first draft.  I think the most essential information required is (apologies for the dodgy attempt at an ASCII table):

                              |    Forward thrusters    |    Reverse thrusters    |

Distance to stop     |                                    |                                    |

Time to stop           |                                    |                                    |

If a table looks too out of place on the F3 page, then I'll just list it instead.

The unit of measure displayed for both the distance and time would be dependent on the magnitude of the measurement, e.g. if distance is > 0.10 AU, then show distance in AU, otherwise in km.  I'd do something similar for time, with an aim to make the leading integral component of the measure as small as possible (easier to explain in code than in English...)

I didn't notice the thrusterFuelUse property.  I'll use that instead.

Cheers

Some minor modifications - I've moved the calculation output to the Ship Info page - same link as above ( https://app.box.com/s/0ancxt0768dixhqoqssf )

Download the en.json ( https://app.box.com/s/venvrlgguor8h3xayxxy31110dtl8abt ) and the ShipInfo.lua ( https://app.box.com/s/l04gnf0ltgliz3fxvuvo8klskfbivvai) to see it in action.

Image of the display: https://app.box.com/s/1gv9d48kkb0jsiip9rkfp2xt85vmnflo

Again, I don't yet have the code for getting the current speed so an indicative speed of 1km/s has been hard coded on the ShipInfo.lua file.

I also haven't worked out how to grab the thrusterFuelUse property - not sure if this value changes from forward to reverse thruster, so not sure of the syntax for getting this value for a specific engine.

All I need is the code to get the current speed....hint, hint 🙂