MaltYebisu

I think it's essential to keep KSP a fun game where realism takes a step back to gameplay. I believe leaving a lot of realism to mods is a great way to get the best of both worlds. Never the less, there are still some things I think should become stock. For me the most important one is persistent rotation during time-warp. I thought my game was bugged after I managed to reach orbit for the first time and the time-warp killed all rotation in the craft. It bothered me because time-warp is supposed to be a way to fast forward time to make the game playable, not something that exists in the game world. Because it is impossible to play the game without switching vessels or time-warping, it is not even something you can refrain from doing to avoid cheating. I know changing this now would perhaps force a lot of people to change their play style a bit. But adding a kill all rotation button in the debug/cheat-menu would be a better solution in my opinion. I'm not familiar with the technical reasons for killing all rotation during warp, but if the Persistent Rotation Mod can manage rotation with little to no performance issues, then implementing it in stock would not be too hard I imagine.

Here it is: KSP 1.4 Golden Spreadsheet

Congratulations with the release! The new version deserves a new thread. RP-0 and RP-1 are different enough to warrant it, besides, some people might need the information in the OP for a 1.2.2 RP-0 install. Having two treads might make it easier to find what they are looking for.

@Epox75 I used The wayback machine to find the dead Better Than Starting Manned thread and managed to download the mod from the links in the OP. Maybe you will find the dead thread on there.

RP-1 is not on CKAN because it's not released yet. You have to download the developmental branch of RP-0 on GitHub. The best way to install it is to follow @Bornholio's install order in the Golden Spreadsheet for 1.3.1. Some of the required mods are on CKAN but some you have to download manually.

There are a lot of improvements "under the hood" and many small changes, but as a player, the greatest differences I noticed are: Tooling cost: Many procedural parts have a "tooling cost" to compensate for the lack of "part purchase". If you don't tool your tanks the production cost and time will go up. The tooling cost changes the way you design your rockets because you would usually try to re-use the same size of tanks to save on tooling costs. Kerbal training: You need to train your kerbals for the different capsules you are using. Kerbal retirement: All kerbals have a retirement date. This date can be extended by letting your kerbals fly missions. Because I don't use planes (and a lack of planning), all 4 of my original kerbals retired before I could use them on my first RP-1 game... I think these changes add to the challenge, and it would feel a little strange to go back to 1.2.2 RP-0 after playing 1.3.1 RP-1. It takes some time to get used to the new gaming mechanics, but I ended up loving RP-1. If you want to get a feel for RP-1, then I recommend @NathanKell's "Rusty RP-1" series on Youtube. It's a bit old, so some things have changed after he recorded it, but it's an excellent introduction to RP-1, and he explains some of the changes and the reasoning behind them.

I love and share your optimism! I own KSP on GOG, and they don't have the 1.3.1.1891 version available for download anymore, only the 1.3.1.1836 pre-release version is available on the "pre-release beta channel". If you contact customer support, they will let you download any version you want, but I can imagine that this is a barrier for most GOG users of KSP.

Thank you for explaining! Nice! I love kerbal solutions to RP-0 missions. Why design a replica you know works. EDIT: With the new version of KSP out, would it be better to skip 1.4.5 support in favour of 1.5.x? I get the feeling that some RP-0/RO developers didn't care too much for the 1.4.5 release.

True... It's also a good practice to back up the file you are editing, so you don't do permanent damage to a file you worked hard on. Github is a free way to keep track of the changes you've made and makes it easy to roll back or see where you might have made a mistake. You have to be willing to let it be public for the free version though. I don't know about notepad ++, but Visual Studio Code has integrated git support. It makes it super easy to manage your edited files.

@Bornholio , I'm a little confused about the RP-1 development. Are there two versions of the RP-0 developmental branch or do the same branch work for both 1.3.1 and 1.4.x? I know aw1621107 made a pull request with 1.4.1 compatibility, but how does that work? I'm not that familiar with github, so I'm a little confused.

I love this mod! I use it for my RP-1 (developmental version of RP-0) game, and today I noticed a few things that might be cool if FF handled. In RP-1 maintenance cost is something you have to deal with and it is 500 credits for one kerbal per year. That means you might have to dismiss a kerbal or two not to go bankrupt (in fact, that was precisely what I had to do). Unfortunately, KSP handles dismissals different from killed kerbals, so you don't see them in the "lost" category in the Astronaut Complex, and the kerbal disappears from the FF hall of fame completely. I don't know how KSP handles dismissals, but I suspect that a dismissed kerbal is just deleted entirely. Would it be possible for FF to show kerbals you have dismissed as "fired" or "dismissed" in the same way you display dead kerbals? Another thing RP-1 introduces is retirement for bored kerbals. Every kerbal has a retirement date, and if you don't give them cool missions to fly they retire. Retired kerbals show up in the Astronaut Complex as "retired", but in FF they show as "dead". I think it would be elegant if FF would have a category for retired kerbals to differentiate them from the ones you killed. The last thing from RP-1 that might be relevant for FF is mandatory courses to be able to go on missions with different capsules. These courses are only valid for a certain time before they expire. It would be nice to have FF track this for each kerbal so you could see classes the kerbals have taken in the past. I know maintaining a mod and updating it is a lot of work, and I don't expect @Nereid to make changes to his mod. Perhaps this is best handled on the RP-1 side of things, or as an add-on to FF like a badge-pack, but I just wanted to share some ideas I had.

Thanks for clarifying! I guess I'll wait a little bit before switching (I'll milk my career game for what it's worth until RP-1 and the dependables are fully ready for 1.4.x). My impression is that RP-1 for 1.3.1 is less stable than RP-0 for 1.2.2, and 1.4.5 might be less stable than 1.3.1. By the way, are there any plans to implement the personal parachute/hang glider upgrade for 1.4 in RP-1? I'm curious about how a "realistic game" would handle this mechanic. Would you ignore it and leave it for the player to do what they want with the ability? (Having basic parachute training include a trip to Mars and Venus for the experience requirement seems a bit "unrealistic" ) Or are there any plans to change this for realism's sake? I think @NathanKell mentioned in a video or stream that he wanted to remove the ability to EVA from early capsules to make it more realistic.

Cool! I use 1.3.1, but I'm thinking of starting a new career. Would you recommend switching to 1.4.5 or sticking with 1.3.1 for now? When I look at KSP RO Debugging (AKA: The Golden Spreadsheet) Mk1.4 it looks like everything should work fine. Are there any reason to not use the latest version of KSP? (Your ship exploded on slow impact with the water, but I sometimes get these bugs with RP-1 in 1.3.1)

Thank you for explaining this for me @ElWanderer , @NewtSoup, and @Steven Mading ! This forum community makes it fun to have questions. I learnt a lot from your posts.

I'm trying to show how much free space is available on the hard-drive. I've read the kOS Documentation: Volume, but I can't figure out how to print the information I want. I have tried different approaches to no avail. //Some stupid attempts: // 1 print volume:freespace. // 2 print kOSprocessor:volume:freespace. // 3 set p to ship:partstagged("Telemetry")[0]. for f in p { print f:volume:freespace. } // 4 set p to ship:partstagged("Telemetry")[0]. for f in p { print f:kosprocessor:volume:freespace. } Does anybody know how to print the free space left on the kOS hard-drive? Also, does anyone have any tips on how to read the documentation? I have a hard time figuring out how to do things on the pages without examples.

If you use GOG, then write support and have them make the install files available to you. It might take a couple of days before they reply, but in my experience, they upload it to an FTP-server pretty soon. If enough of us requests older versions of KSP, they might end up having a better backlog of versions available on their homepage or the GOG Galaxy application.

Thank you for the explanation @scimas! I guess that full kOS compatibility might take some time considering Principia is still in development. I'm curious to see how kOS will interact with Principia when fully implemented.

Hi @RizzoTheRat, Cheers Kevin has a pretty cool solution to this kind of problem in the Kerbal Space Programming - Part 6 - Disaster on the Mun! episode of his Kerbal Space Programming YouTube series. Basically, he uses the boot script to make kOS reboot every 10 seconds check for a connection to KSC and then it looks for an update script in the archive, copies it, runs it and deletes it before rebooting again. This way you have to copy/rename the update script in the script folder every time you have new instructions, but it might beat manually uploading the new scripts every time you have new instructions.

The mod Principia changes a lot of thing with its frame of reference and different terminology for delta-v directions. Does this limit what is possible to do with kOS? Is it possible for kOS to create a Principia manoeuvre and execute it? In Principia you will often see multiple apoapsis and periapsis nodes, will kOS be able to make sense of them? I couldn't find anything about Principia in the kOS docs , does this mean that the mod is not supported?

I have a small question on terminology. Principia use different terminology for the delta-v directions (Prograde ==> Tangent etc). My question is: how do you pronounce the words "-tangent", "-normal", and "-binormal"? How would you use them in a sentence? Is it "this manoeuvre is 10 m/s -normal and 20 m/s -tangent" or something else? Anyhow, thank you very much for this fantastic mod. It is a little hard on my potato laptop, but I'm having fun becoming a novice at rendezvous and having to struggle to go to the Mun again. Edit to clarify my question a bit: I'm asking about the "-" part of the words "-tangent", "-normal", and "-binormal". Do you pronounce it "anti tangent", "negative tangent", or something else?

@topaxi It is usually a good idea to upload the log file and save file to a free file sharing site like Dropbox to make it easier for people to find and reproduce the bugs one is experiencing. Please see How to get support for details on finding the log file. It is different depending on your system. A list of all the mods with version numbers might also make the troubleshooting process a lot faster. It might be really tedious to write down 90+ mods, but it saves the people trying to help you a lot of headaches.

@Speedbird52 I'm not sure when RO will be updated for 1.4.4, but it is already ready for use with 1.3.1. You can find it on CKAN. If you want to track some of the mods used in RO and RP-0, you can look at the KSP 1.4 Golden Spreadsheet. If you want help installing mods for RP-0, you can use the KSP 1.3.1 Golden Spreadsheet.

Thank you for you replies @Gargamel and @kerbiloid. It looks like all we need is the kOS community to show some interest and do the work to create the syntax highlighting. Maybe some of the talented people from The kOS EditorTools Github could help with this. It would be really cool if we made this happen!

I'm trying RP-1 and have some problems with Aerobee engines not igniting. This problem is with no issues with test flight failure or ullage that I could see. On two different occasions, on the same save, I ended up with vessels that used to work fine then stop working. The problem is that the Aerobee suddenly stops igniting on a craft that used to work. I inadvertently managed to save the first of them when I recovered the vessel with KCT, attached launch clamps, changed the kOS boot script and saved. The reason I found out that this was a problem with the ship, was because I tried to use the same ship to make the contract before the time ran out. The other vessel got the same problem, and I managed to save the log of the problem occurring (the first log is me trying the ship on a different save). Is this just a strange random occurrence, a problem with my save/install, or a known problem with one of the mods? (I hope this is just me being stupid and missing something obvious) My logs and craft and save files: Ship number one: Craft file Player.log Ship number two (I apologize for some bad words in the log and save game): Savegame Craft file kOS scrips used player.log ================ EDIT ================ I found the problem, and it was me! I am sorry if anybody tried to figure this out, I should have tried it out more. The problem was with my script. And when I tried to test things, I didn't notice that I hadn't turned the thrust on! When I got some sleep and tried again, it worked... I feel stupid, but at least it wasn't a problem with my install.

Thank you all for the response. I know I saved and changed the script file in the script folder, and I have also tried it a couple of times with different scrips and got the same result. Thank you, I tried that and it didn't change the result. Thank you, I tried to insert the debug line. And it also doesn't update when I save the edits to the script. It looks like this might be the case still then. I guess I would have to do something with rebooting or changing filenames to make my script tester.