frame

Howdy, Stranger!

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

Sign In Register

Howdy, Stranger!

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

Categories

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-

How Do I Calculate....

edited September 2014 in Pioneer

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. 


«1

Comments

  • edited 8:35PM

     


    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.


  • edited 8:35PM

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


  • edited October 2014

    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')
    :seed(2)
    :inclination(math.deg2rad(0))
    :eccentricity(f(0,1))
    :semi_major_axis(f(272903,1000000000)), -- orbital period ~1day ~geostationary (rel. to earth)

    CustomSystemBody:new('Gates Spaceport', 'STARPORT_ORBITAL')
    :seed(0)
    :inclination(math.deg2rad(90))
    :eccentricity(f(0,1))
    :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')
    :seed(0)
    :inclination(math.deg2rad(0))
    :eccentricity(f(999999999,1000000000))
    :semi_major_axis(f(522,1))
    :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.


  • edited 8:35PM

    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?


  • edited 8:35PM

    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.


  • edited October 2014

    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.


  • edited December 2014
    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 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.
  • edited 8:35PM

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


  • edited 8:35PM
    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?
  • edited 8:35PM
    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.
  • edited 8:35PM

    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.

     


  • edited 8:35PM
    @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.
  • edited 8:35PM

    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.

  • edited 8:35PM

    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.


  • edited 8:35PM

    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.


  • edited 8:35PM
    @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?
  • edited June 2016

    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. :D


    Hope it helps.


  • edited June 2016

     


     


    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;

    }

  • edited 8:35PM

    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.
  • edited 8:35PM

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


  • edited June 2016

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


  • edited June 2016

    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.


  • edited 8:35PM

    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


  • edited 8:35PM

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


  • edited 8:35PM

    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.

  • edited 8:35PM

    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

  • edited 8:35PM

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


  • edited 8:35PM

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


  • edited 8:35PM

    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


     


     


  • edited 8:35PM

    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.

     
Sign In or Register to comment.

SpaceSimCentral

| The largest Space and Scf-Fi Gaming Community
@ 2008-2016 SpaceSimCentral.com, All rights reserved.
Powered by VanillaForums, Designed by ThemeSteam

Contact us

Like I am going to give you my phone # :)

Get In Touch