Jump to content

Search the Community

Showing results for tags 'automation'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements
    • The Daily Kerbal
  • Kerbal Space Program 2
    • KSP 2 Discussion
    • KSP 2 Dev Diaries
    • KSP 2 Suggestions & Development Discussion
    • Show and Tell
  • Kerbal Space Program
    • KSP Discussion
    • KSP Suggestions & Development Discussion
    • Challenges & Mission ideas
    • The Spacecraft Exchange
    • KSP Fan Works
    • Player Spotlight
  • Community
    • Welcome Aboard
    • 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


  • Developer Articles

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL



About me



Found 8 results

  1. Hi, I know this might be somewhat controversial, but please hear me out first. I love automating things. I spent hundreds of hours in games like Factorio and Dyson Sphere Program and I have also tried to automate different things in KSP 1. As an example, automation is great for things that need to be perfectly repeatable (like an ascent with a specific profile) or that are hard to do manually (like suicide burns). The best way to script it in KSP 1 right now is to use kOS but I think there might be a better option. While waiting for KSP 2 I decided to try SimpleRockets 2 (by the way, it's a cool game, go try it out). So I opened the game, downloaded a cool-looking Atlas V and was blown away by what happened next. The rocket knew how to put its upper stage into orbit not just around its home planed but also its moons at a desired altitude! Turns out, SR2 has a built-in visual scripting language called Vizzy you can use to write programs like that. I decided to try it out and just in a few hours I had two programs for performing ascent and landing for me. Here's how the language looks: SR2 blog post about Vizzy. This could also be used to complement new tutorials by showing not just a video but an actual rocket flown by a computer to teach new players. And yes, all this can (and has) been done before but I find the experience of using something like kOS far from perfect: you need to install the mod, learn a new scripting language, constantly switch to an external text editor, launch scripts from the command line and debugging is often a pain. If implemented correctly, built-in scripting can improve the player's experience, especially if scripts could be shared through the Steam Workshop for those who don't want to code themselves. And hey, it's not a bad thing either if someone learns how to code a bit while playing KSP 2! And the good thing is, you don't have to reinvent the wheel. This has already been done in SR2 and it works great there. So what do you think?
  2. 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...
  3. BenjisHardwiredLogic Version: v1.2.1 Dependencies: ModuleManager.4.1.4.dll Download: Github - Spacedock - Sourcecode Installation: Simply drag the folder BenjisHardwiredLogic into your GameData folder. Description: A ksp mod to "hardwire"-logic into rocket designs. (At this point: decoupler-staging, fairing-separation and engine/rcs-ignition). Every engine, decoupler or fairing is now disabled by default and can be enabled/disabled by the push of a button in the editor's PAW. Decouplers and also Fairingbases can have a delay assigned (up to 30min 59.9sec). The same for Engines (solid and "liquid") and RCS thrusters. Procedural Fairings (only RO, not the squad basegame thingies) can have a height between 0 and 140 km assigned. Every other value will start counting down once the launchclamps are released. When reaching 0min 0.0s the decoupler will automatically decouple, the engine light up and the RCS become active. Fairings automatically separate at the set height (above sealevel). If the messaging system is activated, 3 pre messages at -10s, -5s and -2s will be shown on screen. Also a on screen message at the actual decoupling, ignition or fairing separation are shown. This will save a lot of space in the StagingList because the whole launcher can be put into 3 stages (or 2, if the 1st stage Engine is immidiatly at 100%, for example if you're using a SolidMotor). But maybe you should just leave your StagingList the way it always was. Else you mess up all the dV and burntime readouts (KER and MJ). The other upside is, you can always stage, decouple and separate fairings ahead of countdown (in case of engine failures). This mod does not prevent that. Example (of your standard launcher): Stages 0-4 un-automated payload-stuff, whatever you wanna put into space... Stage 5 2x radialDecouplers connected to the solidMotors (delayed for 30.5sec) 2ndStageEngine (2min burntime) (delayed for 1min 3.8sec) 2ndStageDecoupler between 1st and 2nd stage (delayed for 1min 4.8sec) payloadDecoupler between 2nd stage and payload (delayed for 2min 4.0sec) procFairing (set for 90km) Stage 6 launchClamps 2x solidMotors (30s burntime) Stage 7 1st stage engine (65s burntime) So, let's look at what will happen, shall we? First spacebar fires the main engine. Once that is spooled up, spacebar fires the solidMotors and releases the launchClamps. Now the countdowns will start. At 30.5s the solidMotors will decouple At 1min 3.8s the 2nd stage will fire. At 1min 4.8s the 1st stage will be decoupled, hopefully the 2nd stage is spooled up by now. At 90km the fairings will separate. 2 minutes 4 seconds after lift off: The payload will be decoupled from the 2nd stage. Changelog: v.1.2.1 - The "SHUT-UP! I told you not to message me" release -CHANGELOG & README: - Added to the release zip -OnScreen messaging system: - All messages are now schown in the upper center - Messages can be turned off now, forgot to implement that earlier v1.2 - The "warn me before doing stuff automagically" release -OnScreen messaging system: - Can be turned off - Shows 3 pre messages before decoupling and igniting at -10s, -5s and -2s - Shows a message at decoupling, igniting and fairing separation v1.1.1 -The "humans want something nice to read" release -inflight PAW change: Circuits are: connected/disconnected instead of active?: true/false v1.1 - The "ON-OFF-Button" release -enable/disable button to disable funcionality instead of 0.0s/0km v1.0 - The "never available, 'cause I forgot to generate a zip file" release -initial release
  4. Yeah, so it's possible to automate many aspects of forum moderation, which liberates moderators to spend their time on special cases and moniter the automated system for errors. Also, instantaneous post approval would be a plus, and I bet you're busier on weekends. https://utopiaanalytics.com/utopia-ai-moderator/ https://www.theadminzone.com/threads/moderating-a-community-with-ai-automated-actions.151885/ I know this thread may not belong on this forum as the suggestion is peripheral to the game.
  5. I think it would be great to heave the ability to programm tasks for the Spaceship to perform... IN ADDITION to the action groups. When you want to design a Capsule that lands in water with parachutes but also got retro thruster to slow the landing. It would be cool to be able to programm the task to ignite the thrusters when reaching a specific height. For example 5 metres above surface height. It would also be great to add the possibility to perform a specific action after a certain number of time. Just like detaching two boosters + disabling the engine (like an action group) so the boosters can separate peacefully and after 2 seconds reigniting the engine. It could also be some kind of extension to the action groups as we know them. Also in terms of automation it would be cool to heave. When you install a mod that adds a real Soyuz Capsule it has to ignite its retro thrusters. I just thought I want to open this thread. I think it would be a nice idea wich can really make some things easier. If it really is a great idea, I would be extremely happy to see it in KSP 2.
  6. AutoRove Mod for Kerbal Space Program A KSP Mod to give the Protodyne Rove Body the ability to move a landed vessel towards a target coordinate autonomously in the background. Right click on the Rove Body and activate AutoRove. The speed of the rover is the maximum speed the wheels can tolerate, scaled down for lower gravity worlds (but not up for higher). This mod is redistributing ModuleManager and Mini-AVC License: MIT Source: Bitbucket Download: * Bitbucket * Kerbalstuff * CKAN File Changelog: v. 1.0.3: - should now work if the Rove Body is not the root part - fixed a bug with rovers having a speed of 0 v. 1.0.2: - should now work if generators are attached - minor cosmetic changes v. 1.0.1: - AutoRove works now properly around the KSC - fixed the .version file v. 1.0.0: - initial release Known Issues: * does not track energy use for moving * only numeric input for target coordinates, no mouse over * does not move the active vessel, only unloaded vessels * no visual display for the target
  7. THIS IS THE OLD THREAD! @linuxgurugamer has graciously taken over this mod as he has the tools, talent, and most importantly (and surprisingly given the number of mods he maintains) time to keep up with it. Please visit the new thread here: Spoilering the rest of this as it's going to get more and more irrelevant over time. Thanks to KottabosGames for showcasing All Y'All on YouTube (why didn't I think to do that?) And also thanks to Chrizz for his review as well, that shows All Y'All working with non-stock science parts.
  8. I’m in the camp where I think “best practice” is to leave my Steam™ installation alone, and copy the entire KSP folder to a different spot and use that to play KSP with. That also has the advantage that you can keep your existing 1.1.3 install while frolicking around with the 1.2 pre-release. Of course there is the boring act of copying over the files from Steam when a new pre-release-release has taken place. A simple file copy will do, but there’s always the theoretical risk of leaving files from a previous release that are no longer needed. More thorough is to remove all existing files, but keep your mods and saves, and then copy the new release over. To get a clean update, every single time, I’ve written a simply Python script that does all that for me. I’m sure there is room for improvement—let me know! The advantage of using a script like this is the ability to extend it. This weekend I'll add a function to change some of the settings (notably using IJKL to steer rovers, and running KSP in window mode) for instance. That will be easy at this point. Anyway, I thought sharing wouldn’t be harmful. Enjoy! # --------------------------------------------------------------------------- # update KSP installation by copying over from steam # --------------------------------------------------------------------------- import os, shutil from zipfile import * # source is the location of your steam (squad?) copy SOURCE = r'C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program' # dest is the actual install you're playing with DEST = r'C:\Users\Kerbart\Documents\Kerbal Space Program 1.2' # zipfile is where the data is temporarily saved. your system temp folder # would be good. or a ramdrive, if you have one. ZIPFILE = r'R:\kspsave.zip' # the exception list of directories NOT to back up EXCEPT = ['saves\\scenarios','saves\\training','gamedata\\squad'] def main(): exec('Backup', makeZip) exec('Clear', clearDest) exec('Copy', copyAll) exec('Restore', extractZip) print('Done') def exec(title, function): print(title) function() def clearDest(): shutil.rmtree(DEST) def copyAll(): shutil.copytree(SOURCE, DEST) def extractZip(): myZip = ZipFile(ZIPFILE, mode='r') myZip.extractall(DEST) def makeZip(): myZip = ZipFile(ZIPFILE, mode='w') process_sub_path(DEST, 'gamedata', myZip) process_sub_path(DEST, 'saves', myZip) myZip.close() def process_sub_path(base_path, sub_path, zipfile): full_path = os.path.join(base_path, sub_path) for name in os.listdir(full_path): short_path = os.path.join(sub_path, name) if short_path.lower() in EXCEPT: pass else: full_name = os.path.join(base_path, sub_path, name) if os.path.isfile(full_name): zipfile.write(full_name, short_path, ZIP_DEFLATED) elif os.path.isdir(full_name): process_sub_path(base_path, short_path, zipfile) if __name__ == '__main__': main()
  • Create New...