Qwarkk

I have managed to recreate your issue and found an interesting problem with CLS. Basically the script wasn't detecting anything in the Abort Action Group, but there are parts there. The problem is that the parts in the abort action group also appear in other action groups. As soon as I removed them from the other action groups, the script works perfectly. Kos has some strange logic here. It only recognises the part as belonging to the action group it was added to first. So in your case, the abort parts were probably in one of the other AGs first and then added to Abort afterwards, causing kos not to recognise them as belonging to the abort action group.

This shouldnt be too hard for me to implement - I have a few other things planned for CLS but i'll definitely look into this too.

Apologies its taken so long to get back to you, I've had an extended break from KSP and the forums. At T-6 seconds the script checks the abort procedure is suitable. Basically, it checks if there is crew on board, and if there is, it checks if you have parts in your abort action group. I can see from your craft file that you have parts in the abort action group so clearly something isn't working as intended. I will take a look and see what I can find. Thank you for the info! I've been away from KSP and the forum for a while but i'm so happy to hear someone getting some good use out of it! I have seen your tweaks, how are you finding the script handles 4x warp? The reason it was limited to 2x was that an early version of the script would struggle to execute time-critical commands if in 4x warp. Also are there any features missing from the script you'd like to see added? Q

'Under the hood' update for CLS (v1.3.0) is now available to download from Github! This update changes a lot of things behind the scenes for CLS. It's two major goals were to tidy the code up in order to make it run smoother and to ensure CLS was as compatible as possible with as many mods so that it performs as expected for everyone who tries it. In terms of new features, this update really offers very little. Changelog Compatibility CLS can now automatically determine the fuel type and mass, even for non-stock resources. This allows CLS to work (theoretically) with any resource pack such as realFuels. Ensured CLS is compatible with all rescale mods and planet packs by altering how it handles atmospheric calculations, gelocation and time variables Ensured any calls for the vessel's geolocation will be accurate across rescale mods and planet packs. Reworked part module searches to maximise compatibility with mods that replace stock modules. This was done specifically with realFuels' moduleEnginesRF in mind. Tidy Up Widespread tidy and reformat of a lot of code. Things look tidier, are easier to understand and will hopefully run smoother. Increased the use of local variables to reduce long, single line equations / calculations. Finally learned how to use BIDMAS to get rid of unnecessary brackets in the formulas. Rewrite of the scrollprint function to make it concise & run a smoother. Removed ‘steerto’ and ‘throt’ variables for steering and throttle control (this was originally done in response to a bug in early kOS versions). Added a separate loop to handle the HUD and monitor resources in Abort script. This removed the need to call those functions multiple times throughout the script. Removed the ‘vess’ parameter from cls_nav functions. The staging check during countdown is now a function instead of one line of messy code. TWR Overhaul of defualt TWR values (all user configurable). Mininimum take off TWR has been increased to 1.3, Upper stage TWR has been increased to 0.8 and max TWR has increased to 4. These changes were made so that CLS can function across stock and rescaled installs in its default configuration. The central engine in a 3-booster configuration now throttles down to 55% slightly different. If the rocket can do this and maintain TWR (by increasing overall throttle) it will do so as early as possible. If not, it will do so when it can maintain a TWR above 2.1 throughout the throttle down. New Features CLS now gives two new hud readouts during ascent (experiencing max-q and passed through max-q). The code behind this is lightweight, 'hacky' and may not always show up. The abort script is now activated in response to a manual abort during CLS. Any hold scenario that occurs during countdown now gives the option to scrub, continue to launch & abort. Originally it did not give the option to continue in some scenarios. This was a mistake, the player should have final say over whether the rocket launches. Bug fixes Fixed the bug where dV and burn time calculations were inaccurate for vessels with multiple upper stage fuel tanks. Enjoy!

CLS v1.2.0 is now available to download from Github! This is a pretty big update that I have been working on over the past few weeks. I have tested it as thoroughly as I can, but I may not have caught everything. If you do find any issues, please either comment on this post or open an issue on github in the issue tracker. ChangeLog Major Changes: New GUI system for adjusting launch parameters, handled by a new CLS_parameters library. Instead of running 'CLS(250,90 etc).' all that is needed now is 'run cls.' Rewrote the ascent program to use the square root method. This new system improves reliability but may not be as efficient. It is now recommended to avoid a target apoapsis below 100km, as an apoapsis this low is reached too early in ascent, causing the first stage to be discarded and a high dV circularisation burn. Added a new azimuth function for fine tuning inclination. Thanks to u/BriarAndRye for his Instantaneous Azimuth Function. Initial testing suggests this code can reach a target inclination to within 0.001 degrees. Added maxStages as a script parameter allowing more flexibility for SSTOs and 3+ stage rockets. Added a logging function which can log data each 0.5 seconds to a csv file in the logs directory if the user wishes. Redesigned the countdown hold function to use kOS's GUI system and give the user on screen buttons rather than the improvised pilot input method. Rewrote the Abort script steering code. The pod will now perform a slow pitch maneuver away from the rocket to ensure it is clear from any RUDs. Added pre-launch check which determines if there is crew present and holds the launch if there is nothing in the abort action group. This is configurable. Added a contingency if the vehicle loses attitude control and cannot orientate itself for circularisation burn. Engines will throttle up a tiny amount and gimbal to the correct attitude prior to the burn. Limited CLS to a maximum apoapsis of 500km. This fixes an error where direct launches to higher orbits miscalculated the azimuth needed. Minor Changes: Fixed an error in CLS_hud which occurred when an abort was triggered. CLS_hud new shows remaining fuel as seconds rather than percent. Changed twr calculations during countdown/liftoff to be more accurate. Changed default inclination to 0 rather than 0.1. CLS now automatically removes the circularisation maneuver node before the script completes. Rewrote script initialisation to keep as many variables 'local' to their functions as possible. Should improve initial performance. Much more robust error detection for user input. Previous script was very weak at catching incorrect user input and holding the launch. Tidied up functions and libraries. Changed the method of detecting imminent staging to use fuel flow. This fixed an issue where CLS miscalculated remaining fuel in certain rocket configurations. Vehicle will now pitch gradually to surface prograde just prior to staging. This ensures discarded stages are not subject to unpredictable aero forces. Tuned the script to achieve target apoapsis more accurately. The script now attempts to achieve an apoapsis within 0.02% of its target. Implemented a control to limit upper stage engines to the same max TWR as first stage engines. Various tweaks to make the launch and ascent more efficient. Abort action group only fires if there is crew is on the vehicle. Multi-stage vehicles (Not SSTOs) that reach the target apoapsis without staging will now stage at once out of the atmosphere so that upper stages handle circularisation. Fixed an error in calculating circularisation burn time if the script is waiting to leave the atmopshere before staging (as explained above). Script will now wait until after staging before creating the maneuver node. Removed the throttle down prior to stage seperation. This was in place to limit sudden g-force spikes but interfered with other throttle up/down code in the script. Enjoy!

Is there any way to adjust the maximum altitude at which the parachutes will deploy? The max for the drogue chutes is currently 12000, can I increase it at all? Thank you!

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.

So I have been working on a KoS script for years. I wrote it for my own personal use but would now like to release it for others to enjoy. I have never released anything before and so I have suddenly become aware of licensing. I have looked around at the various license options and I will admit I don't fully understand it. I want people to be able to use it freely and do what ever they want to it/with it. The one thing I want to ensure is that if they redistribute this work, they do so under the same license I choose. As i understand it (please correct me if this is wrong) this will prevent someone altering the work and redistributing it under a much more restrictive license (which could be done with a MIT license i think?). I want this to be as available as possible across any version in the future. With this in mind I settled on the CC-BY-SA-4.0 License (but I have no idea if this is a good choice). Where It gets difficult is that the KoS script uses libraries from the KSLib collection. I took the lib_navball and simply removed the ones I didn't need (EDIT: and i have also added some comments to explain to potential users of my script how the functions in lib_navball work / why they are used). This is licensed under MIT. Am i right in thinking that as long as I distribute the file with its copyright info / license info then I am safe to redistribute it? The top of the file looks like this: Is it an issue that I am releasing the work under one license containing other work under another license? Furthermore, I relied on help from the amzing KoS community when i hit roadblocks writing the script. I have functions included which I have taken from the KoS subreddit. The functions were written by other people to solve problems posted in the subreddit (but not by me - their solutions just happened to suited my needs). Am i safe to redistribute this work? I intend to give credit of course. Thank you for any help Q

I've searched this topic as best I can and cant find the answer to my question - so I thought id post. Im creating a basic satellite contract pack. The contract in question is to deliver a payload into an orbit generated using the OrbitGenerator / RANDOM_ORBIT. What i want to do is set the rewardFunds to be calculated based off the orbit parameters generated (eg more reward for higher inclined orbit). Can this be done?

Having an issue with FAR on a realism overhaul game in 1.8. I launch a vessel, and after a few seconds or around 150m/s i lose control. The F3 log shows that the root part has been ripped off due to airflow. Weird as the root part remains connected and its right-click menu remains accessible. However, physics just kinda stops. My altiude is locked, my speed is 0, the apoapsis increases rapidly. There is a repeated log spam of: I've posted this in a few other mod pages, however as I test further i'm becoming more sure the issue is to do with FAR. I have very limited understanding but it looks like FAR cant 'voxel' the pod from Near Future Spacecraft, sets its voxel volume to infinite and this causes the issue. That could be a million miles off, as i said I really dont understand much! Would forcing FAR to use the parts colliders when calculating its volume solve the issue? Here's my game log Q Edit: Further testing with different parts made me notice that right before the log spam commences and FARVesselAero is disabled, it appears TAC life support deletes the vessel? The plot thickens. Edit 2: Removing TAC did not resolve the issue.

Having an issue with a realism overhaul game in 1.8. I launch a vessel, and after a few seconds or around 150m/s i lose control. The F3 log shows that the root part has been ripped off due to airflow. Weird as the root part remains connected and its right-click menu remains accessible. However, physics just kinda stops. My altiude is locked, my speed is 0, the apoapsis increases rapidly. There is a repeated log spam of: I asked in the MFI forum, but I now understand it is due to a mod using MFI. I know FAR lists MFI as a direct requirement, but i wanted to ask here first as these issues started around the time i edited RO_Physics.cfg for realism overhaul. That cfg was setting kerbal crew mass to 0.1. After a lot of testing, I found this was causing lots of parts in my save to have negative mass if they were attached to the root part. I removed that single line to resolve that issue, could it be the cause of this? Any help would be awesome. Here's my game log Q Edit: I reversed my change to RO_Physics.cfg and tested whether this resolved the issue. It did not. Unless anyone can see anything in my log, I suspect it may be FAR causing this.

Ok, you have helped by narrowing my issue down. I think either FAR or RO are potential causes, I’ll post there. Thank you! Q

Having an issue using MFI with FAR for a realism overhaul game in 1.8. I launch a vessel, and after a few seconds or around 150m/s i lose control. The F3 log shows that the root part has been ripped off due to airflow. Weird as the root part remains connected and its right-click menu remains accessible. However, physics just kinda stops. My altiude is locked, my speed is 0, the apoapsis increases rapidly. There is a repeated log spam of: Any help would be amazing. I will add, this kinda started ever since I edditted a physics config file in RealismOverhaul. It was setting kerbal crew mass to 0.1 and was responsible for lots of parts in my save having negative mass if they were attached to the root part. Somehow feels relevant in this issue. Here's my game log Q

Of course. Will give it a test and get back to you. I have a few mods I suspect may be causing it, I'll start from stock and slowly add select mods until I can consistently reproduce the bug.

https://github.com/linuxgurugamer/KCT/issues/9 I found this while searching this forum post for solutions / others with the same problem. I presumed as you closed the issue it had been resolved. The changelog for release version 1.4.6.6 also says issue 9 was fixed. I appreciate all this was nearly a year ago and code etc has probably changed! Thanks for all your mod support as always Linux!

I'm afraid I never did find a consistent solution. It actually pushed me to finally get a faster CPU and since then the problem has largely gone. The game now only fails to load once every 10 or so tries. As far as im aware, its a problem with the game trying to load too many models all at once and the pc memory just cant hack it. Sorry I can't be more helpful.

That's how I was doing it, with the PAW. Still needed me to add almost 1mil to access mid range avionics. Thanks anyway!

Experiencing an issue where recovered parts aren't reset. SRBs are running immediately after the flight loads and parachutes are already deployed. I'm aware this is a problem that has already been caught and fixed on github. Im running 1.8 with the right KCT downloaded. Im not entirely sure what you need to see in order to diagnose the issue, so for now have my log file. If you need something else, let me know. Thanks!

Can anyone shed some light on how Avionics configurations work? Its saying I cant afford to upgrade to certain avionics levels. I have these unlocked in R&D. I played around with it in a new save and for some reason I had to cheat add nearly 1 million funds before some of them were available. How is this configured in the files?

Just wanted to give this a bump. I've done some math and figured that essentially 1 unit of Water = 1.27 units of waste water in normal kerbal consumption. Water purifiers convert 1 unit of waste water back to 0.94 units of water. Therefore 1 water -> 1.27 waste water -> 1.2 water. I would suggest that the WasteWaterProductionRate needs to be lowered below 1 in the TAC patches.

Yeah my drivers are all up to date, double checked today.

Apologies! Only just updated to 1.8 so I had no clue this was a thing. Here's the file. Qwarkk

Playing a heavily modded RSS / RO game. Id say the game starts about 25% of the time. The other times it will load until the first black screen with the loading icon in the bottom right corner and freeze after a few seconds and become unresponsive. Ive had success deleting the module manager cache and relaunching the game but this is also unreliable. When it does load, everything is fine so im a bit confused. If anyone could have a look and tell me any glaring issues from the log, that would be massively helpful. Edit: Done some digging and my player.log file indicates lots of d3d11 issues. I've done a bit of research and this is a unity issue some say is caused when too many models are loaded simultaneously and graphics memory is overloaded. My graphics card is 6GB so this does surprise me. I've done system wide driver updates and tried forcing the game to run in OpenGL but this led to crashes in the VAB. I've heard running XMP profiles may cause it, so that's my next thing to try. Any help / suggestions much appreciated, Qwarkk.

So im trying to take the procedural fairing module and apply it to another part. Everything works fine, except I cannot find a way to change where the fairing attach node points are, and they are being placed inside the part. I presumed that editing the node_stack_connect values would do it, but im having no luck. Any help much appreciated. Q

Using this mod with RemoteTech, but the ground stations are all over the place. Is there a MM patch to add some? Thanks