It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In RegisterIt looks like you're new here. If you want to get involved, click one of these buttons!

- 4.9K All Categories
- 490 Introduce Yourself to SSC
- 23 SSC Administration
- 526 General Chat
- 211 Sci-Fi Movies and Television
- 34 UFO's and Conspiracy
- 33 Outer Space and Astronomy
- 47 Political and World Discussions
- 23 Surveys and Polls
- 18 SciFi Books and Fan Fiction
- 299 PC and Console Gaming
- 776 Space/SciFi Combat and Simulation Game Discussion
- 6 3030 Deathwar
- 4 Avorion
- 5 CDF Starfighter
- 2 Go for Launch: Mercury
- 12 Dominium
- 10 No Mans Sky
- 1 Rodina
- 4 Solotra.B
- 11 Starsector
- 48 Starpoint Gemini Series
- 3 Stars of Icarus
- 48 Starwraith Games
- 4 VoidExpanse
- 5 Wayward Terran Frontier
- 83 X Series
- 439 Space and SciFi MMO and Multi-Player Only Discussion
- 13 Age of Ascent
- 56 EVE Online
- 41 Elite: Dangerous
- 32 Infinity: Battlescape
- 39 Jumpgate Series
- 3 Sector 13
- 62 Star Citizen
- 38 StarTrek Online
- 41 Vendetta Online
- 1.2K Free SciFi Gaming Projects
- 3 FAR Colony
- 90 FFED3D
- 19 Oolite
- 813 Pioneer
- 10 XFrontier
- 458 FPS, Strategy and Tactical Scifi Games
- 58 Colonisation: Moonbase
- 1 Earth Space Colonies
- 13 Mass Effect Series
- 11 Nexus: The Jupiter Incident
- 79 Shallow Space
- 11 Space Pirates and Zombies
- 56 Starfall Tactics
- 121 Mobile and Web Gaming
- 11 Darkdawn: Encounters
- 6 Spacesimulator.net Voyager Project
- 210 Classic/Retro Space Games
- 54 Freelancer
- 14 Freespace I & II
- 26 Independence War 1 & 2
- 29 Wing Commander Series
- 95 General Coding and Mod discussion
- 60 Show Off
- 253 Deep Space Salvage Yard
- 19 Ensign 1
- 25 Fairspace
- 14 God Factory: Wingmen
- 27 Heresy War
- 39 Miner Wars 2081
- 20 Salvation Prophecy
- 11 Spacemasters
- 16 Space Force: Rogue Universe
- 25 Starshatter
- 44 The Precursors
- 2 Void of Darkness

Hi Everyone

I think most of the major changes are done, I think. Now I will be just doing small stuff to improve security and hopefully make everything look better. :)

For help for existing users prior to website update read these posts:

**Activating account:**

http://spacesimcentral.com/forum/discussion/7019/troubleshooting-my-account-from-the-switch-over

**Download Area Info**

http://spacesimcentral.com/forum/discussion/7020/download-area-info

Please post to the administration area if you have any problems:

http://spacesimcentral.com/forum/categories/ssc-administration

-D1-

I think most of the major changes are done, I think. Now I will be just doing small stuff to improve security and hopefully make everything look better. :)

For help for existing users prior to website update read these posts:

http://spacesimcentral.com/forum/discussion/7019/troubleshooting-my-account-from-the-switch-over

http://spacesimcentral.com/forum/discussion/7020/download-area-info

Please post to the administration area if you have any problems:

http://spacesimcentral.com/forum/categories/ssc-administration

-D1-

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.

## Comments

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)

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!

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:

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.

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 ( 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 data\ships 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.

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?

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.

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.

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.

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 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

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 :-)

I think it's just a meta table with 3 elements. You can get each element by it's index "x", "y", or "z" too.

If you just want the velocity without the direction then you could just get it's "length" which will give a single value for "speed" I guess.

Looks very good.

A bit of nitpicking: I think "Main" and "Retro" thrusters might be better terms. At least for me. Forward could imply that the thrusters are looking forward, or that they accelerate you forward.

And a bit more: Maybe you could move them up above the acceleration displays, so the deltaV and Speed displays are right next to each other. Would make it easier to judge, how much juice you have left in your tanks.

Anyhow, this feature will sure give the adventurous player an edge over the autopilot regarding transfer times.

Also, if you zip it up this way, it can be used as a mod, making it easier to test:

stop.zip

/lang/ui-core/en.json

/ui/InfoView.lua

/InfoView/Shipinfo.lua

Thanks for the help on IRC. No success yet but I'll keep bashing away...

We now have the distance to stop calculation available on the F3 page, and I've uploaded the latest ShipInfo.lua here: https://app.box.com/s/l04gnf0ltgliz3fxvuvo8klskfbivvai

I'll now do some work on figuring out how to display these numbers on the cockpit (aka WorldView screen).

There is one minor gotcha with the calculations though - the distance to stop is based on the speed relative to the frame of reference (which admittedly is what I requested in the first place). Now that I've had a chance to play with this, I'm thinking that speed relative to destination would be more useful. When travelling from Earth to Mars for example, the point at which deceleration needs to begin occurs while the frame of reference is Sol, which means that the speed will be out by something like 25km/s.

I'll see what I can do about this looking at the underlying code...

Another update. After another couple of months of sporadically trawling through the Pioneer C++ source, I've been able to create a function in WorldView.cpp that calculates the distance to stop, and displays this on screen just below the current nav target relative speed indicator - screenshot here: https://app.box.com/s/2jt86yrl0s3eq3svkxymkzttvsro1f78 (The F means distance to stop using the 'forward' or main thrusters, the R means distance to stop using the 'rear' or retro thrusters. The rear thrusters are less powerful than the front, therefore they will take more distance to accelerate / decelerate from a given speed).

(After using this a few times, I'll probably also add the current available delta-v - that's a very important number when travelling between planets...)

This is still a work in progress - my intent is to make this calculation available only to commanders that purchase the Nav Computer Upgrade in-game so as a result I would need to work out how to declare a new piece of purchasable equipment (knowing my luck and my schedule that will take me another couple of months...).

I know that some other devs (in particular ecraven) have been doing some excellent work in not only calculating this information, but also presenting it on screen in a much more attractive manner (I've always said that I don't do "pretty" very well), so it may be that my efforts so far will come to naught.

What I'd like to to, though, is make available the code I've created so far, and have some of the devs look it over and tell me whether I'm on the right track (I really should work out git works... )

WorldView.cpp - https://app.box.com/s/e7zo8hxyk8kj8uvs0isyjrhnpq203tz8

WorldView.h - https://app.box.com/s/m5ynr4w3aw83u5n1hdijyoeotfm4bqa6

I applaud your efforts, but I think we're on a good path to already include all this in master branch. ecraven's pull request went up last night (#3819). With this, pioneer will no longer draw to the worldview from C++, but from Lua.

It will be significantly easier for modders to add and change the "F1" view.

None of your links above work for me, I just get a blank screen. (Possibly my adblocker acting up?) You can upload your screenshot directly to the forum. That way we can all see it (if logged in), without relying on any third party.

But despair not, your work is not in vain. Without having looked at any code, it might be that you have a more accurate approximation for full stop distance than ecraven, if so, you can collaborate on using your code in his UI.