Search the Community

Hello everyone, I just arrived and downloaded KSP1 essentially to use the KOS features. I installed the mod via CKAN (precisely all the files compatible with my version of the game that were offered to me and which started with KOS), however, when I write the program to run in the terminal, the following problem is shown and nothing happens: "The parser used by kos is complaining about a part of the script it can't understand. KOS uses a parser-generator tool known as TinyPG, and the text description you see from this error message comes mostly from TinyPG, not from KOS itself ." The code I'm trying to run is very simple: SET thrott TO 1. LOCK THROTTLE TO thrott. What can I do? Is there any permission I need to enable? Is the mod simply old? Thanks so much for your help and have a good day.

hi obligatory "new here, forgive me if I'm posting in the wrong place" the image in the sidebar here: https://ksp-kos.github.io/KOS/language.html I've just shrunk it down to 128x128 pixels and stretched it a bit after scaling it down. Is it alright if I use it in on my website? Like as an icon/flair users can put on their profile just to show that they use the KerboScript language? thanks!

BakerOperatingSystem 2.2.0 a Kerbal Operating System Raster Prop Monitor GUI script file! Hello fellow Kerbonauts! Baker Operating System is a single script that runs a GUI I have created to run a large collection of KOS scripts. It is a full autopilot GUI written in Kerbalscript to let the user play the game completely from the IVA perspective exclusively. Everything from Launching to orbit, planning a transfer to a target, executing the maneuvers, landing, collecting science, automatic docking in orbit and much more! I'm SelfAwareMatter and I have been playing KSP for 7 years or so and love the game so very much. It has given me a unique perspective on my own place in the universe and greatly enhanced my ability to understand the world around me. Among the things KSP has inspired me to teach myself, programming with KOS is one. I am a Linux user and building simple boot scripts and editing config files was about the extent of my programming knowledge before playing and learning with KOS. Special thanks to Vulcan for his IVA content and for a bit of code he kicked down, CheersKevin on Youtube for getting me started on writing Kerbal-script code, and the devs of KSP, KOS,RPM, and the modding community in general for contributing to such an awesome game and making it so much more! I am humbled to contribute in anyway I can to the community. If even one nerd gets a kick out of using my system I'll be stoked. What an awesome thing KSP and KOS is! MODS that have been incorporated include- Kerbal Operating System obviously Raster Prop Monitor KOS Prop Monitor Atmosphere Autopilot BD Armory RSVP- the rsvp scripts need to be in your script folder for the transfer planner to work. Hullcamvds Trajectories There is a lot in this 13k lines of code. Some of the programs include- Blackjack! My first game! Its buggy and awesome! RSVP transfer GUI - requires RSVP script files in script folder. They may need to be slightly edited. Automatic Launch System Automatic Landing System Automatic Docking - Docking port to be used on ship must be name tagged "fromname" Engine Control Execute Maneuver Node Robotic Servo Controller Ship systems Resource transfer between docked vessels Circularize Orbit Eccentricity at Apoapsis Circularize Orbit Eccentricity at Periapsis Rover Autopilot Target selector Time-warp Controller Maneuver Node editor with current angle to prograde and angle to retrograde display Science Sensor Controller External Camera Controller Atmosphere Autopilot Weapon systems Moon Transfer Planner Planet Transfer Planner VTOL Automatic Hover I hope everybody has fun with this. I intend to make a youtube video about the script soon showcasing some of its features. I would love if somebody wanted to add something awesome to it. I will continue to work on and update this script. Feedback is totally welcome too. Ive tried to make these programs fairly robust and usable in a lot of different environments and situations but I'm sure bugs will arise I have not worked out in situations I have not tested. I'm sure the way I organize some of the code would give a some programmers fever dreams. I tried to make it as organized and commented as possible. Adding new scripts you may want to incorporate is super easy. Just pack the script you want to run in a function with a call to the bakeros function at the end of the script. That will return to menu selection after the script loop has been stopped. Then just drop it in the list of functions in the script file baker.ks and add the function call to the menuanswer section of the bakeros function you will see at the end of the script. Then it should boot just fine from the selection menu. Any questions shoot me a message in the Discord and ill try to respond quickly. Here ya go!!! I am receiving some great advice on the KOS discord about how to clean up my triggers automatically so the system does not slow over time, and some general ways to clean up some of the code that I will be implementing soon. For now every few scripts its a good idea to use ctrl c and reboot the Baker Operating System script file to reset your triggers. ---Version 2.2.0--- License:MIT Spacedock: https://spacedock.info/mod/3052/Baker Operating System v2.1.0 Discord: https://discord.gg/D5PxdeVA Github: https://github.com/SelfAwareMatter/BakerOS Curseforge: https://www.curseforge.com/kerbal/ksp-mods/baker-operating-system-v2-1-0

I know how controversial this subject is, I have read some long threads about it. I think we can have a constructive discussion if we stick to a few principles: 1. Clearly state the specific problem we are trying to solve. 2. Talk about ways (paradigms) to implement the automation solution. I will make a list of identified problems and ways to solve them through automation in this OP. I will centralize ideas (new and existing) and update regularly. I am not concerned about the learning process and how the levels of automation are unlocked according to experience, knowledge and skill levels. This is for the devs to decide. I am more concerned about paradigms to implement automation, using: A. Parts B. Interface tools C. Scripting D. Recording Guiding principles: 1. Do everything manually at least once. 2. If it gets repetitive, automate it. 3. Everything is a part (module) with an associated cost. 4. Centralize command and control. 5. Record only what you can automate. 6. Plan anything you can record. 7. All interfaces have a unified look. My suggestions: I think that every automation process should have a corresponding part that gets added (or upgraded) on the craft, as it's tradition. So A is closely related to B, C and D. This is why I think we should have a integrated system, a central Command & Control Core (CCC) part, where we could add automation modules (as parts). So everything related to automation would become a module (like installing software on a PC). And each module would then have it's GUI representation - up to the devs / modders. - So we know that stock KSP1 already has automation baked in mainly through action groups, SAS, RCS and KAL-1000. I feel like all of these should be modules for the CCC. - Unfortunately one significant thing that's missing is conditional triggers. This is fixed by the SmartParts mod, which I feel should be stock as modules for the CCC. - We should have a telemetry module that centralized all information regarding craft sensors and components state. - We should also have a science module for the CCC, where we can have an overview of all instruments, experiments and sensors. - All MechJeb features related to automation I think should be stock as CCC modules parts in a simplified, easy to use format (like SAS). You decide what to use if you can afford the parts and if you unlocked them. It should be a construction decision, not an interface decision. If you want to be able to hover, add a hover module. If you want to automate ascent / rendezvous / docking / landing / maneuver nodes execution - add the appropriate modules. - KOS should also be a module you could add to the Command & Control Core. It would interact with all other modules and with craft state information. This way we could easily create abstraction layers for scripting (interact with MechJeb, SAS, SmartParts, action groups, telemetry etc). - Journey recorder should be a module and it should only be able to record and re-do flying and rover driving if you have all the other necessary modules on-board (you can't record docking / landing / maneuver execution without MechJeb docking / landing / maneuver automation modules etc.). It should be linked to the journey planner for a clear overview of logistics. - There should also be a colony CCC building and modules for base related automation. - Future mods regarding automation should be integrated as modules for the CCC, not direct game interface add-ons (they would have module GUIs with a unified look). I don't know how it would work exactly, but it would look more streamlined and everything would be managed by the CCC. - Fuel distribution automation for center of mass control. - Thrust / vectoring / RCS control - modules (if engine parts support them). It would allow us to control VTOL and transformer craft. - Aerodynamic surfaces control - centralized as a module. - Have a CCC progression (mechanical -> electric -> electronic -> computer -> machine learning / AI). And then you can also upgrade the CCC hardware for any type of pod/probe and also update the software (with modules). - Initially on primitive craft replace modules like hardware components, but later be able to wirelessly update modules. But CCC hardware upgrades could only be done physically. Other automation ideas: - Manufacturing planner: build N craft of type X, economics overview etc. - Logistics planner: similar to journey planner, related to manufacturing planner. Would manage automated resources transportation routes. - Science planner: automate experiments, have overview of available science parts per craft, check realtime sensors - R&D extension. I will add more ideas...

I just finished the first version of "Kerbal Guidance System", a kOS script capable of launching a rocket to a precise orbit while maximizing payload. The algorithm is based on optimal control theory using a Newton-Raphson algorithm to solve a set of guidance equations and determine the optimal trajectory. I am aware that other scripts exist, including PEGAS from which I gained a lot of inspiration, my original goal was to get a better understanding of the math behind guidance algorithms. I set out to learn more about PEG, but ultimately decided to use a different type algorithm. Both are based on similar fundamentals, but hopefully this adds something new and can maybe help others learn a little bit more as well. This technique is relatively computationally expensive when compared to the slow processor speeds of kOS. In the future I may translate the code to python to use with krpc. KGS can launch a rocket to a specified orbit while minimizing fuel consumption. KGS offers the specification of three types of orbits: Unconstrainted orbital plane Constrained inclination Constrained inclination and longitude of the ascending node Some of the capabilities of KGS include: calculation of launch time calculate of launch azimuth predefined atmospheric ascent phase coast phases precise orbit targeting I put together a few examples, two for the stock KSP system and one for RSS. The scripts, a guide, and theoretical background documents can all be found on my GitHub page https://github.com/TomTheLion/Kerbal-Guidance-System. It can be somewhat challenging to set up and successfully fly a rocket using this script, but hopefully the guide provides enough detail. I would be more than happy to offer help or clarify anything if anyone decides to try this script. For the stock rockets the only required mod is kOS, for the RSS rocket I used a custom module manager patch to rebalance the engines for a larger solar system (included on my Github page) and the following mods installed from CKAN: Real Solar System Kerbal Joint Reinforcement Continued Restock Restock+ Waterfall Core Simple Adjustable Fairings - KW Rocketry Pack Simple Adjustable Fairings - Plugin

BakerOperatingSystem a KOS RPM IVA GUI! lol Hello fellow Kerbalnauts! Im SelfAwareMatter and I have been playing KSP for 7 years or so and love the game so very much. It has given me a unique perspective on my own place in the universe and greatly enhanced my ability to understand the world around me. Among the things KSP has inspired me to teach myself, programming with KOS is one. I am a Linux user and building simple boot scripts and editing config files is about the extent of my programming knowledge before playing with KOS. BakerOperatingSystem is an operating system I wrote for KOS to be used with RasterPropMonitor. Its a collection of scripts that can be accessed though a GUI. Special thanks to Vulcan for his IVA content and for a bit of code he kicked down, CheersKevin for getting me started, and the devs of KOS and KSP for making such an awesome game. What an awesome thing KSP and KOS is! MODS that have been incorporated include- Kerbal Operating System obviously Raster Prop Monitor Atmosphere Autopilot BD Armory RSVP- the rsvp scripts need to be in your script folder for the transfer planner to work. Hullcamvds There is a lot in this 13k lines of code. Some of the programs include- Blackjack! My first game. RSVP transfer GUI Automatic Launch Automatic Landing Automatic Docking Engine Control Execute Maneuver Node Servo control Ship systems Resource transfer Circularize Orbit Eccentricity at Apoapsis Circularize Orbit at Eccentricity Periapsis Rover Autopilot Target selector Time-warp Controller Maneuver Node editor Science Sensor Controller Camera Control Atmosphere Autopilot Weapon systems VTOL Automatic Hover I hope somebody has fun with this. I would love if somebody wanted to add something awesome to it. If I make significant updates I will keep this post updated. Feedback is totally welcome too. Like I said earlier I really don't know much about programming and I'm sure the way I organize some of the code would give a real programmer fever dreams. I tried to make it as organized as possible. Here ya go! License:MIT https://drive.google.com/file/d/1FJ2dhi_hU1GXt_FH2O68zG1fjH2Sf1nk/view?usp=sharing [download link removed by moderator, pending resolution of licensing issue]

Hey all, I've written a Module Manager patch that adds ModuleScienceContainer (i.e the Science Box) to KOS Processor parts. @PART[*]:HAS[@MODULE[kOSProcessor],!MODULE[KerbalEVA]]:final { %MODULE[ModuleScienceContainer] { //name = ModuleScienceContainer reviewActionName = #autoLOC_502201 //#autoLOC_502201 = Review Stored Data storeActionName = #autoLOC_502202 //#autoLOC_502202 = Store Experiments evaOnlyStorage = False // i.e. can nearby regular vessels also do this, or EVA only capacity = 500 storageRange = 1.3 canBeTransferredToInVessel = True canTransferInVessel = True showStatus = True +description ^= :^.*$: Adds a Science Container. } } however the line capacity = 500 means that it can hold 500 experiment results. i would like it to hold a percentage of the KOS diskspace (eg. if the KOS diskspace is 5000, the experiment space is 500Mits) also how can i make it so this information shows up in the VAB/SPH right click part info panel

I am sure many people have tried to use kOS instead of mechjeb, but couldn't understand it due to its complexity. Is it possible to make a mod which can act as a cheat sheet by providing all the major commands required for basic operations, or giving an in-game tutorial on how to do your first launch, orbit, docking, etc.. This way, even people with no programming knowledge will start using kOS and learn some programming.

Hi, Marcus house had made a kos code for falcon heavy which only works with ksp 1.3 and lower. So i have modified his script and made it compatible with Ksp 1.8.1 and higher . So i will now continue to to update his script . Script is finally complete ,here it is : https://github.com/daiwik-ksp/Falcon-Heavy-Dual-booster-landing- More pic on : https://imgur.com/a/0vaAUyH

Hi ! I'm starting to build complete IVA ! with updated MFDs and especially an integration of KOS in the cockpit thanks to KPM, I start from the principle of a cockpit Dark and cold not texture type internal with emissive, only the spots will bring cockpit lighting. ---- Thanks to ---- * Alexustas For these beautiful PROPS packs (ASET). And its Pods that are beautiful and very technical (That's my reference) * Mihara for its original RasterPropMonitor mod, and thank MOARdV & JonnyOThan For its maintenance. RasterPropMonitor (adopted) by JonnyOThan. * dsonbill for its very practical kOS<-->RPM interface for Kerbal Space Program. * KOS originally created by Nivekk Thanks to all the contributors to this mod. * Nertea for are pack Near Future Props v0.6.4. * Completely inspired by DE_IVAExtension created by DemonEin and IVA_ASET_MAKING_HISTORY I would be nothing without this forum and the contribution of all these fantastic people who makes incredible Mods. MK1-3 POD MOD (Cockpit - IVA finished.) PodCam & Light ok (exterior) : Squad Pod by default, setup 1, compatible with Restock setup 2. (MM patch tested ok) MFDKOS added if KOS+KPM present (Replaces one of the RasterProp MFD) (MM patch tested ok) Big picture ______________________________________________________ mk1Cockpit_MOD (wip)

Modlist Taking flight In the years prior to this moment, whereby a private entity attempted the launch of a liquid fueled rocket into orbit around Kerbin. Space had always been the dream of the masses, yet the playground of the very few governments who had the resources to haul massive chunks of cylindrical metal filled with explosives into space. The tempo of the space development dance had reversed. From sending Kerbals to the Mun, governments of Kerbin had went back to sending Kerbals into Low Kerbin Orbit. The plans to go onto Duna had stalled to a halt. Jebediah Kerman, a retired astronaut who had walked on the surface of the Mun, always dreaming of the day tourists and private citizens of Kerbin could walk the stars. Decided to take things into his own hands, initially he wished to purchase retired assets from the Viscian Military, these were too expensive however. He decided to build his own rockets. It had only been a matter of months since the first Chorus 1A Liquid Fuel Rocket Engine had rung out its first harmony. Now stood on the test stand, a fully fueled rocket, standing by for the launch timer to hit 0. It had been a long journey up to this point. Many minutes of testing and guidance simulations had been performed to check to the best of a Kerbal’s abilities that this would be a success. The Tempo of the Space Flight Technological Development Melody was about to get faster. After the first successful test ignition of the engine. The Chorus 1A Engine used a pintle style injection, similar to the Munar Landers of the Kerbin 5 era. The turbopump of the engine was used to allow for 3 axis control of the vehicle. The Engine recorded a peak thrust output of 170,600 Newtons at T+1 minute into the test the Chorus 1A Engine started testing a gimbal profile, the systems gimballed to 2 degrees, the turbopump exhaust A little while after the successful test ignition of the Chorus 1A (C1A), the engine was taken down and refurbished to be put upon the first launch attempt. Meanwhile the initial test of the Chorus 1A Vacuum engine (C1AV) was attached to the test stand, preparing for its first ignition. The engine ignited without a hitch, however in actual flight the C1AV would be pressure fed. The test recorded a thrust of 7,000 Newtons under 1 atmospheres of pressure. When the success of the engine testing regime had been verified and looked over, the tests moved onto qualifying the flight hardware the first and second stages flew through their qualification tests. But now it was time to see if the Melodia 1 Rocket would fly itself. The guidance algorithm had been programmed to follow a turn based upon the apoapsis of the rocket, pitching it over to a pre-designated minimum pitch angle as the rocket reached a predetermined apoapsis during the ascent. Upon the detection of flameout by the Chorus 1A Engine on the First Stage, then would command separation from it. Revealing the second stage’s Chorus 1AV Engine to the vacuum of space, or the upper atmosphere. At around 64,000 meters above sea level the fairing will deploy, revealing nothing to the vacuum of space as this is a test flight. Upon reaching a targeted altitude the second stage engine will shut down, and coast until reaching the apopapsis, relighting to perform an orbital insertion. At 5:28 Kerbal Time, the Melodia 1 Rocket took flight after a countdown which had began at 4:48. Throughout the flight the data coming from the vehicle looked nominal. As the vehicle began to pitch over the mission control center, composed of 8 Kerbals erupted into a multitude of high fives and cheering. Yet they knew they wouldn’t know if Melodia 1 had reached orbit for another 20 minutes. As the vehicle headed outside of the range of mission control silence echoed through the room, they knew the ringing of a telephone would inform them of a success or a failure, just they didn’t know what. It was 10 minutes into the flight, the vehicle should still be coasting towards a short insertion burn, little over 54 meters per second. The phone rang in the room, carefully Jebediah picked it up. He jumped with joy as the communications downlink center confirmed the Melodia 1 had reached Kerbin orbit. Yet however they were lucky, the fuel tanks had been run dry. This indicated that the maneuver for orbital insertion failed in some way. Additional guidance checks would need to be added in the next flight. But yet orbit had been achieved on the first attempt, the team celebrated through the day and night of the achievement of “getting half way to anywhere” Yet Jebediah knew he had to create an even bigger rocket to succeed in his goal of making space interesting again, he needed to inspire the world in an effective way to further his goal. Authors notes:

Common Launch Script (CLS) What is it? CLS is an auto-launch script that will put most rockets into a circular orbit of any desired apoapsis and inclination. It attempts to be a 'one-size-fits-all' script. If it takes off vertically and has more than one stage, this script can launch it (hopefully). I finally feel its in a state that I am confident sharing with the KSP community so that it can be enjoyed / modified / improved by the rest of this amazing community. Download Link: Github Changelog Dependencies: kOS What can it do? Below is a list of it's main features: General Launches any 2+ stage rocket into any circular orbit within Kerin SOI (apoapsis & inclination can be configured). Allows a specific launch time (to the second) to be set either by inputting "hh:mm:ss" or number of seconds until launch. Can be set to achieve the highest possible circular orbit for the vehicle's dV and CLS's ascent trajectory. Restricts time warp for code stability based on ascent phase. Staging Detailed staging logic that handles automatic staging, including those that use ullage separation. Detects impending staging and steers towards prograde for those Korolev style separations we all love. Auto jettisons LES or fairings on ascent based on atmospheric pressure, but not during staging. Display Provides incremental readouts of vehicle altitude and speed. Continuous display for a range of data. Uses scrolling print for rolling text display. 'Immersive' readouts during countdown, ascent and circularisation. Engines Throttles down main engines on ascent to limit twr (configurable). Throttles down central booster in 3 booster lifters such as Delta Heavy. Throttles them back up on side booster separation. Throttles down upper stage engines to limit twr (configurable). Throttles to achieve a specific twr at liftoff (configurable). Throttling during ascent is gradual. Accounts for SRBs with thrust curves. Throttles up main engines to account for reducing SRB thrust and jettisons SRBs once thrust < 20%. Abort / Countdown Holding Continuously checks abort conditions (RUDs, loss of steering control, insufficient thrust, loss of electrical charge) and activates abort action group if a condition is met. Holds launch if electric charge is low, staging is incorrect, liftoff TWR is too low, action groups are incorrect or any background script initialization is not nominal (to avoid mid-ascent errors as much as possible). Holds launch if user input is incorrect (eg target apoapsis within the atmosphere). Launch holds give the user the option to continue the launch, scrub the launch or recycle the countdown depending on the severity of the issue. This uses pilot input (A and N) keys to determine your response. You will need to click off of the kOS terminal for this to work. Circularisation Continuously monitors data to calculate the best method to achieve orbit and will switch automatically to the most efficient method. Automatically creates, performs and removes maneuver nodes for circularisation with a high degree of accuracy. Ascent Profile / Steering Locks orientation of vehicle during ascent (aka the orientation the rocket leaves the VAB in is how it will remain the entire way to space). Uses a standard ascent profile for consistency. Launch profile is only adjusted (automatically) for low TWR vehicles. Continuously monitors the vehicle's time to apoapsis and controls throttle and pitch accordingly. What can't it do? This script was always written for my own personal use - I have adapted it for a public release. Therefore it has not received testing using any variety of mods or vehicle designs other than my own. As people use this with weird and wonderful designs or different assortments of mods, I'm sure bugs will emerge. Please refer to the bug reporting section below for what to do in this situation to help development. I also want to say that my kOS writing skills are self-taught and I have no background in doing anything like this. There are probably better ways to write this script, and there are absolutely better kOS writers than me. If you do have any suggestions of how to change the script, please feel free to comment on this post or open an issue on github. Installation Instructions Copy everything from the zip into your main Kerbal Space Program folder. Future Development I use the issue tracker on Github to document any features to be added, bugs to be fixed or other general changes to make. You can refer to it here. Usage Instructions CLS can be run from the archive. If you dont have the 'start on the archive' setting enabled, switch to the archive with the kOS command 'switch to 0.' and then you will be able to run CLS. More specific instructions for running CLS can be found at the top of CLS.ks. Many aspects of the script are configurable. Those that are can be found at the top of CLS.ks in the USER CONFIGURATION section. Bug Reporting If this script fails for you, please either comment on this post or open an issue on github in the issue tracker. In both cases I will need to see a picture of the kOS terminal, the launch parameters inputted and when during ascent it failed. In some cases I may also need a modlist or craft file for further testing. Licensing This script is distributed under the CC-BY-SA-4.0 license, except where noted below, where those elements are distributed under their own license. License text can be found here. Licensing Exceptions lib_navball.ks | lib_lazcalc.ks | lib_num_to_formatted_str.ks - KSLib - MIT. See license_exceptions for more information. Special Thanks A huge thank you to /u/only_to_downvote / mileshatem for writing and sharing his amazing launchtoCirc script. CLS is based on his work. I taught myself kOS by deconstructing launchtoCirc bit by bit to understand it and how it works. Then I set about creating my own, but some of mileshatem's original code is in CLS. When i hit a roadblock with ascent profiles, I messaged him on reddit and received some fantastic help. The kOS dev team for writing their fantastic tutorials and documentation for kOS. Incredibly useful for a new kOS user and taught me a lot. The kOS dev team (again) for their amazing KSlib libraries. CLS uses them, and seeing how their libraries work taught me a lot. The fantastic kOS subreddit/community. I hit many roadblocks writing this script and I always found help there. Whether it was reading responses to other's troubles or posting myself, I always found someone with a suggestion. /u/Dunbaratu provided the compass_for_vect function.

The overall aim is to code a rocket to send 4 satellites into a geostationary orbit. I have all the code set just stuck on the last bit. Until the 'Sats" leave the main vessel they are apart of that vessel so the only way I believe would work is to start each Sat running it's own script as soon as it decouples by sending a 'runpath' Command to run a path from 0:/ . Can anyone help with this code ??? I can connect to Sat 1 and send it a message but can not send a run path command to save my life. Any help would be greatly appreciated. Thank you.

Hey Guys, So, my kind of favourite Orbiter right now is the space shuttle. After I found some good ones in the internet that fly reasonably well to orbit, I have problems reentering Kerbin. So I have a few questions. I'm reentering Kerbin at about 2500-3000 Km/h. Where should I do a manuever node to safely land at the "Main Base", you know, the rollway. I'm always missing the rollway for about a few hundred kilometers every time (or I crash). Is there a kOs Script you guys have that'll do something like that? Because I believe the whole landing thing is complicated.

Every time I try to add a parachute to a spacecraft I have no option to deploy it or set altitude parameters, I only have the ability to change the name tag . The deploy and altitude parameter functions have always worked in the past but suddenly this seems to happen. In the recent time I have installed a few mods such as kOS, Procedural Parts and Module Manager, but because of this error I am now forced to do propulsive landings. I just wanted to know if anyone else has/had this problem or if I'm doing something wrong. Thanks!

I found a potential bug in kOS, where I try to create a maneuver node from a list of four values, and it returns the error "Cannot iterate on an object of type kOS.Safe.Encapsulation.ScalarIntValue. What's going on?

I have been trying to figure out the exact landing burn altitude for my hoverslam script and I can't work it out accurately. I've looked at others' script but does not seem to work well with my script. lock burnAlt to (ship:velocity:surface:mag^2)/(2*(ship:sensors:acc:mag)). This is what I use to determine the landing burn altitude. And my condition is: if trueRader <= burnAlt { set autoThrottle to hoverslam. } else { set autoThrottle to 0. } From what i understand from this condition, the throttle should be never 0 whenever it is below and equal to burnAlt unless otherwise. But that's the problem, the burnAlt decreases as the rocket throttling up. Do I need to use constant to find my landing burn altitude or something else that is more efficient? P.S: This does not account for aerodynamic drag nor that it need to be accounted for as I'm playing stock and not RSS/FAR.

I'm trying to revive someone else's kOS code for rover pathfinding using A*, but their code is so messy I can't make heads or tails of it. Can someone help me? The Reddit post featuring the code is here:

The title kind of explains itself. I was trying to figure out if my ship had a radiator, but apparently SHIP isn't a variable, despite it saying so in the documentation. Does anyone know what's going on? Here's the image (I don't know how to link it to a URL): https://drive.google.com/file/d/1j0zn45sKTBKlfb_TsP8iaCcM9eYLj_g-/view?usp=sharing Thanks!

Backstory I started a mission report a few months back. I liked sharing my missions and people liked reading them. But then my computer died and for a while I couldn't recover the data. And during that period of time, I started playing @Galileo's Planet Pack. And I love it. So I've discontinued my initial save, even if I may recover the data someday (TM), and started another save. Boring! Do you have anything else to say? I am playing on Moderate mode, but I have increased the science! returns so that I can do whatever I want as soon as I want. Moderate mode means that I have to pay to unlock new parts. Still boring! How about a modlist? I have: This continues to be boring! A chapter list? I only have 1 chapter at the moment, but... Chapter 1 started with this post. Still quite boring! Some launch scripts? Here's my Google Drive. But there are no ships to launch them with! Fine! Here are the first pages of Starwind (in GPP): The Ceti Campaign Oh yes, I kept the Original Four Gaelans and added the Original Four Kermen. So I have Eight. Tune in next time for Val making orbit, and an Iota flyby!

Hi all, I'm searching for a while how to calculate the duration of a burn required to change orbit both for the Hohmann transfer maneuver and for circularization maneuver. I'm using KOS in KSP and after launch I have periapsis at about 85km and apoapsis at around -200km. At this point I want to write code for orbit circularization. So from my understanding I should burn until my speed at perigee will be equal to the speed at apogee and this will mean that I have close to 0 eccentricity. I wasn't able to find the calculations needed to get the deltaV needed and the burn time. Can anyone help please? Thanks

On-Board Cam: Ground Tracking Cam:

Designed a new Launch vehicle in KSP using KOS. This is the testing of the Launch Escape System.

Got a problem with flacon heavy script, its saying "Cannot find sensor for ACC", and sending to this lines of script: SET vertAcc TO sProj(SHIP:SENSORS:ACC, UP:VECTOR). SET dragAcc TO g + vertAcc. //vertical acceleration due to drag. Same as g at terminal velocity What is ACC, and how to fix this error ? KSP version 1.5.1 (macOS), and latest kos. P. S. Its not my script I just download it so don't be very mad for my stupidness.