ElWanderer

February 21, 2017

Launch azimuth/heading is different to the azimuth/heading of the target orbit overhead (for Minmus, the orbit azimuth would be 84°/96° at the equator) because you already have some Eastwards orbital velocity due to the rotation of the planet. http://www.orbiterwiki.org/wiki/Launch_Azimuth

February 21, 2017

>Is there any way to time a launch such that we can insert directly into a minmus plane (applying our inclination burn during launch)?

Yes. You can time the launch visually by waiting in map mode until the plane of Minmus's orbit passes over your craft (at the KSC). I realise you want to fly the mission in IVA view, but perhaps you would allow map mode prior to launch? It's quite awkward to do so, but you can try to fly at an azimuth of 83.5°/96.5° by hand. That's the initial compass heading you need to take at launch to end up with an inclination of 6° in LKO.

Alternatively you can use maths and mods (for the maths to be doable you probably need an information mod at least). Myself, I use kOS to calculate the launch time and control the launch. Yes, being able to convert between geographic longitude and universal longitude via the universal reference vector is important, but you need to know where that reference is. It's not exposed in stock. It would be useful to work out what longitudes Telemachus is giving you.

To answer your earlier questions: You can do the plane change to match Minmus's orbit in one go, rather than zeroing your inclination first, but that's harder to calculate. OhioBob's website is pretty handy for this kind of thing: http://www.braeunig.us/space/orbmech.htm

February 1, 2017

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.

January 26, 2017

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.

January 26, 2017

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.

January 18, 2017

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.

January 17, 2017

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/

January 15, 2017

20 minutes ago, hypervelocity said:
What I meant was: if currently my Ship's EC is > 100 and Water is < 143 why PRINT EC and PRINT WATER are both 0 when I have the following in my code?
WHEN SHIP:ELECTRICCHARGE > 100 THEN {
    SET EC TO 1.
    PRESERVE. }

WHEN SHIP:WATER < 143 THEN {
    SET WATER TO 1.
    PRESERVE. }

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.

January 15, 2017

1 minute ago, hypervelocity said:

Sorry I meant the WAIT UNTIL was preventing the code moving from forwards

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.

January 15, 2017

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.

January 14, 2017

6 hours ago, hypervelocity said:

The code I have written is the following:


CLEARSCREEN. PRINT "==== EXECUTING DRILLING SCRIPT - DRILLING PROGRAM ACTIVATED".

WAIT UNTIL SHIP:ELECTRICCHARGE>100.
 {
  TOGGLE AG2.                                    //Action Group that deploys the Drills
  PRINT "===== DRILLS ACTIVATED".
  SET AG2 TO FALSE.
 }

WAIT UNTIL SHIP:ELECTRICCHARGE<100.
 {
  TOGGLE AG3.                                    //Action Group that shuts-down the Drills
  PRINT "===== DRILLS SHUT-DOWN".
  SET AG3 TO FALSE.
 }

WHEN SHIP:WATER=144 THEN {                       //Trigger I am having issues with and cannot make it work
 TOGGLE AG3.                                     //Trigger I am having issues with and cannot make it work
 PRINT"===== WATER FULL, DRILLS SHUT-DOWN".      //Trigger I am having issues with and cannot make it work
 PRESERVE.}.                                     //Trigger I am having issues with and cannot make it work
RUN DRILLING.                                    //VERY LAME solution for not being able to work the WHEN/THEN statements. 
                                                 //As I don't know how to make my code to keep checking if EC is < or > than 100, I need to
                                                 //do this to get the code running again (would love to learn how to avoid this very disgraceful solution)

...and...

5 hours ago, EpicSpaceTroll139 said:

I'm not an expert, but from my limited experience I would suggest changing the trigger from "WHEN SHIP:WATER=144 THEN..." to "WHEN SHIP:WATER<144 THEN..." (or >, whatever works best for you).

Or is it throwing some kind of error message? In that case I probably don't know what to do.

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!

January 14, 2017

6 hours ago, pellinor said:

Is there a way to check if a vessel name is valid? I'm trying to write 'set Target to Vessel("name")' in a way that does not crash the program if the vessel name does not exist (because it is docked to something larger).

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.

January 10, 2017

30 minutes ago, tseitsei89 said:

Oh too bad That would have been very useful information. But please do share your library I'll definitely see if I can understand any of it (I'm new to kOS and quite inexperienced in coding altogether...).

Please see my reply to meyerweb above yours

January 10, 2017

6 hours ago, meyerweb said:

I can verify this memory. I was recently trying to do “smart staging”, where the code would check to see if there were launch clamps and then activate first-stage engines appropriately. When I unleashed it on rockets I’d built and rebuilt, everything went insane, for exactly this reason. I was amazed to discover that the parts shown in the staging UI didn’t actually pick up the stage numbers shown there.

I certainly am!

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.

January 10, 2017

42 minutes ago, tseitsei89 said:

Noob question as I just started learning this.

How can I get the thrust and mass of the next stage of my vessel?

I need it because I want to calculate my burn time for a node accurately even if I have to stage mid burn...

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.

December 30, 2016

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.

December 7, 2016

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.

December 7, 2016

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.

November 6, 2016

1 hour ago, EmanonP said:

That's what I remember it doing months ago. Had a sat. contract to put one in polar orbit of Kerbin. Got to Kerbin orbit, and no AN/DN to transition to Polar Orbit. Like I said, no biggie, was just wondering if I was missing something.

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

November 3, 2016

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.

October 31, 2016

1 hour ago, Nibb31 said:

Snopes link in reply to Kerbiloid

Indeed... and the Russian gauge (1520mm) used in most of the former Soviet Union is wider than standard gauge (1435mm). Larger horses? :wink:

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

October 26, 2016

14 minutes ago, Jovus said:

@ElWanderer Thanks, that was exactly what I needed. I was missing the ARCSIN(TAN(current_latitude)/TAN(target_orbit_inclination)) bit, and trying something around converting to a ground track and comparing secants. (It was ugly. It didn't work. I'm not proud.)

Your method works like a charm.

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!

October 23, 2016

16 hours ago, Diche Bach said:

I'll have to try that.

So I've established, it is exactly a 137-degree inclination, which seems weird somehow.

From KSC:

directly east (azimuth 090) = 000.0 - degree inclination

directly north (azimuth 000) = +090 inclination

directly west (azimuth 270) = 180 degree inclination, no?

So why is "southwest" from KSC not > 180 inclination?

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.

October 20, 2016

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.

October 20, 2016

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

Profiles

Forums

Developer Articles

KSP2 Release Notes

Posts posted by ElWanderer