- This topic has 0 voices and 31 replies.
September 24, 2014 at 12:56 pm #60648
I tried flying to the moon as quickly as possible, so I accelerated up to the halfway point, then flipped and decelerated.
Problem is I either splashed into the moon or sailed past it, despite working a 10% error into the halfway point.
So how do I calculate the ‘halfway’ point?
Thanks.September 24, 2014 at 11:06 pm #104591
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.September 25, 2014 at 5:17 am #104592
Surely there is a more scientific method than suck it and see?October 3, 2014 at 9:31 am #104593
i experienced similar.
but i guess we have to take two additional factors to account:
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)
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')
:semi_major_axis(f(272903,1000000000)), -- orbital period ~1day ~geostationary (rel. to earth)
CustomSystemBody:new('Gates Spaceport', 'STARPORT_ORBITAL')
: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')
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.October 4, 2014 at 5:08 pm #104594
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?October 4, 2014 at 6:49 pm #104595
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.October 5, 2014 at 9:43 am #104596
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
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
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
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.December 28, 2014 at 3:06 am #104597
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.December 28, 2014 at 8:04 am #104598
Nice. I have to try this one out. Maybe even putting it into the game via lua.December 29, 2014 at 11:27 am #104599
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?December 31, 2014 at 8:37 am #104600
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.January 1, 2015 at 6:56 am #104601
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.January 3, 2015 at 6:18 am #104602
@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.
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.January 4, 2015 at 5:40 am #104603
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.June 23, 2016 at 9:42 am #104604
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)
Maximum Fuel mass
Current Cargo mass
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.
- You must be logged in to reply to this topic.