ElWanderer

Wikipedia has a Stability of the Solar System page: https://en.wikipedia.org/wiki/Stability_of_the_Solar_System Confusingly, it also has a page on "Orbital Stability" that has nothing to with orbits, but is related to mathematical functions.

I did find this: One suggestion from that is to turn off fine control if you're using it. It's not the thread I was remembering, though.

This rings a bell. I think there is a KSP bug whereby it calculates the torque each RCS thruster will generate invorrectly, causing those well away from the centre of mass to fire barely, if at all, which is the opposite of what you want to happen. I'm not sure what search terms to suggest, though.

My code calculates the available delta-v for the current stage prior to each manoeuvre, so as to determine if it needs to stage, which affects the burn time estimate. When I recently started testing against KSP v1.2.2/kOS v1.0.3, I noticed I was getting 0m/s printed out a lot indicating STAGE:LIQUIDFUEL/OXIDIZER were both zero. Toggling stage view in the KSP resources tab showed the same data: no fuel. Yet the engine was active and had fuel (and the engine part gauge in the staging list in the bottom left showed access to liquid fuel). I had a bit of a play, and got the impression that staging and stage (re-)ordering seemed to matter. KSP didn't seem to like me firing the next stage at the same time as triggering the decoupler. Separating those into two steps seemed to help. I say "seem" because my testing was definitely not rigourous. One example that stuck in my mind was when my upper stage was reported as having no resources except for 16 units of solid fuel; that fuel was in two sepratrons mounted on the stage to deorbit it, but naturally they weren't activated at the time (they were set-up to activate along with the decoupler above). This is fairly common in my designs, and may be the reason why I'm suddenly seeing this with almost everything I launch (compared to launching the same craft in KSP v1.1.3/kOS v1.0.1). Another example was a ship that docked to another craft, then undocked. On undocking, KSP reported it no longer had any fuel in the stage. I added an empty stage below the current one and triggered it. Then the stage fuel numbers appeared. In this example, I think I was using my docking tester, which has a single stage once in orbit, but it's possible that I was using my crew shuttle that has extra stages (decoupler, chutes, heat shield jettison if I'd forgotten to remove it) to confuse matters. I'm sorry I don't have any concrete examples; I don't get much time to play the game itself. Edit: I should point out that none of my current designs use fuel pipes so that's not a factor in these examples. I know the kOS v1.0.2 release notes explicitly mentioned asparagus staging as an area where you'd expect to see changes in behaviour.

KSP's behaviour with "stage" resources has been annoying me too. I've had to write my own fuel-finding functions that recursively negotiate the parts tree, starting from any currently-ignited engines. I'm not aware of any way to take into account fuel lines, though Is there a way in kOS to find which part a fuel line transfers fuel to? A search pulled up an old Reddit post saying fuel lines had their own module, but it had nothing useful accessible https://m.reddit.com/r/Kos/comments/35wu8o/fuel_zones_or_remaining_deltav_fuel_per_engine/

The contents of those triggers won't get executed until the start of the next physics tick, by which time your script has already ended.

I was referring to the be script you posted that had only WHEN statements, to which you added: "EDIT: After running the script, I tried PRINT EC, PRINT WATER & PRINT READYTODRILL and all read 0. Clearly the WHEN/THEN statements are not being executed/just wrong." My last post was explaining why it'll exit without doing anything useful.

WHEN/THEN commands do not work as you're possibly thinking. They don't stop code execution; instead they're stored as triggers to be run each tick. This means that the script will continue executing, but if there is no more code to run, the script will end. Try sticking a WAIT UNTIL FALSE. at the bottom of the script so it never ends.

...and... I don't think SHIP:WATER exists in stock + kOS, but I'm guessing it's a resource added by another mod that could be picked up automatically... otherwise I'd expect that to throw an error and crash the script. Going via something like SHIP:RESOURCES is more complicated (you need to loop through the resource entries in the list until you find the one with the right name), but should allow access to any resource. If it exists, SHIP:WATER is probably a floating point value, in which case, yes, it's highly unlikely to equal any value precisely, so a less than or greater than kind of check *is* preferable. As you're looking for "full" tanks, you probably want something like 'greater than 143'. If you use SHIP:RESOURCES, you can actually find out what the capacity of the specific resource is and so react once the resource amount is over 99% (say) of the full capacity. Also, do you want to re-enable the drills if the level of water drops back below 144 units? If enabling and disabling via separate triggers, you want to check they don't conflict with each other or fire all the time. I would set a global variable that declares whether the drills are on or off and check that in the logic for each trigger. I'd also combine the checks on electric charge with those on the water level (the bits inside braces are pseudocode): GLOBAL (drills are on/off) // pick a starting value and then set the drills to that condition. (set drills to on/off) WHEN ((water level is over 99%) OR (electric charge is below 10%)) AND (drills are on) { (turn drills off) (set that drills are off) PRESERVE. } WHEN (water level is below 99%) AND (electric charge is above 10%) AND (drills are off) { (turn drills on) (set that drills are on) PRESERVE. } Ah, I see there were several respones while I was typing!

You could loop through all vessels in the game (LIST TARGETS IN my_list...), comparing their names to the one you're looking for, until you either find one or finish the list.

Please see my reply to meyerweb above yours

Ah thanks for confirming that. My lib_dv.ks file is here: https://github.com/ElWanderer/kOS_scripts/blob/master/scripts/lib_dv.ks and documented here: https://github.com/ElWanderer/kOS_scripts/blob/master/documentation/lib_dv_readme.md The documentation is separate to keep the script file size down... It's for delta-v calculation (of the current stage only) and burn time calculation (current stage + next stage if necessary). It relies on one function from my common library, pOut(), which is a wrapper around PRINT (that adds in Mission Elapsed Time and logs the whole thing to a log file if one has been defined). That's easily replaced and I don't think the library needs anything else from my repository. That version was written against KSP v1.1.3 / kOS v1.0.1. I've been having "fun" with STAGE:LIQUIDFUEL and STAGE:OXIDIZER since the v1.2.2 / v1.0.3 upgrade, so there is a draft updated version here: https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/scripts/lib_dv.ks. It uses STAGE:RESOURCESLEX and if that doesn't find any fuel, tries SHIP:RESOURCESLEX instead. Edit: except SHIP:RESOURCESLEX doesn't exist. D'oh.

This is very difficult for multiple reasons. You can't get the thrust of an engine that isn't running. My workaround is to activate the engine briefly, note the thrust, then shut it down again, which can't be done for SRBs (and is a bad idea in Realism Overhaul where engines have limited activations). A full solution for all engine types would need changes to kOS to make these values available on inactive engines, or we could add a big look-up function to our code that has the thrust and ISP of each engine model... yuk. Dividing the craft into stages typivally requires walking the parts tree and making assumptions about where the root part is. Each part has an associated "stage number", but from memory this can't be trusted as KSP assigns it when parts are added, but doesn't change it when staging is rearranged. If that did work, it'd make things much easier. To avoid writing something massive, I have a very cut-down version that guesses what the next engine is (assuming there is just one). That's based on checking there is a decoupler attached below each engine, and picking the engine whose decoupler has the lowest total mass, including the mass of child parts (and their children and so on). That total mass can be subtracted from the current MASS to get the wet mass of the next stage. We can also then determine the details of the next engine. I have a library and some documentation I can link to if you're interested in seeing my approach.

They extended the the year length (without meaning to) by half an hour in v1.2, then corrected this in v1.2.2. The GM values etc. are different depending on which version you look at.

Yes. It's equations 4.86 and 4.87 that are of particular interest, which only need the semimajoraxis, eccentricity, true anomaly and gravitational parameter. It does require being able to calculate sinh() and inverse cosh(), which kOS doesn't have native functions for, so I had to look those up on Wikipedia. Oh, and the calculation of true anomaly based on radius is in equation 4.82, though as said before this is the same as for an elliptical orbit.

OhioBob's website has the required formulae for hyperbolic trajectories: http://www.braeunig.us/space/orbmech.htm#hyperbolic I used the details from that page to write something in kOS which works well. I can share that if you like. The calculation of true anomaly and mean motion is the same, it's the conversion from true anomaly to mean anomaly (via eccentric anomaly) that is different between hyperbolic and elliptical orbits.

One difference with contract orbits is that the An/Dn markers appear on the contract orbit, not your own. Might that explain it?

Stock KSP only shows the nodes on your orbit if you're orbiting the same body as your target. It'll also show nodes on satellite contract orbits, again if you're orbiting the same body. Those are nodes related to the intersection of two orbits. It would also be possible to display the nodes related to the intersection of your orbit with the universal reference plane (i.e. where your orbit crosses the equator; with no axial tilt, these are the same thing) but you'd need a mod to do this.

Indeed... and the Russian gauge (1520mm) used in most of the former Soviet Union is wider than standard gauge (1435mm). Larger horses? Plus the limitation on transporting something by rail is really down to the loading/structure gauges (how far the tracks are from obstructions, as opposed to the distance between the two rails).

Glad that helped. I just wish I could remember where I found that function; from memory it was a book which shows up in Google search, but where it shows you every other page rather than the whole thing. In this case the bit I needed was on a page I could see!

I think that by convention, inclination is measured in the range 0-180°. It's the longitude of the ascending node that tells you which way around an orbit is. If you have two orbits that are in the same orbital plane, but travelling in the opposite direction, they will have the same inclination but the longitudes of the ascending node will be 180° apart.

Sounds like it Areobraked. *Sad face* Speaking of Kerbal-style, it reminds me of my first automated Mun lander probe using kOS. Killed its horizontal velocity beautifully, switched to the suicide burn piece of the code a few hundred metres up and... crashed. So it turned the throttle off, plummeted and properly crashed while I was furiously typing to correct the mistake in my code.

I have a kOS library that tries to calculate this. I've only just documented it (most of my code is uncommented, so I'm slowly adding separate readme files), but hopefully that'll explain the maths behind what I'm doing, even if the kOS code itself is of no use/interest. Check out the etaToOrbitPlane function. Library: https://github.com/ElWanderer/kOS_scripts/blob/master/scripts/lib_launch_geo.ks Documentation: https://github.com/ElWanderer/kOS_scripts/blob/master/documentation/lib_launch_geo_readme.md

The BBC are reporting that the parachute jettisoned earlier than expected (hinted at in the ESA page linked to above), as well as the thrusters firing for less time than intended. http://www.bbc.co.uk/news/science-environment-37715202 PS. Mark Watney says "thanks for the new barbeque. Mmmmm, hot potatoes".

Fingers crossed. I've got to feel for the guy whose wind sensor on-board Schiaparelli is a re-run of one he had on-board Beagle 2 (as mentioned part way down http://www.bbc.co.uk/news/science-environment-37700042) To lose one sensor is unfortunate. Losing two...