Search the Community

From what I gather from interviews (Nate and EJ_SA for example), mature KSP2 gameplay will have a lot of elements similar to Factorio / Satisfactory / Dyson Sphere Program. I have to say Factorio is one of my favorite games so I really appreciate that. I imagine that we will have to build our extraction / processing / transport vehicles and colonies and set up logistics networks using our creations. I have a hunch this delivery routes system will have its own management interface for automation. I think it's really cool because we'll be able to build "cheap" transports with basic materials we obtain and "expensive" exploration spaceships with more exotic elements. So basically we'll have to adapt to each planet and make the best designs we can (rovers, trucks, aeroplanes, helicopters, boats, rocket ferries etc.). There's a lot of reasons to design a new vehicle and constantly iterate. We'll always have something new to build or improve, even without contracts. But what I found a little bit stale about automation games is the lack of interesting end goals. I think it's a really good idea for KSP2 to have exploration as its main purpose. Discovering the planets inside a new star system and their secrets, entering the atmosphere and landing for the first time, doing scientific experiments, exploring interesting anomalies.. I think that this is a good motivation to "grow the factory". How do you feel about the construction and management simulation elements of the future KSP2? Any specific things you would want KSP2 to borrow from the other games I mentioned?

BenjisHardwiredLogic Version: v1.2.2 Dependencies: ModuleManager.4.2.2.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.2 - The "Correct me, if I'm wording things wrongly and please spin stabilize" release -Aded a rare 4th Stage and Spin-Motor Option for Igniting and Decoupling -Grammar update: - Editor: Igniting -> Ignite - Editor: Decoupling-> Decouple - Messaging: Jettison-> Jettisoning - RCS with its own correct grammar 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 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

BenjisHardwiredLogic Version: 2.1.0 Dependencies: ModuleManager.4.2.3.dll Download: Github - Spacedock - Sourcecode Installation: Simply drag the folder BenjisHardwiredLogic into your GameData folder. Description: Benjis Hardwired Logic… ...is a set of tools to predefine staging actions in your rocket. Launch Clamps can release after a given time (whenever you think the engine is spooled up). Fairings can automatically be jettisoned at a given altitude. RCS and Decoupler can be activated at a set time after launch or prior to reaching Apside. Engines can ignite at a set time after launch or prior to reaching Apside. An engine can also be cut when a set Apside is reached. An Apoogee Kick Motor can either Burn-Out, Circularize or Cut-Off at a set Apside. On-Screen appearing messages for all events can be turned on / off (in VAB and Flight). Check out the awesome flowchart in the pdf provided.

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...

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.

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.

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

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.

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()