Jump to content

Qwarkk

Members
  • Posts

    180
  • Joined

  • Last visited

Everything posted by Qwarkk

  1. CLS v1.5.0 is now available on Github. Make sure to remove old versions of CLS before installing v1.5.0 Changelog - Ship will now throttle down as its apoapsis approaches the target to ensure better orbit accuracy. Note: there are conditions under which this will not happen. - Altered the way CLS detects thrust curves for SRBs. The old method was more accurate but the performance hit was huge. The new method is less accurate but much more compatible and performs much faster. - Moved to my own method of fine tuning inclination. The old method was math heavy, difficult to tweak and there was a specific condition under which it would mistakenly force a launch abort. As a result lib_instaz.ks is now obsolete. - The new method of tweaking inclination is way more simple and compares inclination with target inclination to adjust the heading accordingly. - SRBs will now jettison when thrust curves dip below 15% instead of 25%. - The HUD readout for throttling down the upper stage now doesn't occur until the vehicle has a high enough twr for throttling to be necessary. - Default liftoffTWR changed to 1.4 for better ship design compatibility following some feedback. - Steering tweak to avoid a 'kick' at the start of the gravity turn. - The CLS menu for choosing orbital parameters now has an 'Instantaneous' launch window option. If provided with the inclination & longitude of the ascending node, CLS will calculate the instantaneous launch window needed to reach this orbit. - New library (CLS_window.ks) included to calculate the instantaneous launch window. Thanks to u/ElWanderer_KSP on reddit and u/Rybec as the library is just a slight tweak to their work from reddit. - When using the instantaneous feature, the HUD will show whether the launch is scheduled for the ascending node or descending node. - Fixed an error during orbital insertion where CLS may incorrectly calculate whether to burn at apoapsis or periapsis. - CLS will now perform a quicksave on the pad prior to launch. - More accurate calculation of the maximum possible apoapsis that is compatible to any planet pack or rescale mod. - User can now define the launch time as a countdown in minutes, seconds or a combination of both. - Fixed bug where CLS does not jettison fairings / LES if orbital insertion occurs on the first stage. - Fixed multiple bugs with the HUD. NOTE: The instantaneous launch window feature has been tested heavily and works as it is supposed to. However, I am not 100% confident in its compatibility with other people's game setup. If you find it is launching against the target orbit direction, please let me know.
  2. Thank you! This has been bugging me for ages, appreciate the help!
  3. Hi all, looking for some help. I created my own contract pack & contract group to do space station missions such as crew rotation, re-supply or evacuation. I know a mod for this already exists but i wanted to make my own. However, only one contract is ever offered from the multiple contract types available, despite all contracts having their pre-requisites met. Can you have multiple contracts all targeting the same vessel? Thanks for any help. If it would help for me to post the contracts, let me know and i will do so later - Im not home currently.
  4. Is there a manual or explanation for this mod? I cant find any explanation for the vessel safety rating, how many levels it has , how each flight increases reliability or the point at which too many uses will start to decrease reliability? Thank you.
  5. This has been a fun problem to solve! It seems the method implemented in v1.4.4 improved reliability but reduced compatibility. No problem though, v1.4.5 adds a check to ensure the parts it is attempting to activate hibernation mode on actually have the necessary modules and goes back to using an action rather than a field. This *should* solve the problem. I also found an issue where CLS was overloading the command part while it was in hibernation mode and it wasn't reliably running all instructions. This has been fixed by bringing the vessel out of hibernation mode earlier prior to circularisation burns.
  6. I have just released v1.4.4 which uses a different method to activate and deactivate hibernation mode, try this with Kerbalism and see if you have any luck.
  7. Good to know, I appreciate your testing for this. Next release I will include options to disable this feature and a disclaimer for Kerbalism users. Thank you!
  8. This suggests it may be a mod / difficulty setting causing it. If you launch a vehicle without using CLS, do you have full capability of toggling hibernation on and off? This was basically my idea for a solution. In future releases, I can add options into the configuration area at the top of the main CLS.ks file which would allow users to stop CLS doing certain things, such as hibernating. That way people who experience these issues which aren't 'terminal' can simply deactivate the CLS feature causing the issue.
  9. Interesting - are you confident this is a CLS related issue, or are there difficulty settings/mods that are potentially not allowing you to bring the probe out of hibernation mode? Can you take it out of hibernation mode if you force CLS to stop running? Can you post a screenshot of your gamedata folder or a modlist?
  10. I've looked into this and I think you're right. When CLS checks for launch clamps, it simply checks for any parts with the 'LaunchClamp' module. I've just downloaded Restock and looked through its patches and it seems restock replaces the stock launchclamp module with the 'ModuleRestockLaunchClamp' module. I've made a slight tweak and released version 1.4.3 which should fix this for restock. Thank you for bringing this to my attention .
  11. Thank you for this - immensely helpful. CLS v1.4.2 is now live! Only two changes - one to address the Linux issue discussed by u/ruiluth and u/jwbase - thank you both for your help. The other is that CLS will now prevent SAS activation while it is running - SAS does not play nicely with its steering commands. Enjoy!
  12. Thanks for the feedback - manually staging your craft while CLS is running is a deal breaker and will always cause errors. From the kOS output, it looks like by staging the vehicle, the part CLS was monitoring fuel levels for was jettisoned and it threw an error. Is the script working as normal when you dont stage? As for the Linux file system, im on windows so I cant test or change this - can you tell me which files Linux drops into those two folders?
  13. Nothing to do with the paths, just a complete oversight on my behalf. CLS presumed that all engine parts have the module 'ModuleEnginesFX' and this isn't the case. I've corrected it in CLS v1.4.1 now available to download. Thank you for the feedback and providing me with the screenshot.
  14. CLS v1.4.0 is now available from Github! This update has been a long time in the works and I have taken some extensive breaks from KSP which slowed its release. Every time I release a new version of CLS, I always feel like its the finished product with little left to add, and then a few weeks later, a new idea will hit me and mass changes will be made. This time though, I really do think CLS is on the home stretch to be finished. There are one or two features I want to implement, but apart from those I think most of the changes from this point onwards will be bug fixing. Changelog Abort The abort procedure included in CLS v1.3.0 relied upon another script (ChuteDescent.ks) which I completely forgot to upload. Apologies! ChuteDescent handles chute deploy on the aborted capsules descent. I split it into it's own script as it can also be used for a capsule re-entering the atmosphere. Minor Changes Improved CLS logic for detecting incorrect staging where SRBs are incorrectly placed in first stage. CLS now has a system of excluding hullcam parts from its staging checks and part counts. CLS can now detect the presence of fuel cells on the vehicle and will activate them automatically if EC is below 25%. I can't spell separation/separated/separate it seems. Corrected the spelling (thank you jefferyharrell) Added a check to confirm engines are throttling correctly at T-0. I found that the script was aborting some launches when it didn't need to due to throttle 'lag'. The ship will hold pitch a for 3 seconds after staging to ensure the next stage is clear of the previous stage before pitching. Staging will now occur when SRBs are below 25% thrust, not 20% (for SRBs with thrust curves). More accurate launch throttle calculations and ascent throttling when using SRBs with thrust curves. Warp limit increased during coast phases. The script will also reduce the warp level progressively approaching a burn. CLS will now hold the launch if launch clamps aren't detected and suggest a scrub (Thanks go to Tacombel for highlighting this issue) Staging at ascent completion has been adjusted to make it smoother and less chaotic. Removed throttle down when approaching target apoapsis. General script writing tweaks Ascent profile is more aggressive resulting in improved efficiency. CLS now checks if the circularising engine has an unlocked gimbal before using it for attitude control if the vessel isn't correctly orientated for circularisation burn. Also only throttles to 0.1twr rather than 10% thrust (which may have been overkill for upper stages with high thrust engines) Pretty extensive renaming of variables and functions so that their names indicate what they do. CLS logs are now named with the real world time of launch. EC Consumption Complete review of the script in an attempt to reduce the amount of electrical charge CLS requires to run. 33% reduction in EC consumption during launch and ascent. 50% reduction in EC consumption during coast due to CLS now entering a 'low-power' mode. CLS will now also put all control parts into hibernation mode during the coast phase. HUD Complete redesign of the bottom HUD elements. During pre-launch, if a scrub/hold occurs there is now a 'More info' button which will explain the cause of the hold to assist you in solving the issue and successfully recycling the launch sequence. Added a readout to show which runmode the script is in next to the Mission Elapsed Time on the HUD. The fuel readout has been updated. It used engine fuel flow to calculate remaining fuel - accurate when the engines are burning, but inaccurate during coast phases when fuel flow is 0. So now it will show remaining fuel if engines were to burn at 100% thrust while in coast phases. Time to apoapsis/periapsis readout now shifts over to show minutes when it would exceed 999 seconds. CLS will now detect precise moment of Max Q rather than a time frame in which it happens. CLS now gathers more information for the HUD during pre-launch. dV changes on Orbit The concern here is that boil-off or use of fuel cells will reduce the vehicles remaining dV which means it will not be able to complete circularisation burns. CLS accounts for this by ensuring the vehicle has around a 5% dV margin for upcoming burns. 1.4.0 adds a fail safe so that if boil-off or fuel cell usage has reduced the vehicle's dV to below a burn's dV requirement, it will not cause script failure. This is done by recalculating vehicle dV just before a burn and amending the maneuever node's properties if necessary. In these scenarios, the final orbit achieved by CLS will not be circular. Achieving Orbit This is a major change and the code to implement this system is spread all through CLS and its libraries - I will summarise what it does below. Previous versions of CLS were very basic in that the vehicle would burn until apoapsis reached a target orbit altitude, cut-off its engines and then burn at apoapsis to circularise the orbit. This presented issues with low orbit altitudes just outside the karman line or situations where it left the upper stages with unrealistic circularisation burns. Now, the script has multiple methods of circularising: As before, circularising at apoapsis. First burn is longer and stops when periapsis reaches the target orbit altitude. Then at periapsis, the vehicle burns retrograde to achieve a circular orbit. Same approach as number 2, but the script sees the apoapsis is getting extremely large, so it cuts the engine, burns at apoapsis to raise the periapsis to target orbit, and then burns retrograde at periapsis to circualrise the orbit. The script continuously monitors multiple data streams to determine which approach is best.
  15. As it turns out, the first issue is already fixed in the next release of CLS. The next version drastically changes how it handles low orbits so it will definitely be able to cope with 75km orbits. Also, the throttle down when approaching target apoapsis has been scrapped. As for the second issue, I have now tweaked the procedure the rocket goes through upon achieving target apoapsis. The staging will now be a lot less chaotic but will happen as soon as target apoapsis is reached - it wont even wait until 70km. Edit: The next release of CLS is 1 or 2 days away. Its quite an update too.
  16. 75km is a challenge, but I will look into improving this in the next release. As for the other matter, i will look into it and get back to you.
  17. It isn’t a problem, earlier versions of the script just had varying results launching to lower orbits. It’s more of a warning to expect results to vary, but it won’t stop you launching. I can probably review how good the newer script is at hitting these orbits and remove that warning - will do that for the next release. Can you elaborate more on the situation it stages in at 70km? What is the eta to apoapsis? How many stages does the vessel have in total? What is your target orbit? Is it staging from first to second stage or from second to third stage? There are numerous reasons it may be staging at that point, help me narrow it down and I’ll have a look at changing it slightly
  18. So I have spent many hours over the past few days looking into this. As I thought, changing CLS to launch a vehicle with a solid-fuel first stage was relatively easy. However, essentially all of the logic, calculations and script features are designed for liquid fuel stages. The script makes a few core presumptions about the launch vehicle, such as being bi-propellant and having throttling capability. I found that to fully adapt CLS to solid fuel first stages, I was essentially going through CLS's thousands of lines of script and functions and basically saying "if its a solid fuel first stage, just ignore all of this and all of that". I found myself writing hundreds of new lines specific for this vehicle design and forking the script at almost every turn to either run solid fuel or liquid fuel modes - I didn't like the result. The way I want CLS to function is that no matter the vehicle design the script runs through the same set of instructions and functions, and not that it runs through different instructions and functions for each vehicle design. This is hard enough with SRBs! I definitely want CLS to be able to handle solid rocket first stages, and it remains a feature i intend to add, but I need to find a new approach to do it.
  19. Hi Tacombel - glad you sorted the issue. This is actually super useful to know, I hadn't thought of making CLS accommodate rockets without launch clamps / fail safes if people try to launch without them. This will be a feature for the next release. Q
  20. It seems that kOS only recognises a part as belonging to the action group it is first assigned to. Hopefully this will explain what i mean: Example 1: In VAB, part x is assigned to action group 1 followed by action group abort. This will not show when running print Ship:partsingroup("abort"). Example 2: In VAB, part x is assigned to action group abort followed by action group 1. This will show when running print Ship:partsingroup("abort"). Is this intentional behaviour for kOS? Is there a workaround?
  21. 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.
  22. 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.
  23. 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
×
×
  • Create New...