Search the Community

I wrote a script to do a skycrane-style rover landing on Duna, and then decided to make a cinematic instead of my usual script-showcase-style videos. This is the first cinematic I've ever made, and I also intend to make one for my Mun landing soon! Music: The Force Awakens, Trailer #1, John Samuel Hanson The Mole, Dunkirk OST, Hans Zimmer No Place On Earth, The Heart of Man, Tony Anderson All scenes were filmed in KSP 1.3. Mods used: kOS Camera Tools Distant Object EVE FASA Hull Camera VDS Kopernicus KSPRC Planet Shine Reentry Particle Effect Scatterer Texture Replacer Replaced Real Plume ...and many, many config edits in Scatterer, EVE, KSPRC, and Real Plume Hats off to the modders that make this game bearable to look at (and film)! Thanks for watching!

This is a very easy (but still hard), challenge, first and foremost the goals of the challenge. these are split into 5 levels. to progress onto the next level you must make an entry on all the levels before that e.g a level 5 entry needs a level 1, 2, 3 and 4 entry, if you get stuck go to the KOS documentation. the steps marked with an asterisk (*) are optional you do not need to complete that part of the challenge see below the goals of levels for the rules. level 1. 1. write a basic KOS script that gets a craft into orbit of kerbin, Gael or whatever kerbin-alike planet you wish. 2. write a KOS script to bring that same craft down from orbit. level 2. 1. write a script that can go to the Mun or any mun-alike body (hint: Vehicle must be like the saturn V with the conical fairing covering the LEM) 2. write a KOS script that can do a transreposition and docking (like on Apollo were they turned the CM around and docked with the LEM). 3. write a script that can do a insertion around that moon. level 3. 1. continuing on with the level 2 challenges you must write a KOS script that can land on the moon you are orbiting. 2. write a KOS script to ascend from that moon you have landed on. level 4. 1. write a KOS script to rendevous with the CM that is orbiting the moon (this level may qualify your name for a place in my signiture if it is a universal code). 2. create a KOS script that can dock. 3. retearn the spacecraft home from the moon. level 5. 1. create a KOS sciript that can go to Duna (or the planet packs equivelent) 2. land on duna. 3. go to ike (if it has a moon in the planet pack) 4. retearn to kerbin 4*. for extra credit, go to the moon. 5. re-enter safely and go home 5*. land near the KSC (100Km minimum) (Manley may be required ). secondly, the rules: (these are really simple rules). i know this challenge is possable because an old KOS dev did this challenge which is were insparation comes from this. 1. all parts mods are alowed (KOS is a requirement to complete this challenge). 2. don't cheat (no RO, or RSB without the stockalike patches) 3. KOS must control all aspects of the mission (Exept for EVA's and you actviating the scripts which is running the scripts from terminal). 4. most importantly, have fun coding these 5. you can use your old KOS scripts if you wish.

I recently had another series, 2mF, developing a KOS script to automatically fly, return and land boosters in KSP. I decided to try that again, this time with less "empirically determined values" and with explaining my code. This should make the script fit to multiple different missions, not just this one specific rocket. I hope to be able to demonstrate New Shepard, Falcon 9 and Falcon Heavy like missions. This also is an editing-learning-experience for me. So I hope the audio quality on the next video will be better, I am trying! I want this to be a community-thing, so I am looking forward to your feedback, improvement suggestions and criticism! Links YouTube channel Forum Thread GitHub Repo Modlist CameraTools for recording DistantObjectEnhancement little dots for planets and ships PlanetShine planet illuminating the vessel Scatterer better atmosphere and water kOS programming rockets Other Info Text Editor Atom Syntax Theme Solarized Dark KSP Version 1.2.2 Video Editing Software Adobe Premiere Pro Microphone Blue Snowball Hans Episode #1: Automated Booster landing development tutorial using a KOS Autopilot script. Inaugural episode: Dumb suicide burn with a simple hop. I promise the audio will be better next time! Also go to the YouTube video, to like and subscribe!

Know this would suck up my gaming time from my 0.235 rescue mission, I've started playing 1.2, and doing it with kOS to boot. R&D has just started studies on mixed cycle engine, and fuselages larger than Mk2. The latest production jet engine, the J-X4 "Whiplash" Turbo Ramjet has allowed the creation of a more efficient Single Stage to Orbit Spaceplane than The Reliant (powered by the "Panther" and "Reliant" engines). This along with the new Shock Cone intake lead to the design and production of the 3rd SSTO model, with the ability to accelerate at higher altitudes. In order to keep the CoM somewhat centered after the majority of the propellant mass was used up, the Whiplash engines were placed on the wingtips, as far forwards as possible. This gave the craft a distinctive shape, leading to the name, "The Diamond." Also, the Design Department was sick of SR-71 knock-offs. After many launch "simulations," a good ascent profile was developed for The Diamond. This was programmed into a kOS sequencer, and consisted of 10 steps, including a drop in altitude to accelerate past 400 m/s to "jumpstart" the Whiplash. The SSTO was able to achieve an 80km orbit with about 500 m/s delta-V to spare or 150km with 380 m/s. A new de-orbit program was created, and 2 launches were performed with orbital altitudes of 80km, and 150km (to match the Curie Space Station). The Automated Landing Program originally made for The Reliant was used successfully both times resulting in safe landings at KSC. (vaguely sung to the tune of "The Bonnie Ship the Diamond" made popular by The Corries, though I prefer the Gaelic Storm version). The Diamond's a spaceship me lads, To orbit straight she's boun', At KSC she is all garnished with auto-struts aroun' Jebediah gives the order, To orbit far and wide, Where the Sun it oft'n sets me lads, And darkness dims the sky And it's cheer up me lads, ne'r yer struts be breakin' For the Bonnie Ship The Diamond goes a fishin' for kraken! (sorry, out of lyrics. Also, got a bit of help from /u/morpheus1229 on that last bit on the chorus) After the two shake-down cruises, The Diamond's first real mission came up. To prepare for the first landing on Minmus, Gene wants to bring down veteran Scientist and Engineer Bill and Bob from Curie Orbital Akademy and Gas Station. Also, we need one other redshirt. To help finance this operation, a Tourist Contract was accepted for an Orbital Adventure. (that's The Defiant attached in this older photo) En route to the station, Jebediah is tasked to capture an empty capsule or cabin, which will be converted to a re-entry pod at Curie. The Diamond seats 2 in the cockpit, and 2 in the cargo hold. With the addition of the re-entry pod, there's enough space for everyone that needs to go planet-side. And to get one more thing in, a "Rescue a Part" mission was also accepted. Previous attempts to KLAW the PAL Humpback Truss with the standard sized KLAW were unsuccessful. Mission Control hopes the new "Baby KLAW" (Tweakscale) will have better luck. That totals 5 Mission Objectives Retrieve 3 kerbals from Curie Orbital Akademy and Gas Station Retrieve an empty pod from Kerbin Orbit and bring to Curie Station Release the converted pod for re-entry (Bill thrown in there) Give a Tourist an orbital adventure Rescue a module from Kerbin Orbit The two orbital retrieval missions will require a number of Hohmann Transfers, using up precious fuel. The plan was to do a partial refuel at Curie. As you can see, all mission objectives were accomplished! Looks like the Landing Script couldn't stick the landing. I suspect with manually pumping fuel in, and after the Part Rescue, too little fuel was left, compared to the previous successful landing runs. This lead to some instability, which fed into the ascent/descent PID Loop in the landing program, causing pitching oscillations. Eventually the craft did a back-flip, one engine flamed out, leading to an accelerating upside-down flat spin. This actually slowed the fall down, likely due to the left generated (like Helicopter?). Descent speed was less than 50 m/s until fuel ran out near the ground. Most of the expensive parts survived, and they made it within 35 km of KSC. Val likes to point out she did better in her SSTO crash landing from Orbit.

I'm trying to use the KAS winch with harpoon using kOS. I've been able to use events to extend and retract the cable, and with a little searching, detach the head from the ground. When I click Eject, everything goes well. The hook/head and cable fire out and attach to the ground (assuming it's in range) and then I assume the action taken when you click instant stretch takes place, making the length equal to the distance. Before it hits, the length is the maximum. However, calling the event to Eject only sets the length to max and unlocks/releases the hook (it remains attached to the cable), it doesn't fire out. Probably I'm doing something stupid, but what's the best/real way to do this?

I Recently downloaded KOS and I kind of have an idea of what I want to do. I want to script multiple scripts to achieve an Apollo style Landing on the moon and to do this I have decided on the scripts I want to make.. The first one is the auto-launch program where the craft goes up to 5 - 10 km then preforms a gravity turn and is put on a heading until the objective altitude is reached then it coasts to Apogee then makes the circularization burn I also want it to script the if negative vertical velocity to trigger the abort action group and switch to a file that contains procedures for the abort to jettison the les and to deploy the parachutes. I need a program that will execute maneuver nodes, a lunar landing Descent and Liftoff, a reentry autopilot for displaying heat shield integrity and action groups. I will also need a few micro managing programs that I think I can code my self and some of this I may be able to do since I do not fully understand the Kerbal computing language.

So I am playing with KOS and it's pretty hard to find some up to date tutorials (the documentation on github is fine! But Finding scripts that work or people willing to help isn't that easy) so I thought I'll just publish stuff I do and did here. Maybe someone else is just looking for a bump in the right direction or my future me thinks "how did I do that the last time?!". I'm a noob and teaching that stuff to myself is a whole new experience and I enjoy it. So this thread is where I'll dump stuff that works - maybe someone finds it usefull maybe someone posts something usefull. Have fun! Mods I used (wich are needed for the .craft files to load): - KOS (obviously) - MechJeb Crafts: 1. TKO (Tourists Kerbin Orbit) A rocket to bring 2 tourists into orbit and safely back to kerbin. picture: .craft file (just copy and paste into a editor and save as *.craft in saves/ships/VAB/*.craft) .ks file (script) (just copy and paste into a editor and save as *.ks in kerbal space program/ships/script/*.ks) It's a basic orbit script wich works nicely, has documentation and prints some stuff into your kos-terminal. 2. TKO (Tourist Knockout Suborbit) A rocket to bring a tourist to space and knock him out before bringing him back to the surface. picture: .craft file (just copy and paste into a editor and save as *.craft in saves/ships/VAB/*.craft) .ks file (script) (just copy and paste into a editor and save as *.ks in kerbal space program/ships/script/*.ks) This is as simple as it gets, no ifs, no loops - just a line of commands.

I'm coming across what I think is a bug in Unity's font system that makes it hard for me to "be nice" to other mods and not break them. This problem is weird and what I've learned so far is from a few weeks of on/off trial and error and experimentation. I could be wrong about the cause, but I've barked up a lot of wrong trees already trying to find other possible causes before settling on what I'm about to describe below as what I think is the cause of it. So what's the problem? These two Unity methods Font.GetOSInstalledFontNames Font.CreateDynamicFontFromOSFont can break fonts that are also in a Resource/Asset file if these steps happen in this order: 1: Unity loads a font from Resource or Asset files, but hasn't had any occasion to draw anything in that font yet. 2: Using Font.CreateDynamicFontFromOSFont(), You create another Font instance that is for a font the same font family as the one from step 1 above (i.e. loading "Arial bold" when "Arial" was loaded in step 1.) 3: The font from step 2 (DynamicFontFromOSFont) gets rendered into some text. 4: The font from step 1 (From the Resources or Asset file) gets rendered into some text. When you do the steps in that order, then Unity gets confused and seems to wipe out all the glyphs of BOTH instances of that font from then on (i.e both the one from the Resources and the one from the OS). From now on it will render all text in that font as blank, (and it now claims that all text drawn in that font is 0 pixels wide and 0 pixels high, so things like GUILayout buttons get shrunken to minimum size in addition to not being able to show the labels on things because the font is blank.) Note that if you swap steps 3 and 4 so the Resources font gets exercised in some way before the DynamicFontFromOSFont does, the bug does not happen! It only happens when the first attempt to draw something in the font instance that was built from the OS font call happens prior to the first attempt to draw something in the Resources instance of that font. Note that it's the order in which the fonts get USED to draw something that matters here, not the order in which they first get loaded. (i.e. you can swap steps 1 and 2 and it doesn't change the outcome). As you can tell from the fact that I used "Arial" as my example case above, this means when we do this in kOS, I have the chance to break every other mod that uses Unity's default GUI.skin for something. Oh, and this isn't just about using the legacy IMGUI. I noticed that the act of using the font *anywhere* in Unity is affected, even when I draw 3D hovering text in Arial in the game scene - if the Arial font has had this bug trigger, then that 3D text won't show up. I can trigger the bug by choosing to render font text into a Texture2D in memory that I don't even show on screen anywhere. Even rendering it that way triggers the same problem so long as I do it in the order shown above. Why did I want to do this?: At this point, the person reading this might be thinking, "Well then just don't do it! Stop using the OS fonts and instead ship with one and hardcode it.") So I feel I have to defend my desire to support doing this: I'm trying to let the user use any font on their OS as the kOS terminal font, and move away from our current technique of cutting and pasting regions from a texture file that contains images of the 128 ASCII chars. (For 2 reasons: Using a real font scales a lot better than stretching a bitmap image for those users who prefer the terminal to use a bigger font, and more importantly it would let you print to the terminal in your preferred language, for which you probably already have a font you like installed on your computer that's better for that purpose than whatever we might ship with. But wait, isn't it only a conflict when you actually try to RENDER the font? Isn't the user just picking one font, not every font on the OS? True, but Unity does not expose any of the metadata about a font until after you load it, and even then you still have to actually render a few characters with it before all that you need to know manifests itself. If you haven't loaded a font from the OS yet, then the font's string name is literally the only thing you know about it. You don't know if it's bold, italic, etc (except from making a heuristic guess from looking for substrings in the font's name like "this font's name has the word 'bold' in it. I guess it must be a bold font then.". Most importantly for my case - you can't tell if it's monospace or proportional until after you load it and try rendering a few characters with it. The font metadata isn't available through Unity. So I was doing a quick dummy render of a short string containing some wide and some narrow characters, and counting the pixels Unity reported it took to do so to find out if it's monospaced or not. This is relevant since I use the font to paint a terminal very fast by drawing each line of the terminal as a single string - I need to restrict the picks the user is allowed to the monospace fonts only. It's that test for monospace that mandates that I actually give each font an experimental test render, and it's doing that which caused me to trigger the bug this post is talking about. I thought this would be really slow at first (test render every font) but it turns out that even on a computer with a few thousand fonts installed it only takes a couple of seconds, and I only have to do it once and then never again (and I can throw away the font after I tested it so it's not eating up memory once I learned it's proportional). So why not just avoid it by forcing the order to come out the "safe" way? An obvious fix presents itself: Before trying to use any Font that comes from CreateDynamicFontFromOSFont, kOS could just make sure to iterate over every Font object that ii finds in the Resources and perform a dummy rendering with each of them. (i.e. Tell it to render "Hello" into a Texture2D, then throw away the Texture2D, just to exercise the font a bit first which seems to prevent the bug.) I have tried that and it does work.... but... read on: I'm not in control of the order that OTHER mods do things in, nor am I in control of what order Unity chooses to call the Awake() and Start() methods of all the Monobehaviours from all the mods, nor am I in control of whether or not other mods might try to wait and lazy-load a font dynamically from an asset bundle later on during the game. This means there is no point in time when I can reliably answer "yes" to the question: "At this point have all the fonts that will ever get loaded, during the life of this process, from any Resource/Asset, been loaded and we know there will be no more?" In order to reliably use this workaround to fix the problem, I have to do so at a point in time when that is true, otherwise there will be a Resources/Asset font I missed when I performed the "foreach Resource font, render something small with it" code. So now to the questions for other modders: (1) How many mods actually bother trying to ship with their own font? Then again, with SQUAD doing localizations in the next release, who knows if maybe even THEY might wait to load a font later on after game initialization so I can't rely on knowing if they will do so. Could it be so few mods that the solution is to simply see if we happen to break another mod and if so then react to that and work with the other modder to come up with a scheme to force a known loading order between the fonts used by our two mods? (2) Do I need to consider splitting this work off into a standalone font manager mod and then make kOS require it as a dependency? Then any modder that wants to load fonts should have to work through it instead of doing it on their own? (i.e. similar to other library-mods like the CommunityResourcePack, the goal of such a mod would be to make sure all font loading happens in one place where the order can be enforced to prevent the bug.) (3) Any suggestions for a workaround that I might not have tried? I'm really not a Unity expert at all. The only things I know about it I know from doing kOS dev work. Yes, I am aware of the fact that Unity lazy-loads font glyphs (I found that out when trying to implement other parts of this system) and therefore the need to use Font.RequestCharactersInTexture() before attempting a test render to look at character size. But I suspect the bug above is somehow related to this lazy-loading feature misfiring in some way so the two different instances of the same-named font are stepping on each other's toes, or maybe Unity is getting fooled into thinking it already performed all the lazy-load work for both versions of the similarly named font when it really only did so for one of them. (Thus the font's data never gets populated because it thought it already did so?) (4) As KSP gets more international users, will more mods start considering using their own fonts so that even though this might not be a problem today it will become one soon so I still have to worry about it? (5) Is this a known Unity bug that was already fixed in a release of Unity but we don't have it yet because KSP is a few revisions behind? If so might the problem magically fix itself in the next KSP release? I tried searching Unity's issue tracker for font-related bugs and spent a long time walking through them and not finding anything that seemed related, before I gave up on trying to do that.

I'd like kOS to calculate the velocity at periapsis for me with the apoapsis height, periapsis height and apoapsis velocity as variables. However, if one is using the specific orbital energy v2/2 - µ/r = constant, you must know the standard gravitational parameter. I could hardcode the values into my script for every celestial body, but I want it to be as general as possible (if you decide to alter the default masses with mods etc). How do I get rid of the dependency of µ in my formula?

I have not been playing KSP a lot the last few years after I quit building space planes. Was a bit hard to find something fun to do motivating me to play but eventually I decided to use KOS and do some scripting. I cant code or script realy so that was interesting After doing some scripts that could take a specific rocket up in orbit or a spaceplane up and land I decided I needed something "Universal". Even with a handful of scripts and rockets when I played career with limited parts one have to invent rockets as the parts are unlocked so realy my new shiny rockets and there scripts where useless until the "end game". So I needed something that worked with most rockets. That is when I started to work on my "Universal Rocket Launch System" or URLS as I like to call it. Its written for KSP 1.2.2 and KOS, I suppose never versions "should work"? You can download the script here. https://dl.dropboxusercontent.com/u/27196441/urls.zip The goal with the scrip is to put ANY payload in a 100-103km Low Kerbal Orbit. Now Im no programmer or scripted, And Im definitely not good at maths so my "formulas" might be a bit strange but they get the job done at least tough there not always as precise as I would like them to be. The script consist of a number of guidance modes. But basically the rockets pitch is calculated and set based on its altitude using a formula I created. The rockets velocity is calculated based of altitude to using a formula I derived and the engines are throttled accordingly to maintain proper acceleration trough the gravity turn. I actually derived my gravity turn formula used for the pitch with a rocket I called the Delta I. It could naturally do a gravity turn so I recorded that data, created a simple script that mimicked that and also tuned the thrust of the stages accordingly. Once I had this simple script I had enough data to create the gravity turn formula I mentioned earlier and the formula for the target velocity and all other formulas I needed. Now the problem is that not every rocket behaves like the one I used as a benchmark, the Delta I. The most common problem I noticed was either a to powerful first stage and a weak second stage and this created a problem. If the second stage is to weak aka low TWR it will not gain altitude fast enough, basically it will fall short of the intended profile of the gravity turn. Since the velocity is calculated based on altitude a second or 3:e stage could actually find it self costing at a pitch up attitude and just run out of fuel since the script did not demand full thrust because the orbital speed at that altitude was meet. As fare as the script was concerned the orbital velocity at that altitude was correct and sure it was but since vertical velocity was around zero the stage would just cost until the fuel ran out. So my next guidance mode I had to create is also based of altitude BUT the formula I derived calculates what time the rocket should be at that altitude. If we assume the rocket turns as programmed by she script and accelerates properly we should always know at what time our rocket should be at a specific altitude. So this secondary guidance mode basically calculates the time the rocket should be at Altitude X and it checks that against the time since launch and if we are ahead or behind to much this guidance mode takes control over the throttle. This mode wont allow the velocity of the rocket to go below 90% of the velocity that was the target, simple reason is that we dont want the rocket to fall out of the sky but other then that it can override the velocity as much as desired to "catch up". This secondary guidance mode will allow even a second or 3:e stage to coast in to orbit. Usually when the second or 3:e stage struggles to get in to orbit its usually enough just to move fuel from that stage to the previous stage, that gives more D/V on previous stage and a lighter second or 3:e stage giving them better TWR. The last guidance mode is basically there to put the rocket in LKO and this mode is activated either when the AP is deemed high enough or the rocket is high enough in orbit. To be able to understand what the script is doing I created a User Interface. It will show useful data the script uses and what guidance modes are in use and what part of the script has completed. This is very useful when designing a rocket to fly with the script. One can pretty easily determine if a stage has the proper TWR or not for example or adjust thrust limits on solid rocket boosters for example since the script has no control over those. I will now explain what the screen shows from top to bottom Apoapsis altitude - this is just apopasis altitude in meters so pretty strait forward Periapsis altitude - this is your periapsis altitude in meters. Vertical speed - this is your rockets vertical speed in m/s so useful to tune thruster limits and engine configurations. Vertical speed target - this is the vertical speed in m/s your rock should travel at the first 1000m after launch. Orbital Velocity - this is the orbital velocity in m/s of your rocket and its used for simplicity from launch to LKO. Velocity deviation - this shows the difference between the calculated velocity and the actual velocity in m/s the rocket is travelling at. Positive number and the rocket is going to fast and a negative number and the rocket is going to slow. Time in flight - this is the time the rocket has been flying since launch shown in seconds only. Deviation from ideal trajectory - this will show you how much behind or ahead in time in seconds the rocket is on its trajectory, ideally you want no deviation but some will eventually occur as the rockets vertical speed declines the accuracy is reduced. Target pitch - this shows the pitch the rocket is suppose to have not what it is, apparently it was very "hard" to script something that would show the rockets actual pitch so you should check this pitch value against the navball to make sure your rocket actually has the authority to pitch over as demanded. Then we have guidance modes. Only one guidance mode can have full authority at a time and what mode has authority will be shown with the word "Active" next to it. Vertical Velocity - This guidance mode is used the first 1000m of the accent, the rocket tries to go strait up and accelerate at a predetermined rate. Orbital Velocity - This is the primary guidance mode for the gravity turn and the one you want to spend most of the time in. It controls the velocity of the rocket according to altitude and should work for any rocket with good enough TWR. Time deviation - this is the secondary or fallback guidance mode. Its primary job is to take control from "Orbital Velocity" guidance mode if the rocket for example has an excessive TWR, like solid rocket boosters that was not properly configured with a thrust limit. Its more commonly activated when a second or 3:e stage has a to low TWR and it will make sure full throttle is used to try and coast the rocket in to orbit. I have also had instances where boosters smashed one of my main engines of and then this mode could save the rocket to. You dont realy want to be in this mode because then your rocket is not balanced to work well with the script but since this guidance mode is based on altitude it will be less accurate at say 50km or higher since the vertical speed decreases and the rockets starts to level of so even the best rockets might spend 10-20 sec in this mode before going in to the last guidance mode. This mode is also triggered if the rocket is 5 seconds behind or ahead of its intended point in time. Orbital Manoeuvrers - this is the last guidance mode and its basically there to get your in to LKO. It is activated either when the rocket has high enough altitude or when the AP is high enough. We dont want the AP to go higher then the intended LKO do we. The last part in our User Interface is Mission parameters. The word complete will be shown next to a mission parameter when it has been executed. Gravity turn - gravity turn is completed. LKO - rocket is in a stable Low Kerbal Orbit. Payload delivery - payload has be deployed. Deorbit burn - the orbital stage has done a retro burn and will now reenter Kerbin at 30km altitude and burn up. Now there area few other things that needs to be mentioned about the script. If an attribute in the User Interface reads "null" the that only means the data is no longer correct or available and therefore no data is shown to confuse the user. The script will check for engine flameouts and will stage as long as there are flamed out engines. The script will also check for active engines and stage until active engines are detected. Every time the rocket stage it will default to full thrust on the engines just to make sure it wont fall behind on its intended trajectory since the TWR will usually be lower with a new stage then an empty one. The scrip uses action group 10 to jettison faring or anything else you want to get rid of, this will happen at 54000m. If you want to jettison your faring earlier you can have that in your staging sequence as usual. The reason I opted for 54000m to jettison fairings is the the fact that I got destructive wobble with 3.75m parts up to about 50000m. Since the script is universal I need a safe altitude to deploy the fairings. The script will stage one last time in orbit to jettison then payload, but action group 9 is also triggered and can be used to separate a payload from the last stage and also extend antennas if you need an uplink to control the payload. Also the scripts formula to estimate velocity is a bit off in the early part of the gravity turn compared to the rocket it was designed for (Delta I) so its pretty common for it to report that the rocket is a bit behind in velocity but still show that the rocket is on time aka no Time Deviation. Try out the Delta II rocket supplied with the script for a good benchmark rocket to use as a reference. For the first stage I usually use a TWR of 1.5 based of the Vacuum numbers, if I use the atmospheric numbers I tend to go with 1.3. The scrip is primarily intended to make launches easy and routine and not to make them the most efficient to save that little bit of fuel. You should tune your rocket so it spends most time in the "orbital velocity" guidance mode for best performance but the script is intended to fly pretty much anything that can be flown manually tough its not designed for space shuttles. I have tested pretty much all my rockets, good and bad once and also most stock rockets in KSP and they do work (staging order might need tuning tough). You can download the script here. https://dl.dropboxusercontent.com/u/27196441/urls.zip It will include the Delta II rocket (improved version of the Delta I but performance the same) and also a Soyuz ST (picture below) that I designed using the script. I would recommend flying them first to get an idea of how the script works and how you can use it to tune your rockets. So now its up to you to break my script and tell me what it cant do So feel free to post any good or bad launches in this thread.

I tried my best with this video hope you liked it guys! Thanks

I'm trying to write a general one size fits all launch script based around Powered Explicit Guidance, but the math is way over my head, and I'm not quite patient enough to write all those formulas... Can someone help me develop this? I want the final product to be able to pilot a ship from the launch pad to an orbit defined by apoapsis. periapsis, inclination, longitude of ascending node, and argument of periapsis, with the first two being the only mandatory arguments. I am using a heavily modified (mostly trimmed) variant of Seth Persigehl's launch script for the in-atmospheric flight, including open loop pitch control and open loop heading control. PEG will kick in once the second stage starts, and the rocket's engine will not shutdown or throttle significantly until cutoff - the rocket will make orbit in one long burn.

Kode: The IDE for kOS Current version: 0.4.0 I have made a simple IDE for use with the kOS autopilot. At the moment it is not much more than a notepad clone with syntax highlighting, but everything has to start somewhere right? One neat feature it currently has is the ability to export your script straight into your kOS scripts folder(Once you visit "Settings" and tell it where KSP is installed). It also has some basic code completion. Eventually I plan to add quite a few useful features such as intellisense, Error detection(Such as forgetting your '.' end of line), Compiling and debugging, Tabs and a tree file viewer(Such as in Visual Studio) to allow for easier development of multi file programs. I will also be adding the ability to import your libraries with one click, Telnet control(For multi monitor users, Have Kode open in one screen and KSP in another. Code and run at the same time!) and the ability to create a script by clicking and dragging blocks together(Think Lego Mindstorms) which would be useful for a user who wants to use kOS but doesn't want to learn how to code it for whatever reason, This won't happen for a while though. I am planning for a Linux and Mac build in the very near future. Why Kode? It's a portmanteau of kOS and IDE, But it is also Code with the compulsory Kerbal 'K'. I thought it was pretty nifty. Kode is released under the GPL v3 licence. Note about the Linux version: Due to complications porting a dependency over to Mono Kode depends on Wine and this should be installed before Kode. With version 0.4 Kode has the features to hopefully rival whatever program you currently use and as such I am changing focus from smaller updates more often to bigger updates less often with a focus on stability. Download You can download Kode here: https://github.com/TN-1/Kode/releases Extract the zip making sure all files are in the same folder and double click to run. You can view the source over at Github: https://github.com/TN-1/Kode Changelog 18/1/2016: 0.1.0 - Initial release 24/1/2016: 0.2.0 Steam install auto-detection Open and Save As dialogs default to KSP/Ships/Scripts(Per the steam install detection) Dark mode Upgrade detection(Tools>Upgrade) 10/2/2016: 0.3.0 Tabs! Linux version! Fixed issue #1 through use of try-catch. Changed undo/redo behaviour: Buffer now 10char long with (hopefully) unlimited actions Added report bug and kOS docu to help menu Added graphical toolbar Export code in markup General code cleanup 20/02/2016: 0.4.0 Reworked steam install detection Reworked session restore when settings changed(Issue #4) Redesigned the settings menu(It finally looks good!) Added support for multiple installs(Steam or not)(When you add the install, Make sure it is too your root KSP directory) Added support for lowercase syntax highlighting(Issue #5) Added the code minimiser at long last, It will strip comments, empty lines and double spaces. Tweaked save all and save as behaviour. 08/04/2016: 0.5.0 Project mode added Support for libraries Upgraded Linux Installer Windows Installer Add support for opening files via explorer Added auto indenting Added tab space setting for auto indenting Added keyboard shortcuts Added a code minimiser Added column count Removed now defunct "Export to KSP" button Kode now checks for unsaved changes on exit Kode now supports launching by double clicking files in explorer(See known issues below) Fixes bug where Kode crashes when you open with no tabs Fixes bug where Kode crashes if you don't select a folder on first start Fixes bug where Kode will treat recovered tabs as new ones on setting change restart Fixes beta bug where Export to KSP crashes when not in project mode Worked around a bug where Kode auto restart doesn't change UI correctly. Manual restart is required after changing editor/project modes. All changes to file will now trigger an *, not just additions Tab close X behaviour tweaked Syntax highlighting and autocomplete now support UPPER, lower and Mixed Case without changing settings Update auto-detect(Added in 0.4 but this is the first release to use it) Current known issues File associations as set by the installer doesn't work correctly. You need to manually set Kode as the program to open .ks and .ksproj through the Right Click>Open with menu, Select Kode and Always Open with. Autocomplete for mixed case is bugged, after typing an uppercase first letter and then a lower case second letter the A/C box disappears. Syntax highlighting is unaffected.

The Boffins have not been idle despite it having been a long time since the Circus did anything. No, they've been hard at work testing and tweaking stuff for the next chapter of the Glorious Kerbal Space Empire. Their current project is to develop a kOS script to facilitate the deployment of what they call "Moonsats". In the Circus concept of communications networks (see the link in my sig), there are 2 general species of commsats: Main Relays, which have huge antennae and are in highly eccentric polar orbits over the central body in each planetary system, and Moonsats, which are in moderately low circular orbits, usually but not necessarily around moons of the central body. There usually needs to be more than 1 of these latter per "moon", and they need to be spaced neatly, and that requires more math than the Boffins want to do manually. Thus, the goal was to make KAL9000 (actually the name of the computer part in kOS) do crunch the numbers for them . Anyway, the project has gone from the drawing board to partial implementation and successful completion of early milestones in the course of today. The Boffins are feeling a little proud of themselves so decided to show off what they've done so far. And here it is: Really, that's all it does right now, just calculate and display those 5 particular numbers, only 2 of which are really important at the moment. But that was the main challenge. The rest of the project should be somewhat simpler as it traverses known ground. Today the Boffins had to learn more about the "anomalous rectums" (actual technical term) of orbits than they ever wanted to know . There's a non-negligible amount of code and a lot of research behind this simple display. The idea of the whole project is as follows: A carrier vehicle (CV) with 3 moonsats aboard gets into an elliptical orbit at the desired inclination around the body the Circus wants to hang a network on. At this point, the kOS script is activated. The kOS script figures out a good altitude for the moonsats to orbit the body and adjusts the CV's Pe to that altitude. The kOS script determines the orbital period for a circular orbit at this altitude, then multiplies that by 1.33333 to get the desired orbital period of the CV. The kOS script calculates the Ap needed by the CV to have that orbital period and adjusts the CV's Ap as needed. Once so adjusted, the CV releases 1 moonsat per orbit, each of which then circularizes at the Pe of the elliptical CV orbit. Because the CV's orbital period is 1/3 longer than that of the moonsats, each time it or a released moonsat reaches Pe, it will be 1/3 of an orbit behind the previous moonsat, so they end up evenly spaced and able to see each other around the body. To accomplish this, the Boffins broke the project up into phases: Phase I: Develop the basic algorithms for computing the required orbital parameters, in such a way that the same script can be used at any body with a reasonably large SOI. Just print these numbers on the screen and test their validity by performing the necessary maneuvers manually. This is actually the only important phase because the system is workable at this point. The later phases are gravy. Phase II: Add the ability to deploy n >= 3 satellites, and add automation so the CV performs all maneuvers itself. Phase III. Write a separate program for the moonsats so they can tweak their own orbits automatically. Today, the Boffins are please to report that Phase I is complete! It's that output which appears in the pic above. The process starts by determining a "good" altitude for the moonsats. This has to be high enough that they can see the adjacent moonsats sharing the orbit without the planet in the way, plus have some margin of error for imprecise maneuvers getting there. For the 3-moonsat problem, this altitude is determined as follows: The desired quantities are the line CS (for calculation purposes) and also CS minus the radius of the planet (orbital altitude for maneuvering purposes). The length of the line CF is arbitrary, whatever you think gives enough clearance between the edge of the planet (and atmosphere, if present) and the LOS between adjacent moonsats. In Phase I, the Boffins chose 120% of the body's radius. This turned out to be just a tad too short in practice, so will be increased to 150% in the next round of testing. In any case, for the 3-moonsat problem, Triangle CFS is a 30-60-90 right triangle so with CF given, calculating the length CS is just 1 trig function away. The next step is to calculate the orbital period for a circular orbit of radius CS. Just plug the numbers into Kepler's 3rd Law: T = SQRT[(4 * π2 * R3) / (G * MP)] where T is the period, R is CS, G is 6.673 x 10-11, and MP is the mass of the body you're orbiting. Simply multiple this value by 1.3333 to get the period of the CV/s desired elliptical orbit. It was at this point that the Boffins started running into all the "anomalous rectums" and thought they were going to have to do a bunch more calculations using them to figure out the CV/s desire Ap by way of the semi-major axis. But fortunately, the Boffins figured out a shortcut after a chance reading of a footnote buried deep in dense pages of complex equations. That life-saving footnote said this: "A circular orbit with a radius equal to an elliptical orbit's semi-major axis has the same period as the elliptical orbit." The Boffins already now had the period of the elliptical orbit so could plug that back into Kepler's 3rd Law (above) rearranged to solve for R, which in this case would be the semi-major axis of the CV's elliptical orbit. R = [(T2 * G * MP) / (4 * π2)]^(1/3) Then, because the planet is at one focus of the ellipse, the altitude of the CV's desired Ap would simply be: Ap = [( 2 * SMA ) - CF] - the body's radius. Wow. That wasn't so hard, thanks to the shortcut Anyway, with all these numbers determined, the script simply printed them out as shown above. All this worked fine at Kerbin in an equatorial orbit but to really test Phase I, the Boffins sent a wad of 3 moonsats to Mun and had them arrive with a 60^ inclination. Here they all are still attached to the CV en route to Mun. And here they are being deployed, all being flown manually using the numbers calculated by KAL9000 using the script. You can see the CV is in a slightly elliptical orbit with the 1st moonsat in place and the next in-process. With all 3 moonsats in place, the Boffins de-orbited the CV. As it turns out, 2 of the moonsats can't quite see each other and the others are borderline due to their orbits being a shade too low. As mentioned above, fixing this is just tweaking 1 scalar value so really isn't important here. What is important is that the Boffins managed to code this script without any egregious logic errors, despite not knowing much about fancy orbital mechanics, and that the algorithms work well enough to provide good results even with substantial rounding errors (for clarity in the display of the numbers) and the imprecision of manual flying. So now the Boffins are celebrating with their traditional whiskey and wondering if it's even worth the trouble to go on with Phases II and III.

kOS-SCANsat is an Addon to kOS kill Kerbals in new and exciting ways. It allows you to use the inaccurate data provided by a low resolution scanner to be used for mission planning**. It is designed to provide a "realistic" way to plan your missions and forces*** you to scan your landing side before you send a lander. Features: Low and High resolution altimeter scans Biome scans Resource scans slope data (and highly inaccurate slope data for low resolution scans) KerbNet Scanning of the current vessel. (only for biome and altimeter) ** you should bring a KerbNet compatible scanner with you, so you can prevent the worst. *** actually it doesn't remove the magical geoposition:terrainhight suffix, but using that is now considered cheating Requirements: KSP 1.3.1 kOS 1.1.5.1 SCANsat Full Documentation: Documentation of the API Downloads: Get the latest release here Source code is here

Computers and space have fascinated me for as long as i can remember. The combination, in the form of automated probes, even more so. In the real world it is not uncommon that a probe develops one or more problems. My goal is to develop a system consisting of software and processors with kOS which is as fault tolerant as possible in KSP. You might ask yourself: Why a multiprocessor system, Isn't one processor enough? Well, frankly one processor is definitely not enough. First of all, errors (in code and hardware) WILL happen. Error can't be caught by kOS. Any error will stop the processor executing the program. With just one processor, your probe is essentially dead and a total loss. kOS does allow the user to control the craft after such a fault occurs. That means that there must be at least one other processor on board which takes care of communication and such. In the system i want to (will!) develop, there will be no hidden processor(s) like that. If a processor halts, it must be reset bij another processor on the probe and not by typing commands in the terminal window. Another reason why using multiple processors are required has to do with computerarchitecture. Any computer, from large mainframecomputers to even mere PC's, has controllers which take care of specific tasks. In theory, the CPU could do all those tasks but it would make the computer very slow. Most probably, it would render the computer impractical. With controllers, the CPU can delegate certain tasks and continue with it's own workload. It makes the computer faster and more fault tolerant. After a controllerfailure one function becomes unusable but not the entire computer. The third reason is that the complete system can be less complex and more modular. I will be using several mods, some are really required, some are not. The most important are: Remote tech Universal Storage - Provides an easy way of placing multiple processors on a craft (i don't like to use multiple HAL9000's for several reasons) kOS (1.0.0) - Will be upgraded to release 1 as soon as some bugs in that relase are solved. MechJeb 2/MechJeb 2 embedded - Will only be used to display flightdata and will be removed when a kOS processor does that. Scansat - For science subsystem and testing. Kaboom - Used as selfdestructmechanism. Procedural parts - Will only be used if it is unavoidable. (has been removed) KSP 1.1.3 64 bits - The 64 bits 1.0.0 kOS version works correctly (the 0.21.1 version did not). Mods which are not essential (but can provide eye candy or might be usefull): Aviationlights - lighting the probe and possibly also as "indicatorlights". Agext / Modactions - For easy programming specific tasks like opening/closing solarpanels HullCamVDS BD Armory - FLIR and IR camera Launchnumbering KerbalAlarmClock KerbalJointReÏnforcement I probably will remove (parts of those) mods when they're not used to save memory space. I will be adding some modified parts as well (a universal container as kOS processor f.e.).

Hi, I'm fairly new here and I know it's pretty presumptuous of a noob stepping right in and asking for help. But I'm going quite insane. I have tried flying with keyboard commands and, no surprise, I suck at it. For three days now, I've been desperately trying to write a KOS script that does a few very simple things. Not even involving the ship changing orientation a single time. Really just straight up and straight down. The ship CAN do all the things, if I play around with MechJeb to assist keyboard control, it all works (within the limits of my utterly rubbish control abilities). But there is one specific little item holding me up. That had me write and rewrite my script and try it out dozens, possibly a full one-hundred times. The problem: I want it to drop the SRBs when those are empty. I've given all the SRB's a name tag and have desperately tried all (and I do mean ALL) combinations of my name tag, the enumerator I stuffed with all the tagged parts, SHIP, SOLIDFUEL and AMOUNT. I've also tried out checking for FLAMEOUT. Nuffin. I've tried the little "THESE ARE ALL THE RESOURCES ON THE SHIP:". script snippet from documentation site on Github. That works fine and lists a resource "SolidFuel". Yet when I ask the terminal to PRINT SHIP:SOLIDFUEL:AMOUNT., I get an error that AMOUNT is an unknown variable. When I stop the line at SOLIDFUEL., I get the number 1436. So that works. Yet when I try PRINT SHIP:PARTSTAGGED("booster"):SOLIDFUEL., I'm told SOLIDFUEL is an unknown variable. The parts in question ARE tagged "booster", of course. I don't want anyone to go and write me a whole script, of course. Just an example how I can get the SolidFuel from a specific set of parts and a little explanation would be absolutely lovely. Please? I suspect I have a fundamental misunderstanding of the entire syntax and structure. But neither going through the GitHub documentation nor trial and/or error have enlightened me.

After some time working on my KOS script I was able to make a 100% automated Relay System set-up. Craft file will be up soon. AALAUNCH: http://pastebin.com/6ymKdmRK What it does: Countdown Can detect when asparagus staging stage needs to be staged Gravity Turn Circularization (100 x 100 km) ABORBIT: http://pastebin.com/VHnVAab2 What it does: Calculate how much Dv is needed to go from current orbit to desired orbit (750 x 100 in this case) Burn to exactly desired orbit (with margin of 0.1 meter) Calculate how much Dv is needed to go from current orbit to desired orbit (750 x 750 in this case) Burn to desired orbit, kinda... (due to not being able to burn all the Dv at once at the Ap +0 results will vary: Margin +- 500 m) Activate Relay Sat's solar panels and Omni Stage Relay Sat (Force of decoupler has been taken into account, roughly) ACORBIT: http://pastebin.com/5jv3YZkM What it does: Decrease orbit so the orbital period is lower, spacing the sats evenly (roughly) Increasing the orbit to a circular 750 x 750 orbit again (And ofcourse calculate how much Dv is needed) Stage Relay Sat (Force of decoupler has been taken into account, roughly) ADORBIT: http://pastebin.com/B9EFF7th What it does: Same as ACORBIT: Decrease orbit so the orbital period is lower, spacing the sats evenly (roughly) Increasing the orbit to a circular 750 x 750 orbit again (And ofcourse calculate how much Dv is needed) Stage Relay Sat (Force of decoupler has been taken into account, roughly) I'm sure I could improve some things (feel free to say what could be done better), but anyways, this was tougher to make than I thought it would be it kind of succeeded. Ps, ran a test and visible separation occurred after ~100 days which isn't that bad, right...

I'm pretty new to KOS so I have a few questions: Lets say we use this code from here . When it enters space I want to add some code: lock steering to prograde. wait until eta:apoapsis < 30. lock throttle to 1. wait until eta:apoapsis > 50. lock throttle to 0. wait until periapsis = 100000. How do I make this a loop and how do I deactivate the loop when Periapsis is = 100000?

In the terminal these characters show up and behave like the letters shown: ` turns into P ~ turns into S ^ turns into R ' turns into Q " turns into W There is a message about tinyPG. In the editing terminal the e, r and the d keys don't even show up. How do I fix this?

I spent three days trying to write a hoverslam script from scratch. I was trying to look for ways to cheat out of having to account for changing mass and acceleration, and I was totally stumped. Some of my prototypes were 40+ lines. Then it hit me. Slapped this together in 5 minutes, and now I've got worry free hoverslams for any body, and any lander with a TWR > 2 (even lower with a small tweak). I posted this in the "What did you do today?" thread, but wanted to share here, since I'm really proud of it. See my sig for more kOS videos!

As the topic says, I need to calculate the force of drag on an arbitrary rocket for use in the function for finding terminal velocity. I am working on an ascent guidance script for kOS, in case you were wondering. EDIT: Apparently as of KSP 1.0.x this doesn't matter any more.

Hi all, since kOS don't support subfolders (yet?), I've a bunch of scripts and also I hate to alt-tab all the time. I made this plugin, so I can manage my scripts without alt-tab too much in a poorkerbal way . The plugin search for folders starting with "arch_" in the KSP stock Ships folder (the one where the folder "Script" of kOS lives), it makes a list of those folders and you can now change between them at wild. It's possible also to create new archive folders on demand. kOS will do the rest as is always looking for changes in the "Schips/Script" folder. Under the hook the plugin only do renames and remembers the name of the archive folder in use for later restore. So if you are using the default archive folder (ie: you just installed the plugin) and you change the archive folder to use in the plugin, it will rename the original "Script" folder to "Script_orig" and the one you wanna use to "Script". You can restore the original one in any moment or change the folder to another one without previously restore the original. The actual archive in use it's visible in the plugin window tittle, empty if the original one is in use. Now uses git instead of plain folders as I'm now using git to manage my kos scripts. Not tested in linux. It's supports Toolbar and if it's not present fallbacks to ksp applauncher. Also has a configurable keybind ("ALT + Y" by default, configurable in "GameData/kos_ma/Plugins/PluginData/kos_ma/config.xml"). Screenshots: Download: https://github.com/hashashin/kos_multiarchive/releases/download/0.2/kos_multiarchive-0.2.zip mirror : http://spacedock.info/mod/433 Source/bugs/code suggestions: https://github.com/hashashin/kos_multiarchive License GPLv3 Salud. Ps: Sorry for my poor english.

In-game kOs script editor (and maybe multi-purpose text editor!) BIG PROJECT CHANGES: This thing now focuses on being not only a text editor (for kOS and wathever you want), but a full emulated computer system which runs on its own bytecode! As of now nothing playable is done, this is, for now, a planning thread! Prototype: (Font is final, syntax and UI are not) Shows how nice the monospace font and a 4bit pallete work together Plans: - Nice editor with international keyboard support - File loader and/or kOS hook (you call edit and the editor pops up) - Syntax highlighting for .ks files - Auto-completion? - Auto-factoring (Placing the { } when you write ifs and stuff)? - ¿¿¿¡¡¡ Stand-alone display for kOS !!!??? { The drawing api seems nice, and allows for individual pixel setting which could allow epic-ui designs (Also, kOS needs some way to handle input) } Priority: - Getting a Unity Window to display a texture (in Window.cs) [0%] - Building a texture out of pixels [100%] - Building a pixel array out of a char array [100%] - Building a char array out of a string and scrolling [0%] Github: https://github.com/tatjam/KosEditor/tree/master/KosEditor Collaboration is welcome!

Hey. i want to make an script in kos that can calculate und flay from any planet to an other planet, like Trigger Transfer Window. i had tried a lot but i have nothing that works in the right way... can someone help me please?