Jump to content

Search the Community

Showing results for tags 'kos'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • Welcome Aboard
  • Kerbal Space Program 2
    • KSP 2 Discussion
    • KSP 2 Suggestions & Development Discussion
    • KSP 2 Dev Diaries
    • Show and Tell
  • Kerbal Space Program
    • The Daily Kerbal
    • KSP Discussion
    • KSP Suggestions & Development Discussion
    • Challenges & Mission ideas
    • The Spacecraft Exchange
    • KSP Fan Works
  • Community
    • Player Spotlight
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
  • Gameplay and Technical Support
    • Gameplay Questions and Tutorials
    • Technical Support (PC, unmodded installs)
    • Technical Support (PC, modded installs)
    • Technical Support (Console)
  • Add-ons
    • Add-on Discussions
    • Add-on Releases
    • Add-on Development
  • Making History Expansion
    • Making History Missions
    • Making History Discussion
    • Making History Support
  • Breaking Ground Expansion
    • Breaking Ground Discussion
    • Breaking Ground Support
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Skype


Twitter


About me


Location


Interests

  1. I am proud to present PEGAS: Powered Explicit Guidance Ascent System - a kOS script for automated launches using a real-world guidance algorithm taken straight from the Space Shuttle documentation: the Unified Powered Flight Guidance! What is PEGAS and what is it capable of? PEGAS is a launch autopilot made in kOS. Its aim is, given a vehicle description and a mission target, to execute the entire ascent to a desired orbit. It supports defining orbits by periapse, apoapse, inclination and longitude of ascending node - allowing you to ascend to any (reachable) orbit in any given orbital plane. You can even select a target in the map and launch to the exact plane of this object. Short list of what PEGAS can do, in the approximate order of when it will be doing it: automatic launch window and azimuth calculation, flexible atmospheric ascent using one of two modes: simple ascent in 3 steps: vertical ascent for a given time, pitch-over by a given angle, hold prograde, advanced ascent by pitch-altitude table (thanks to Aram1d) event system, allowing you to schedule things like fairings jettison, throttle management, roll maneuvers, or anything you want (via KOSDelegates), flexible automatic staging, allowing for even complex staging sequences requiring separation of a spent stage, ignition of ullage motors (SRB or RCS), ignition of the main engine, precise orbital guidance using UPFG, able to target any elliptic orbit in any plane (provided the vehicle can physically reach it), including launching to a plane of an existing object, inter-CPU communication (credit to Patrykz94) system made with reusable boosters in mind (also see his Falcon-style landing script). Contributors (thank you ): Patrykz94 - inter-CPU communication system Pand5461 - upgraded CSE routine Aram1d - pitch-altitude atmospheric guidance For a general showcase, see my most recent video, where PEGAS controls an Atlas V ascent to a parking orbit for a rendezvous with an International Space Station: PEGAS is approximately 2000 lines of code long and released under the MIT license. How do I get it, run it, read more about it? You can get the code from my GitHub (current release: v1.3 "Olympus"). You are strongly encouraged to read the tutorial and reference! PEGAS is not a straightforward "click this to fly" kind of tool and needs to be set up for your vehicle and mission. If you're interested in the mathematical details of the algorithm itself - check my prototype repository, especially its documentation. If you've spotted a bug or have a feature request - feel free to post either in this thread, or better yet on my GitHub issue tracker (read this, please). What is this thread? This thread carries a history of my development, from the first version of PEGAS that used a very basic formulation of Powered Explicit Guidance, through all my effort to implement the Space Shuttle guidance, to the release of a complete guidance script and all subsequent updates. History of progress: Summer 2015 - work on a MATLAB prototype using a basic form of Powered Explicit Guidance (read about the algorithm here). Late 2015 - MATLAB code ported to kOS. February 2016 - release of the first version of PEGAS (watch my video here, but bear in mind that this has very little in common with the current state of the project). Summer 2016 - I'm back at work on PEGAS, researching the Space Shuttle documentation. August 2016 - working MATLAB prototype of 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. Read more here. October 2016 - implementation of UPFG for multiple stages. November 2016 - verification of 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). February 2017 - the MATLAB prototype is complete, work on the kOS port begins. March 2017 - numerical consistency proven between MATLAB and kOS implementations of the key UPFG algorithm. May 2017 - basic version of PEGAS flies a simple rocket in KSP. July 2017 - first release of PEGAS! November 2017 - PEGAS version 1.1 is out! January 2021 - PEGAS version 1.2 is out! October 2022 - PEGAS version 1.3 "Olympus" is out! Release v1.3 "Olympus" is the final major release of PEGAS. Therefore, I'm switching this project into end-of-life mode, where it will only receive fixes to any bugs that might come out. Nonetheless, any updates will be posted to this thread, with this post being refreshed to link to the new developments. Thank you for following me on this journey
  2. 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
  3. 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...
  4. 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)
  5. 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.
  6. 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
  7. 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]
  8. 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
  9. 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
  10. 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.
  11. LaserDist LaserDist v1.4.0 for KSP 1.10x. and KSP 1.11.x The only real change here is compiling against KSP 1.10.x DLLs and support for putting LaserDist parts inside the new KSP inventory system. The KSP 1.11.x updates added an EVA inventory system for parts and they require parts have a new "ModuleCargoPart" section added to its Part.cfg files to use it. This release also works on the previous KSP version, KSP 1.10.x too, but it may cause a startup complaint (which it is safe to ignore) in the logs on KSP 1.10.x when it sees the new "ModuleCargoPart" section in the config files. LaserDist v1.3.0 for KSP 1.8.1 Why does this Mod exist? The intended purpose of this part is to be used in conjunction with scripted autopilots like [kOS](https://github.com/KSP-KOS/KOS/releases), 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. Hey, where'd the pictures go? This post used to contain some embedded images illustrating what LaserDist looks like. They no longer appear because I no longer want to support the IMGUR site due to their awful willingness to let advertisers run whatever Javascript they feel like without properly vetting it for safety. So I pulled my albums off that site. Too many random ad redirects and browser-hijackings on that site for me. If KSP forums support some other image hosting site, I may put the images back but I don't know at the moment how to get the forum to use anything other than IMGUR.\ KSP 1.8 update. No changes to Laserdist except API usage with KSP 1.8. KSP 1.8 deprecated some API calls, replacing them with alternate versions. In particular, the shader used with LineRenderer to draw the laser lines needed to be built with a new kind of constructor. The V1.1.0 update: Another go at fixing the phantom hits bug. See: https://github.com/Dunbaratu/LaserDist/pull/24 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: http://mods.curse.com/ksp-mods/kerbal/246141-laserdist https://spacedock.info/mod/765/LaserDist https://github.com/Dunbaratu/LaserDist/releases ZIP Download (See release page above): Source Code Hosting site: * https://github.com/Dunbaratu/LaserDist License: * GPL v3 Copyright (C) 2014,2015,2016 Steven Mading (aka Dunbaratu on Github) [email protected] 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](http://wiki.kerbalspaceprogram.com/w/images/d/dd/Electronics.png). 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.
  12. 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:
  13. It took me a while but my autopilot is finally finished. Download file here: https://github.com/Toukie/KSP/tree/master/GAPAPOV
  14. 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.
  15. 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!
  16. 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.
  17. 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?
  18. 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.
  19. 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:
  20. 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!
  21. 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!
  22. 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
  23. Designed a new Launch vehicle in KSP using KOS. This is the testing of the Launch Escape System.
×
×
  • Create New...