Search the Community

Showing results for tags 'kos'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements
    • The Daily Kerbal
  • General KSP
    • KSP Discussion
    • Suggestions & Development Discussion
    • Challenges & Mission ideas
    • The Spacecraft Exchange
    • KSP Fan Works
  • Gameplay and Technical Support
    • Gameplay Questions and Tutorials
    • Technical Support (PC, unmodded installs)
    • Technical Support (PC, modded installs)
    • Technical Support (PlayStation 4, XBox One)
  • Add-ons
    • Add-on Discussions
    • Add-on Releases
    • Add-on Development
  • Community
    • Welcome Aboard
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website


  • Developer Articles

Found 36 results

  1. Hello! TLDR: This is a development log for an autopilot I'm developing for RSS KSP using real-world rocket guidance algorithms. Over a year ago I've shown a script for kOS that was capable of autonomously flying rockets in RSS-RO modified game (you can find the code on my github and watch a video where I tried to explain what is it and why would anyone need it). In short, it's a kOS script handling the staging sequence and guidance throughout the whole ascent of a launch vehicle, from a "go" mark to parking orbit insertion. Now I'm taking the thing to a new level by implementing the Powered Explicit Guidance algorithm - a real world guidance scheme taken straight from the Space Shuttle documentation (in the document it's referred to as UPFG). My github project consists of two components: a kOS code section and a separate MATLAB folder. The first part - currently a work-in-progress - contains all code needed to run the script in an in-game kOS terminal. The MATLAB section contains a development version (prototype) of the algorithm, along with all the simulation code (all the work KSP does for us normally), and it's the place to look at if you're interested in technical details and newest developments. Note: the two components are not dependent! You do not need one to use another. The old script contained many useful features (vehicle-specific boot files, timed staging events) but also many limitations: only constant azimuth (so not even inclination control), complex first stage guidance (you basically need to design a pitch program for your rocket), very basic PEG implementation (only pitch control, only single stage vehicles). However, the project has seen a major progress since then: Implemented the Unified Powered Flight Guidance taken right from the Space Shuttle GN&C documentation - its Ascent Mode allows targeting orbits in a given orbital plane. Properly implemented the UPFG for multiple stages. Launch window estimation - calculates when the target orbit will pass above the launch site, allowing to launch a bit before that. One of the posts demonstrates PEGAS capabilities with several launch vehicles, sites, and targets, proving its great accuracy (plane error below one hundredth of a degree means correction maneuver of about 1m/s). Since the following post, the MATLAB part of PEGAS is complete and I am actively working on a kOS port of the algorithm and its surroundings. So far I managed to: translate the key UPFG algorithm to kerboscript and verify it works just the same as the MATLAB prototype. Rough list of TODOs from this point involves: testing and adjusting the algorithm for use with the left-handed coordinate system of KSP, constructing a simple, independent atmospheric guidance system (UPFG makes an assumption that there is no atmosphere present, therefore it would provide wrong results if used in early ascent - hence a separate program must control this portion of a flight), launch window estimation: PEGAS can now handle wider launch windows easily, there is no need to calculate the time of lift-off with great precision (which is generally very difficult) - simply launching a while before orbit passes over your head will be enough; calculation of this moment (knowing current time, coordinates of the launch site and target orbit) is necessary, designing a general autopilot framework: integrating the whole mission procedure, from selecting a target orbit, through launch window estimation, launch, staging, orbit insertion enabling use of bootfiles for providing information about the vehicle (UPFG needs to know several parameters of each stage it is to guide, therefore a way of obtaining and storing it must be created; there are no plans to do this automatically, since scanning the vehicle part tree would be too complex, so the user will have to take some measurements of their vehicle as input for UPFG - the most user-friendly way to do that seems to be via bootfiles permanently attached to each launch vehicle). I will be updating this post along with the new developments. Thanks
  2. I'm making a landing script on kOS, but now I had to kill the horizontal velocity of the ship. But for this I had to have the heading retrograde. In other words, lock orientation on retrograde but inclined to horizon to just kill the horizontal velocity. Have you some ideas to get this orientation on kOS ? (I'm not english, sorry for my potentially horrible syntax.) Thanks
  3. Since this challenge seems to be dead, I decided to post a new kOS challenge thread here. The challenges are aimed to reproduce the achievements of real-life space programs. Rules: Launch an automated mission controlled by kOS. Manual control is allowed on uncrewed missions in the form of typing commands into kOS console. On crewed missions, manual RCS controls and action group triggers are also allowed. All spacecraft must have an antenna on board which is capable of reaching Mission Control (if it is in sight) or relay network. Required mods: kOS RemoteTech Recommended mods: Community Tech Tree SETI-UbM or other probe-first tech trees Kerbal Engineer Redux RealChute FAR Some kind of life support Other noteworthy mods: KSC Switcher to launch from non-equatorial sites for extra bonuses Since the challenge lies mostly in programming and mission planning, part mods are allowed. Mods that do piloting other than kOS are disallowed. You can still use MechJeb info panels if you need. Notes on RemoteTech usage. Signal delay must be on. Antenna ranges must be in either in Root mode with RangeMultiplier = 0.5 or in Standard mode with RangeMultiplier = 1. Extra ground stations are allowed and their range may be increased to cover the whole Kerbol system. Number of ground stations is limited to 10. One set of extra stations can be found in the SETI pack. Missions beyond Kerbin SOI assume the existence of a relay network in Kerbin orbit. Otherwise, the launch of relay network must also be demonstrated if the mission relies on it. Scoring: Base score for each challenge is 100 points. Bonuses and penalties are applied in the form of score multipliers. Manual command penalty for all challenges: score x0.9 for every command entered in terminal after liftoff (command is a sentence ended with a period) Challenge list (The ones that have the description marked bold) V-2 Sputnik Corona Vostok Luna Syncom Molniya Gemini Surveyor Venera Mariner Apollo Viking Kerbal Positioning System Vega Cassini Falcon Mission descriptions: Mission badges Sputnik Vostok Luna
  4. Ad Inexplorata

    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!
  5. Hello everyone! I want to share with you my project called 'New Kepard'. It was inspired by New Shepard rocket landing: My goal was to recreate it in KSP using the kRPC mod which allows you to write your own scripts to control the vessel. The developement of the project took me much longer than I had originally thought (more than 100 hours). Writing the program which controls the rocket was not the hardest thing. Bugfixing, tweaking, testing and ensuring that the code is prepared for every possible flight scenario was what I spent the most of the time (~75%) on. I am now very happy that I made it to the end and didn't give up. I created two films about my project: The first one was edited to be similar to the original Blue Origin's video The goal of the second film is to show what my project is and how to use it Code and the craft are avaliebe to download on GitHub. I hope you like what I've done
  6. 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.
  7. The goal of this series/project is to develop a KOS script that can fly a falcon heavy like rocket or a single booster rocket and return all boosters and the first stage to the KSC autonomously. Progress will be posted over time. I will post single 'flights' on YouTube and in responses to this post. Each 'flight' will include an iteration on the source code adding or improving a single feature. The source code is available on Github. There now is a followup project: Questions/comments/improvements are greatly appreciated. Mission Log: Flight #1 - Simple Hop Flight #2 - Liftingbody flight path adjustment Flight #3 - High altitude path reversal boostback Flight #4 - Heavy demonstrator with boosters Launch #1 - Foo-Sat to LKO - A COMPLETE MISSION!!! Github source code Kamik423
  8. LaserDist LaserDist v1.0.1 for KSP 1.3.0 Why does this Mod exist? The intended purpose of this part is to be used in conjunction with scripted autopilots like [kOS](, to provide a way to for you to write scripted pilot software that can see the distance to the ground (or anything else like a ship) along the laser line. See the image in the picture album to see what its meant by this.The reason this can be useful is so you can detect things like terrain slope and mountains in the way. The default radar altimiter in KSP only shows you the distance directly under the craft. The V1.0.0 update: I believe I have finally fixed the phantom hit problems (I found that Squad changed a few of the layer numbers in 1.2.2. My raytracing calls were giving phantom hits to the UI elements and the map view's planets because the layermask that worked fine in 1.1 wasn't right for 1.2.2.) Since the phantom hits problem was the main thing making me consider the mod "not ready", and tha'ts been fixed - I now am moving it to version 1.0. (1.0 also includes a few minor tweaks to the laser visual animation you should barely notice.) Releases, from major download sites: ZIP Download (See release page above): Source Code Hosting site: * License: * GPL v3 Copyright (C) 2014,2015,2016 Steven Mading (aka Dunbaratu on Github) 100x model This is a very small plugin. It makes a KSP Part that measures straight line distances by laser. The "Beamer 100x Disto-o-meter" Part aims a laser in a lin and then measures the distance in meters to the first object the laser hits. The result is displayed in the right-click menu for the part and can be read by kOS (and other?) script mods. 200x model The "Beamer 200x Bendable Disto-o-meter" Part is the same as the 100x part described above, but it lets you choose a deflection angle with the "Bend X" widget on the slider, (or by using SETFIELD in kOS on it), and the laser can dynamically change it's aim along this one axis. 500x model The "Beamer 500x Aimable Disto-o-meter" Part is the same as the 200x part described above, but it lets you bend the laser in two different axes, to aim it whereever you like within a zone, using both "Bend X" and "Bend Y" settings. All models: The laser can work over long distances - here it's measuring the distance from a Kerbin orbit vessel to the Mun: The direction of the laser is whichever way the laser gun is pointed when you mounted it on the craft. ### Information about the data fields the part displays: ![LaserDist Rightclick panel 1](rightpanel.png) KSPField: 'Distance' is a float - the number of meters being shown in the display. It's -1 if there is currently no hit. KSPField: 'Hit' is a string - the name of the object being hit. KSPField: 'Enabled' is a bool - true if the measuring device is on. KSPField: 'Visible' is a bool - true if the laser should be drawn when it's activated or false if it should be (realistically) invisible because, hey, it's coherent light and it's not supposed to be seen from the side. KSPField: 'CPUGreedyPercent' is a float (called "CPU hog" in the GUI) ranging from 0.0 to 20.0. It's how much of a single physics tick of time this mod will allow itself to consume during a single Update. If it hasn't gotten a good enough answer within that much time, it will wait until the next update to continue the calculation. KSPField: 'UpdateAge' is an integer - It's how many Unity Updates (animation frames, basically) it's been since the value you are seeing was calculated. Because of the logic of CPUGreedyPercent (see above) sometimes the value being displayed is stale by a few update ticks and shouldn't be trusted until the next time that UpdateAge becomes zero again. If you're in a situation where this mod needs to spend more than 1 update of time to get to a good answer for the distance, you'll see this value spinning a bit, quickly going 0,1,2,3,0,1,2,3,0,1,2,3...etc. When you see that, only when it hit the zeros was the distance value perfectly correct at THAT moment. KSPField: 'Bend X' is a float - the number of degrees the laser is deflected in its relative Yaw direction, if it's the type of laser that can be deflected. KSPField: 'Bend Y' is a float - the number of degrees the laser is deflected in its relative Pitch direction, if it's the type of laser that can be deflected. KSPField: 'Max Bend X' is a float - the range of bending the laser can do in its relative Yaw direction. If this is zero, then the laser cannot bend that way. The range is always centered at zero, plus or minus this number. KSPField: 'Max Bend Y' is a float - the range of bending the laser can do in its relative Pitch direction. If this is zero, then the laser cannot bend that way. The range is always centered at zero, plus or minus this number. Note: The higher that CPUGreedyPercent ("CPU hog") is, the less likely it is that UpdateAge will ever be nonzero, but the bigger hit your framerate might take. ### How to Mount it. ![icon of Electronics node]( The Beamer 100x Dist-o-Meter is located in the "Electronics" tech node of the career tech tree. It's a 300-point node on the tree so you might not have it yet in a new fresh career game. It appears in the science tab of the parts bin. The Laser can be mounted anywhere as a surface-mount item. Take care to note the orientation of the laser emiiter. (KSP lets you fine-tune the rotation of a part by using the SHIFT key while you hit the WASDQE keys.) The Laser will bounce back and give you a distance measurement when it encounters *ANY* object, including parts of your own craft. So take care to mount it somewhere where the laser beam will have a clear line of sight without obstruction. To ensure a good mounting point, you can use "tweakables" to enable the laser and make it show up in the VAB to look and see if you have it aimed well. ### Lightspeed Note that if you use it to measure the distance to a far away body (i.e. like aiming it at Duna from Kerbin), the mod does take into account lightspeed. You have to hold the laser on an object steady and unchange for the entire duration of time it takes for lightspeed delay to bounce the signal back or you won't get a measurement, so using it at that great distance will be very hard. ### How do I use it from my script then? Quick synopsis: Getting a handle on the laser, then turning on the laser using that module: SET laser_module TO SHIP:MODULESNAMED("LaserDistModule")[0]. IF not laser_module:GETFIELD("Enabled") { laser_module:SETFIELD("Enabled",true). } Getting a reading from the laser: SET laser_module TO SHIP:MODULESNAMED("LaserDistModule")[0]. PRINT "Laser distance is measuring " + laser_module:GETFIELD("Distance") + " meters." PRINT "Laser is hitting: " + laser_module:GETFIELD("Hit"). Transforming the laser reading into a 3-D co-ordinate: The part model is designed such that emitter of the laser line is located exactly at the part's local transform origin position, aimed along the part's ``facing:vector`` unit vector, allowing you to get its 3D vector position from a script like so, *Provided you haven't bent the laser with the ``"Bend X"`` or ``"Bend Y"`` settings. If you have bent the laser, then you need to apply these offset angles yourself with an ANGLEAXIS rotation in kOS*: SET laser_module TO SHIP:MODULESNAMED("LaserDistModule")[0]. set dist to laser_module:GETFIELD("Distance"). set emitter_position to laser_module:part:position. set emitter_unit_vec to laser_module:part:facing:vector. set laser_hit_position to emitter_position + (dist * emitter_unit_vec). Laser_hit_position is now a 3D vector position of where the laser hit something To do the same general thing but when the ``Bend X`` and ``Bend Y`` fields are nonzero, rotate the vector around the part's facing unit vectors: SET laser_module TO SHIP:MODULESNAMED("LaserDistModule")[0]. set dist to laser_module:GETFIELD("Distance"). set emitter_position to laser_module:part:position. set emitter_center_vec to laser_module:part:facing:vector. set x_bend to laser_module:GETFIELD("Bend X"). set y_bend to laser_module:GETFIELD("Bend Y"). set bending_rotation to angleaxis(x_bend, laser_module:part:facing:topvector) * angleaxis(y_bend, laser_module:part:facing:starvector). set emitter_unit_vec to bending_rotation * emitter_center_vec. set laser_hit_position to emitter_position + (dist * emitter_unit_vec). . ### Part modeling help? I am aware that the artwork on the model isn't pretty. I'm a programmer, not a graphic artist, and I don't have experience with things like Maya and Blender. In fact I just made the model by slapping together some stretched Cube and Cylnder objects in Unity itself, without the aid of a modeling program. The model is good enough to work with, but I'd be happy to have someone better at art redesign the model. I included the model in the github directory if you want to have a look.
  9. 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!
  10. 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.
  11. 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?
  12. KOS Scripting

    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.
  13. KOS basic scripts + crafts

    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.
  14. 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 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.
  15. 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?
  16. 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. 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. 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.
  17. I tried my best with this video hope you liked it guys! Thanks
  18. kOS help

    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.
  19. 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: 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: 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.
  20. 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.
  21. [1.2] kOS Addon: kOS-SCANsat

    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.2 kOS 1.0.2 pre-Release SCANsat 16.9 Full Documentation: Documentation of the API Downloads: Get the latest release here Source code is here
  22. 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.).
  23. 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.
  24. 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: What it does: Countdown Can detect when asparagus staging stage needs to be staged Gravity Turn Circularization (100 x 100 km) ABORBIT: 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: 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: 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...
  25. 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?