Search the Community

Like what I do? Want to directly support development? Consider donating via Patreon or Paypal! Set up recurring donations through Patreon ...Or make a one time donation via PayPal DOWNLOADS Spacedock | Github MANUAL | DEVELOPMENT | BUG REPORTS Made by @CobaltWolf, @Jso, @Zorg and @Invaderchaos Massive support from B9PS and SAF provided by @blowfish (Un)official wiki maintained by @Friznit Dependencies (included in download, check for latest versions if you have issues!): B9 Part Switch - Used for fuel switching and for some mesh / texture switching. Community Resource Pack - Primarily used for hydrogen resource. DMagic Science Animate - Used for advanced experiment functionality. NOT THE SAME AS DMAGIC ORBITAL SCIENCE!!! Module Manager - Used for internal patching and adjustments. Simple Adjustable Fairings - used for the new "hard" fairings included from BDB v1.7.0 onwards Deployable Engines - Self explanatory? System Heat - Our new solution for boiloff management Changelog: FAQ What is this mod? BDB adds parts. Lots of parts. Nearly 1000 parts, including launchers, spacecraft, and probes, all in a stockalike style. The focus lies primarily on the US space program up through the Apollo program, though some modern parts exist. They are not perfect replicas, but rather take inspiration directly from existing designs. Care has been taken to research and include pieces for projects that were proposed but never happened, to increase the possibilities available to the player. Parts are made in a lego frame of mind, and screenshots of your unique franken creations are always appreciated! The mod is not recommended for new players, as the mod adds a good deal of clutter to the VAB lists. The mod also adds new standard sizes (such a 0.9375m, 1.5m and 1.875m diameter) of parts in order to more accurately scale to KSP. Now, 1000 parts sounds like it would kill your PC. While the mod certainly is large, the memory overhead is likely lower than you would expect. Care has been taken to ensure the mod is efficient, with methods such as enforcing a strict texel density (a technique I have only used since mid-2017, so the older assets might not be as efficient) and texture atlasing to cram several parts onto each texture sheet. For those familiar with KSP mods, BDB can be considered a stockalike equivalent of FASA, and a US counterpart to Tantares' soviet rockets. The parts are really overpowered! I managed to take a Mercury Hermes to Mercury Moho. The parts in BDB are balanced and scaled against the stock parts. Unfortunately, due to KSP's tiny solar system, that means that the rockets you build will be more powerful than their real world counterparts. For realistic balance, use something like a 2.5x to 3.2x rescale. Scaling can be accomplished via Sigma Dimensions, and scale preset configs are available through Rescale! You could also try the incredibly awesome JNSQ, which comes natively sized at 2.7x scale and works perfectly with BDB! Well, what do I get? Currently, the mod includes nearly 400 parts! A (non-exhaustive!) list is below: I would like to see X, Y, and Z in game! Awesome! I love having people interested in the mod's development. First, check the roadmap to make sure I haven't already planned on making it. If it's on there, it will get done - eventually. Some day. Hopefully. If not, feel free to ask on the thread. Preferably with pictures, or something. Fair warning - I don't have much of an interest in modern rockets, so don't expect to see things like a Falcon 9 or some such in this mod. I also don't plan on covering anything Soviet - Tantares already does a fine job of representing those in a stockalike style. Right now I'm also sort of swamped, with content planned for upwards of the next year! However, if you have something relevant to what I'm currently working on (ie you can't have X rocket without Y part for it) please speak up - I like to be complete! I don't want to download all this, can you split up the mod? I wish it was that easy! At this point, splitting up the mod would be a good deal of work, as well as additional overhead to maintain. Additionally, despite the frequency this gets asked, nobody seems to agree on how the mod should be split up! However, the mod is easily prunable. Deleting folders inside Gamedata/Bluedog_DB/Parts/ will delete that part family without breaking other parts of the mod. For finer pruning, mods like Janitor's Closet can be used to remove parts from within the game. There's something wrong with the CKAN configs for BDB! Myself and the other authors do not maintain the CKAN configs for this mod. @linuxgurugamer has graciously volunteered (I think) to look into any issues pertaining to this mod on CKAN. The Apollo Launch Escape System wobbles. Right click on the LES and autostrut it to the heaviest part. If you don't have a button for autostruts, go into settings and turn on "advanced tweakables". The BDB science experiments don't work. Make sure you have DMagicScienceAnimate installed. All the dependencies are included in the download, so make sure you put everything in the GameData folder you downloaded into your KSP's GameData. The Saturn and Centaur engines don't work. Make sure you have CommunityResourcePack installed. All the dependencies are included in the download, so make sure you put everything in the GameData folder you downloaded into your KSP's GameData. I don't have the LDC/Atlas V/other cool parts people are showing off in the thread. Those parts are still in development. If you want them, download the latest dev version. Warning! These are unstable, unfinished, unbalanced, and will probably break your saves! What parts go to which rocket? They all have weird names, and I'm so confused. The parts all have kerbalized names, like the planets in KSP. There's a list of the real names, and how to build real rockets, in the Wiki/Manual. In addition, there's an optional real names config in the `BD_Extras (No Warranty)` folder, though it might not cover all the latest parts. Type tags into part list search box to narrow down the list to related parts. Useful tags * Mercury, Hermes, Redstone, Etoh * Gemini, Leo (Gemini gets you junk, use Leo) * Apollo, Kane * Skylab * Atlas, Bossart, Muo * Titan, Prometheus * Saturn, Sarnus * S1, S1C, S1E, S2, S4, S4B, S4C (Saturn V is very easy to build using stage tags S4B, S2, S1C) * many more Mercury-Redstone/Hermes-Etoh can't reach space! Your TWR is too low. Empty the upper checkered tank - which, in real life, was actually structural with some avionics. Or add more boosters. Your choice. Mercury Redstone Flight Plan: 1. Liftoff (maintain 100% throttle throughout flight). 2. Pitch over eastward about 0.75 degrees per second. 3. Stop pitchover at 45 degrees pitch (10,000 - 15,000 meters height). 4. Hold attitude to burnout. 5. Jettison tower. 6. Separate spacecraft from Redstone. 7. Turn retrograde. 8. Do stuff. 9. Apogee (hopefully 100+ km). 10. Fire retro motor (optional), jettison retro motor, fall back down (not optional). 11. Deploy parachute at 3000 meters. 12. Ticker tape parade (assuming step 11 went well). Compatibility: Credits: Licensing: #RealThrustHasCurves

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i5-10600k | GPU: RTX 3080 | RAM: 32GB DDR4-3600 Severity: None Frequency: Always Issue: There is a typo in the part description of the T-1 "Dart". In the first sentence, it says There is just a space between C7 and s, which isn't proper syntax. Expectation: There should be an apostrophe connecting C7 and s, i.e., C7's. Steps to Reproduce: In the VAB (or R&D Center), hover over the T-1 "Dart". Press Shift to expand the part description. Read the first sentence. Included Attachments:

The Third Great Number War: The Long Haul! I. Important Notice As per instructions from the moderators: there is to be no role play elements to the battle. Simple exclamations that we are getting ahead or falling behind, or saying you need help are fine, but no suggestion that you are part of an army or fantasy faction in some epic confrontation. It is more or less attempting to reach a goal line and passing to another with the same goal, or getting intercepted by someone going the other way. II. Rules A. Definitions Current Number (CN): the number around which the game revolves. At the beginning of each round, it is set to 0. Round (or Battle): between two resets of the CN. Ninja'd: if, while you are typing your post, someone else posts a move, which makes yours invalid, you have been ninja'd. Most of the time, you won't see it until you refresh the page. This then causes you to have to edit your post to correct for the new number. It is then not unheard of for someone to post before you have had a chance to edit your post, and so a cascade effect happens. To make clear your original intent in the hopes of lessening this, see under "Posts". B. Goal The goal is for the Positive Guard to reach ±70. Everytime this happens, the current round ends, a new one is started, and the CN is reset to 0 in the next post. If the CN is 70, it is a Positive victory. If it is -70, it is a Negative victory. C. Posts Every valid post must contain at least a number, the CN (when you made the post, and prefaced by a letter, see below). Additionally, for your post to be valid: You must wait at least five minutes between two posts. This is to minimise spam and ninja posting. Any other player must have posted a valid post between your last post and your new post. In other words, you can't make two posts in a row. The CN in your post must be the one of the previous post, plus or minus 1 (one). No floating-point or decimal (etc.) shenanigans, please. "One" is neither 0.5 nor 32. Your number must have a preface letter before it, which is one of the following. By doing this, a player can see what you intended to put, and post knowing what it would be if you had not been ninja'd. Positive Guard: if you are trying to get the CN to +70 (Positive). Negative Mercenaries: if you are trying to get the CN to -70 (Negative). The Neutralists: if your goal is to get the CN to zero (Neutralist). Note: You do not win if you get the counter to zero; only the positives and negatives can win. Chaotic People: if you are chaotic and just post as you feel, but your post's CN must only be 1 different from the last post's. The addition or the subtraction of the number 1. (Chaotic) III. History of the Third Great Number War Thanks to @Nazalassa, who went through every post in this thread (up to a certain point ago), and wrote down their CN, we have this graph, which shows the evolution of the CN across this thread. The horizontal scale is the CN, and the vertical scale is the post number (since the beginning of the thread). Here's the a Codeberg with Nazalassa's work: https://codeberg.org/Nazalassa/numberwar-graphs Total posts: 21250 (as of page 850.) Battles: 38 Shortest: #35: 19044-19156 [len: 113] -> Positive Longest: #18: 10644-12355 [len: 1712] -> Negative Positive wins: 19 Negative wins: 18 Times zero reached (from ±1): 742 Entire graph below: Old version of the rules below:

-Solved- By opening the textures is a program that can edit .dds images, switch the compression to BC3 / DXT5 I recently downloaded the mod Silverwolf Aerospace and its part textures are nearly entirely grey, excluding windows and small details, i'm wondering how to fix this and if anyone can help with this.

The Comprehensive Colony Communications Archive (CCCA) Hello everyone! I've been seeing a lot of people confused about how colonies will actually work lately. We have received a lot of info on this over the years, but it's pretty spread out. That's why i took it upon myself to go through every Feature Video, Show and Tell, AMA, Dev Update/Blog/Chat and Interview and compile every bit of information we have about the KSP2 Colonies Milestone update, along with where and when it was mentioned. Do keep in mind that some of this info is years old at this point and may not be entirely up-to-date with the developers plans and goals anymore. Props to the KSP2 Knowledge Repository post, which served as a great independant resource to make sure i didnt miss anything. Thanks also goes out to @Spicatfor helping me go through the youtube interviews. If i did miss anything, feel free to let me know! I've highlighted the sections about (planned) core colony functionality and the features that are expected to ship with the Colonies Milestone. Do keep in mind that some of the core functionality (such as Resources) wont be in the initial release yet and will come with later Milestones. This post is also available as a PDF at the bottom of this page for easier reading, for those who prefer that. Enjoy! 1. Feature Videos · Colonies will have exotic fuel factories, such as metallic hydrogen ( + concept art) Kerbal Space Program 2: Episode 1 - Next Gen Tech [Feb 20, 2020] · Pre-alpha captures of various colonies and stations Kerbal Space Program 2: Episode 1.5 - Work From Home Developer Update [Jun 24, 2020] · More pre-alpha captures Kerbal Space Program 2 - Feature Videos Teaser [Oct 23, 2020] Kerbal Space Program 2: Episode 2 – The Kerbals [Dec 21, 2020] 2. Dev Diaries · Colonies as one of the KSP2 Design Pillars (exploring next-gen space program concepts): - new features based on inspiration from expectations and the real world - but not on the level of complexity that dedicated colony builders have - minimizing micromanagement - colonies in function of serving ‘rocket gameplay’ How Colonies will work gameplay-wise: - Establishing a colony by launching inflatable modules on a standard rocket - Fuel is synthesized in-situ by this colony to refuel rocket> - Players bring in more resources to make colony self-sufficient - Colony grows to allow player to build and fly rockets from this new location - Orbital Drydocks and Mining Colonies are mentioned - Rearranging modules of a colony is mentioned - commitment to keep Colonies open to the modding community is made Developer Insights #3 – KSP2 Design Pillars [Apr 26, 2020] · Mention of being able to dock at each others colonies in multiplayer Developer Insights #4 – KSP2 Engineering [Jun 12, 2020] · Confirmation that Vehicle Assembly and Colony Assembly Build Interface (also known as BAE; Building Assembly Editor) will use same camera interactions Developer Insights #7 – KSP 2 UX Architects [Nov 27, 2020] · Deep technical dive into how Resource Flow will function, but no specific mention of their relation to Colonies Developer Insights #13 – KSP2 Resource System [Feb 25, 2022] · Inspiration for Colony parts is drawn from concept studies, physics treatises and hypothetical engineering trades. (No examples of such studies is listed) Also reveals new ion plasma engine which should be added along with radiators (as per Nertea), thus with Colonies (see Dev Insights #21). Developer Insights #14 - Part Creation [Jun 27, 2022] Nertea Talking About New Ion Engine [Aug 17, 2023] · Pre-Alpha Sneak Peak of a Large-size Pulsed Fission Drive (based on Project Orion). Likely to ship with the Colonies update (see Nate's AMA) Developer Insights #15 - Writing for Kerbal Space Program [Aug 30, 2022] · Connection between the Heating system and Colonies - core areas of heat management for colonies: heat-producing/removing parts & environmental heat sources/sinks (e.g. An ocean) - Environment will directly impact efficiency of Mining Colonies; being on a cold planet or being in the shadow of a mountain will result in ‘a bonus’, being on a lava planet will ‘pose a challenge’ - not getting rid of heat may result in nuclear meltdown - engines, drills, factories, and power generators listed as possible heat-generating parts for both Colonies and Vessels - atmospheres, oceans, sunlight and proximity/contact to surface features listed as possible environmental heat sources/sinks - pointing a torch drive at a colony will result in consequences - some parts/modules will be more prone to heating than others - mentions there will be ‘tools’ to understand and manage heating on Colonies and Vessels - heating model for parts and colonies will be based on average heat flux (incoming/generated heat on a part – outgoing heat = resultant heating on that part) - Radiators and heat sinks will pull heat from all parts - Thermal Flux and Extraction/Production (using Delivery Routes) calculations will always run in the background even when the colony is not being observed - the Colonies Milestone will introduce basic part heat management, basic radiators and thermal planning - More part heat managment, more radiators, exotic environments and more planning tools are planned to arrive later with the Insterstellar Milestone Developer Insights #21 - Rockets' Red Glare [Jul 23, 2023] 3. Show and Tells · Power generation modules for colonies - will progress from compact fission reactors to giant fusion tokamaks to next-generation Z-pinch fusion reactors Show and Tell - New power generation modules for colonies! [Feb 5, 2021] · Station and Colony Part Models: - Orbital Launch Clamp - Geothermal Power Generator - Colony Roads/Runways - Deep Resource Scanner - Wind turbine Show and Tell - Creating New Parts [Jun 11, 2021] · Colony Fuel Factories: From smallest to largest: Methalox Fuel Factory, Monopropellant Fuel Factory, Xenon Fuel Factory, Helium-3 Fuel Factory, and Metallic Hydrogen Fuel Factory Show and Tell - Colony fuel factories [Feb 19, 2021] · M-sized Bi-modal, extendable nozzle afterburning nuclear engine: NERV-US Will possibly ship with Colonies, as this engine has been functional but hidden (in its non-afterburning mode only) in the game since release. Appeared in an earlier Show and Tell as the ‘LANTR’. May be waiting on Part Heat Generation. Show and Tell - NERV-US [Oct 1, 2021] Show and Tell - New LANTR engine [Jun 25, 2021] · Procedural Radiators – Unconfirmed Show and Tell - Procedural Radiators [Mar 25, 2022] 4. AMAs · AMA Nate Simpson [Mar 24, 2023] 3/24 Discord AMA Answers Ask Me A Few More Things Q: Can you give any more detail about how the automated "trade routes" are going to work? Will we see ships automatically landing on / taking off from the launchpad or will it be more of a in-the-background kind of thing? How will the game handle changing delta-v requirements due to different planetary alignments? A: For delivery routes, we have clear steps. First implementation, crediting/debiting resources to vehicles and colonies based on duration. Second implementation might take into account launch windows and such. Someday, would be very cool to see vehicles coming and going. Not a promise, but a long-term aspiration. Q: Will certain resources needed for colony construction be planet/biome specific? A: The diversity of resources is what's going to make exploration mode so fun. Compared to KSP1 which was very self-directed (take temperatures, etc.), when there is a unique resource somewhere that gates your access to some category of parts/features - wow it totally changes the game. It gives you something material literally material, yeah the interplanetary/interstellar progression will really POP once you're able to dig up a specific thing that gives you a specific ability. Q: For the far off colonization update. How will buildings work? Will we assemble them ourselves by landing modules (or making them on site) and moving them into position, or will it be more of a prefabricated type of building system? A: We have a inflatable module that you put on a vehicle and once you deploy it - it's basically like setting up a camping site. It sets up a VAB-like interface. Using that and other modules, you can use resources to add even more modules to the colonies. There will be attach nodes and it'll be very similar to creating a vehicle. Also the same thing applies to orbital colonies. Q: Orbital colonies have been mentioned. Will they have a set orbit once the first part has been built, or will they be able to move with engines like other spacecraft? A: They can be moved and crashed, yes. Q: How useful will orbital construction be and how awesome are the colonies? A: Completely critical to the interstellar progression. You can't make a interstellar vehicle in a gravity well. Someone will definitely prove me wrong about that one day. Q: … Will players be able to share colony buildings (Once that comes out) and create? A: …So there will be the asynchronous progression - people dropping in and out of the server over time but slowly building up resources and sharing delivery routes between colonies. … Q: Will there more colony parts than what shown in the trailers? A: yes. Q: What kind of size range can we expect with colonies? Will all colonies be roughly the same size, or will we be able to have small 1-2 launch research colonies along with our gigantic industrial ones? Will there be any upper size limit? A: There's no plan for an enforced upper-size limit. It'll be similar to vehicles, it's made of parts - we want people to make it as large as they want. Obviously not all computers can handle massive builds, so there will probably be a player-dependent fps-based size limit. Q: "When we'll see other exotic fuel types like metallic hydrogen? Will they be added alongside some big update like colonies or will they be added before?" A: We will be bringing in new engine and fuel types across multiple updates, generally as they become instrumental to the progression. I suspect nuclear pulse will be next up, as it opens up the interplanetary progression quite nicely and is a good supplement to colony building. … Q: Will be possible to alter the surface on the planets? Like dig a pit or flatten an area for a colony? A: There are no current plans to do this - … - So yeah, we’ll keep talking about this. · AMA Shana Markham [Apr 20, 2023] Discord AMA 2 - Design Director Shana Markham Answers Q: Most players don't know how do reentry and land precisely. How will you teach players to land precisely near colony to deliver resources there, or will we get instruments to predict landing site for delivery paths? A: …Certainly when colonies comes out, advanced landings will be extremely useful. One of our writers (Jim Peck) did a knowledge-share internally about precision landings, and that taught us a lot about how in-depth that topic can be - and we have to figure out how to distill that down to make it approachable for new players. Q: How will the resources be distributed across so many planets in order to give the player a reason to explore every world? If resources aren't the catalyst for exploration, how else do plan on motivating exploration? A: … we want to look at the various resources on a planet and how it plays into your space program. Especially with colonies and exploration, you may want to build a mining colony - but perhaps it's really far away and it's annoying to get to. So instead you go somewhere else and build an additional orbital colony to help build resource pathways. Q: In the previous AMA it got said that colonies will be built using resources, but the resource gathering update comes after the colonies one, how will that work? A: Remember that question about the roadmap? This is one of the outcomes when everything is building on top of each other.. We wanted to make sure exploration is about exploration. Q: Will colonies feature automation gameplay (with-in the colony, so not the delivery route system)? It can look something like: 1) Resource extractor building mines a raw resource, 2) Resource refinery building makes a useable material out of it, 3) Assembly A: …We want to make sure automation is implemented to make sure the part of the game that is really important to us, rockets, continues to stay the main gameplay loop. Q: Will adding to orbital colonies be similar to how we already make space stations etc. or how will that work differently? A: Orbital colonies would follow a similar flow to terrestrial colonies and have the same toolset. · AMA Kristina Ness [Jun 30, 2023] AMA 3 - Art Director Kristina Ness Answers Q: Have the assets for the game been done? What does the art team do after the assets are made? A: Yes. The art team is actually, as is with most games, the art team is ahead…. our 3D artists right now are working on colony parts. All the science parts are already done and ready to go and they're all lined up. And so, they're onward to colony parts. (as of June 30th, 2023) Q: Will Kerbals be different colors based on what planets they originate from when colonies are introduced? A: That's a very fun idea. I have my own head canon about Kerbal colors. And we'll see. We'll see if that becomes canon. Q: When can we expect to see crew modules which require animations such as gravity rings, especially ones with cool deployment methods? A: Colonies!! I actually just saw a gif of a module very similar to what you are describing that I hope we can share soon. · AMA Chris Adderley (aka Nertea) [Aug 18, 2023] KSP2 AMA Series - Chris "Nertea" Adderley - Answers/Transcript Q: When colonies are implemented, will heat be required for habitation modules in colder environments? A: Not in the current design. We're mostly focusing on having players understand overheating as a concern rather than under-heating. Q: How will the "rotational" artificial gravity ring part showcased in the teasers and trailers work? Will we have multiple iterations of varying sizes? A: We're not really looking at specifically simulating different gravity levels in the game right now. It's not really part of our plans, but we do want to have, at least for colonies, different sizes of gravity ring, and not only different sizes, but different roles. A lot of different things you can put into gravity ring and a lot of different interesting gameplay you can build out of that. And that's a lot of different things you can put into gravity ring and a lot of other things you can build out of that. And that's all I'll say about that. Q: How is the colonies stuff going, there's been some recent concern on whether launching rockets will be free in science. If so, will that be an issue for progression? A: We are effectively designing our progression system in such a way that that's not an issue. I should clarify that as we're going through our milestones, the science milestone is going to be more similar to the science mode from KSP1. So you didn't really have cash in that mode in KSP1. So we're working within the same constraints in terms of that. In the far future when we have resources and things, we're often taking the approach that like, we want players to feel like they want to, they're able to do a lot of stuff from the KSC and from colonies. So I'm not gonna say launching rockets will be free. There's always going to be a cost associated with a rocket, but the amount of various resources that you might have access to at the KSC at different places is going to control what you can launch when. Q: I got the impression that there was going to be the potential for vessels/stations with truly massive part counts… is this still going to be a thing eventually, at least by 1.0? A: This is a core goal that we have in our game. It's like we need to scale things….We're gonna have a specific [performance] target for colonies, a specific target for interstellar, and then a specific target as we go towards 1.0. So the goal is to deliver more parts per ship, more parts per save, more ships per save, to make it so that you can truly have a curvil interstellar civilization. Q: What are your thoughts on greenhouses and simple life support with snacks for example? How do you see conveying that colonies are both real places where kerbals live and 'working machines' much the way vessels are? A: …We have some things in the works around Colonies that ape some of the ‘results’ of life support, which I hope will get at the idea of colonies being a little more kerbal-involved than just plunking Kerbals in a command part. Q: As a side question, stations and bases. Are these going to have something of a real use this time around, given that stations were limited to more or less just fuel depots in KSP1. I'm thinking more along the lines of long term research projects, with big pay-off for significant durations of time. Is there some sort of requirement to resupply the stations, perhaps required crew rotation, stuff like that? A: The progression we want to deliver for bases and stations mirrors IRL conceptions about how these things should work. You will start out with outposts that have limited utility – let’s call that KSP1-like. Fuel depots, maybe comms relays, etc. As you progress through the tech tree, you’ll get access to stuff that provides them with greater utility. That’s shipyards and docks, fuel factories, launch pads, etc. Eventually you’ll get the biggest parts, which are mostly focused on giving you the full capabilities of the KSC at a colony. A core piece of the utility in my mind comes with resource gathering (which is a ways off in the roadmap,) when the specific positioning and configuration of a colony becomes really important. Placing a colony with good access to progression-related resources and having easy access to heat management/power sources will allow you to build specific functions and cool vibes into each colony. Crew rotations and resupply are not currently something we would want to enforce. I hope that when we get resources and delivery routes fully operational though, that this is something modders will hit really hard because the framework of stuff like delivery routes will be there. 5. Interviews and Dev Chats · Colony parts will start appearing in Tier 4 of the tech tree and continue into Tier 5 Science and Tech Tree - KSP 2 Dev Chats [Nov 30, 2023] · ShadowZone Interviews Nate Simpson (2019) KSP 2 Developer on Multiplayer: "I Never Heard People Laugh So Hard" [Sep 6, 2019] - Base Assembly Editor to build Colonies similar to the VAB for craft - Colonies will use the same physics system as craft, so it will fall if you build too tall · Scott Manley Interviews Nate Simpson (2019) Kerbal Space Program 2 Developer Answers Important Questions [Sep 2, 2019] - Early Stage: Bring modular component that you build on site, inflatable module - When population grows you unlock some ISRU capabilities to unlock more permanent modules · PC Gamer Article with Developer Interview (2020) Space Odyssey: Our first big look at Kerbal Space Program 2 [Jul 1, 2020] - 'Boom Events' are mentioned as a player-initiated event that will increase colony population "through a method we will not describe" - Boom events will happen by making discoveries and unlocking new technologies, and have a variety of effects - Colony Nursery module is mentioned as an example, where a Boom Event will result in the creation of new colonists - Colonies will underperform when they run out of Power or Food - First time Food is mentioned! · PC Gamer Interview (2022) Kerbal Space Program 2 full interview PC Gaming Show 2023 Preview [Nov 23, 2022] - Use local resources to build colonies - Use local resources to build craft at those colonies - Orbital Construction will happen in a ‘sort of open space’ - Delivery routes to automatize a task -> build a resource extracting rover that brings resource to the colony. after doing it once, you can make a repetitive delivery so you continue to receive that resources · Shacknews Interviews Interview (2021) Kerbal Space Program 2 - Interview With Creative Director Nate Simpson [Jun 24, 2021] - As a colony grows, it will eventually become self-sufficient and not need external resource deliveries to expand anymore · Shacknews Interviews Interview (2023) https://www.youtube.com/watch?v=easPDj-o06o&t=358s [May 2, 2023] - There will be between 200 to 300 colony parts · GrunfWorks Interviews Nate Simpson (2024) KSP 2's Creative Director talks Colonies - Interview with Nate Simpson [Mar 1, 2024] - Colonies will come with new kinds of science collection - Colonies will be placeable anywhere - ‘dozens’ of new colony parts - The Colonies Experience will be ‘whole’ at its initial release despite resources coming later, but will evolve as resources and delivery routes come online later 6. Sneak Peaks · An Orbital Colony Around Duna & Jool (video of rotating rings/arms in link) Colonies Sneakpeeks [Mar 15, 2024] This Document as a PDF: CCCA.pdf

1. Adding fins to the rear of small rockets can improve aerodynamic stability during early parts of flight. This may not be needed if you have engines with a high degree of gimbling instead. Most but not all rocket engines in KSP have quite large amounts of gimbling (this is shown in the right hand side of the part menu in the VAB) Adding to this, although modded - I found taller/longer rockets to fly much, much nicer than short and stocky ones. Using cryogenic engines, you build very tall for the same deltaV/mass and they... you let go of SAS and naturally do a gravity turn and it's beautiful. Is there a way you could make your rocket taller without making it heavier? 2. On the flipside, payload. Make sure your payload is not much more wider than the rocket underneath it. A super wide fairing will introduce more lift than the fins at the rear and make you flip out like crazy. If you can keep your fairings relatively straight, you're good. Slightly flared out (with symmetry on bottom and top ideally) also works but... don't make it too wide. This too wide is sth I ran into a lot during my early lander designs and struggled horribly because of it. Something that can help you there is knowing you can attach fairings to rocket parts. Like, rockomax tank, 2.5m fairing, science junior/random junk, heat shield and pod. You attach the fairing to the pod's bottom rather than cover it as well.

I wonder how many years it will take for the game to reach the level of playability of the first part? I hope in three years the second part will be fully playable?

This challenge was continued with permission from the previous thread manager @sdj64 LINK to the old Jool-5 thread There are over forty-five pages of entries and discussion, so look and see what made it and what didn't LINK to the older Jool-5 thread. There are hundreds of pages of entries and discussion, so look at it to see what worked and what didn't! CHALLENGE RULES Given the scale of this challenge, everyone who completes the mission successfully gets a spot in the hall of fame. 1. No cheating, including the stock debug menu cheats, HyperEdit, kraken drives, or file editing. HyperEdit is allowed for testing but get rid of that H when you fly the real mission! 2. No part-clipping of functional parts (fuel tanks, batteries, crew pods, engines, science parts, SAS) into each other. It is okay to clip structural and non-functional parts, wings, and heat shields. 3. Any number of launches are allowed to assemble the ship in low Kerbin orbit (preferably below 100km, not a hard ceiling though, but do try to stay around or below 100km at most). All launches must be flown! 4. There's funding for one main ship only so all the crew, lander(s) and other stuff has to go to Jool as one big ship. Once the ship leaves LKO, it cannot obtain more parts or fuel unless it mines and refines the fuel itself. The ship can separate once in Jool's SOI. 5. Kerbals must be in a pod or cabin (no seats) for the interplanetary journey. Seats are okay for landing and flying within the Jool system. 6. One refueling mission is allowed in the Jool system if you run out of fuel, unless your ship uses ISRU. The refueling mission can only transfer resources, not parts, to your Jool 5 craft. This mission must actually be flown! 7. On all of the landings, the Kerbal must be able to get out and walk (or swim!) around on the surface. Make sure your ladders work! 8. Use Normal difficulty or harder, except, any ComNet settings are allowed including turning it off completely. 9. All the Kerbals have to arrive back to Kerbin surface at the end of the mission, happy and alive. You are allowed to optionally send up a craft to return them from LKO. 10. Mods / DLC: STOCK: only mods which do not add parts and do not change physics are allowed. This includes any informational, planning, visual, autopilot, or automatic functions. DLC: Any and all DLC made for Kerbal Space Program are allowed. MODDED: Use of most parts mods and certain game mechanics mods are allowed. You NO LONGER HAVE TO ASK if your favorite part pack is allowed! Some parts mods are prohibited. Please see below. Specific Mods: ENTRY SUBMISSION RULES 11. Submit your challenge as an imgur album, with good captions and descriptions, as a video or series of videos, or as a thread in Mission Reports. 12. Pictures or it didn't happen! Please keep the resources tab open, as well as show the informative windows from Mechjeb or KER if you use them. Take a picture of every important moment, including transfers, dockings, landings, stagings, and refuelings. For Jeb's Level, also take pictures of the science screen when you recover your craft. Alternatively, video submissions are a great way to show everyone your mission as well. These will help future participants to see exactly how you accomplished each part! CHALLENGE LEVELS 1ST LEVEL: one Kerbonaut lands on all the moons and come back safely. Low mass and low cost and low parts sub-challenges: with stock parts and physics, how low can you go and still accomplish the mission? NOTE: Low cost submissions may not utilize ISRU, or a negative cost would be possible. (Thanks @jinnantonix!) 2ND LEVEL: two or more Kerbonauts land together on all the moons together and come back safely. 3RD LEVEL: There's not enough time left for training one crew member to be an expert on all of the moons, so five Kerbonauts must go to the mission, with at least one unique Kerbonaut landing on each moon. JEBEDIAH'S LEVEL: collect as much Science as possible! Your score is the number of science points from the Jool system only, returned to Kerbin (not transmitted). Only stock experiments count for this! To score, take pictures of the science screen(s) when you recover the data. Otherwise, the rules are the same as 3rd Level. GATECRASHER / HONORARY MENTIONS: Missions completed the mission in spirit but didn't meet every requirement. ISRU: Use of ISRU will get a note ISRU on the entry description in the hall of fame. This includes stock ore harvesting and converting as well as mods such as Kethane and Karbonite. ISRU is allowed for any level of completion. GRAND TOUR: Not officially part of the challenge, but landing on all planets and moons in the Kerbol system in one mission will earn a GRAND TOUR note and the everlasting praise of all of Kerbal kind. Rule 4 is waived, but any Kerbals on the mission cannot return to Kerbin in between any landings and you still must follow the other rules. Additional optional information to help others see how the mission was accomplished: - Which game versions did you use? - What mods did you use, if any? - How many Kerbals are on the mission? - How many launches were needed to start your mission from Kerbin? - How much did your mission cost? - Did you needed a refueling mission? - Did you bring additional stuff like satellites, rovers, etc? - Share the delta-V information too, if you tracked it! ------------------------------------------------------------------------------------------------------------------------------ Well, now this big announcement is in the Kerbal News, all the public is excited about this mission and even the Government is watching! Now it's up to you, to the engineers and to the bravest and craziest Kerbonauts of all time! Completion Badge: Anyone who has finished the challenge can add this badge to their signature. The Low Mass Feather badge is available for entries in the low mass sub challenge. Hall of Fame 1st Level- - @Laie Video here. Used a smaller-than-you'd-expect rocket with a dedicated Tylo lander and a spaceplane shell that encloses the Vall-Bop-Pol lander to make the Laythe lander. A very well done mission with a great video. - @Stratzenblitz75 Video here. Used a completely reusable mission involving a tiny mothership which orbited Tylo and tiny landers that explored the system. I should also point out that no nuclear engines or ions were used in the mission. Truly impressive. - @Ultimate Steve Videos here and here. Used a single launch in career mode sending Val to many places in the system including Vall. Very impressive how quickly the mission was thrown together and carried out. - @IncongruousGoat Album here. A simple, single launch Jool 5 mission that only uses 42 parts! Very well optimized and well done. Good job! - @chargan ISRU Gif here. Used an ISRU shuttle and hopped from Kerbin, to the Mün, to the Joolian moons, to Duna, and finished it off with a glorious vertical landing at the KSC. Excellent job! - @GRS Album here. Used a massive, creatively named mothersheep that carried landers for Laythe and Tylo, landing on Vall and Bop (AND DRES!) by itself. As an added bonus, the lonely Dres was even visited, that doesn't happen very often. Amazing job! - @Challyss Album here. Used a brute force 5 meter launch booster with two 5 meter side boosters. Once in LKO used a vector-power stage to boost to an elliptical orbit, then used a rhino powered mothership to go to Jool, where it completed the mission. - @5thHorseman Videos here. Used a single launch to send three Kerbals to the Jool system, where the ship parked in an elliptical Tylo orbit. From there a tug took the landers to their respective moons where they *wait for it* landed. The ship then fired all three Kerbals home safely. An amazing mission and equally amazing videos. - @Xurkitree Grand Tour Thread here. A surprisingly small mission that not only landed on all the Jool moons, but also every other planet and moon in the system. The mission sent a craft out to Eeloo, which landed and returned to Jool before heading home. Once in orbit Derton was picked up by a recovery rocket and landed safely back on Kerbin. Outstanding. ISRU Video here. I don't even know where to start, Xurkitree didn't just do a Jool 5 in this mission, they did it twice. A large SSTO ISRU craft launched and refueled on Minmus before gravity assisting its way to Jool where it completed the landings and then returned to Kerbin, WHERE IT RELAUNCHED and then detached a small non-ISRU craft which carried out the landings again. A fun note was when the Laythe lander landed by computer control while the Kerbal parachuted down. Great job on your fourth Jool 5 submission! - @dvader Album here. A single launch using only chemical engines. Used several gravity assists to make the trip to Jool cheaper in terms of delta-v. Used a small but capable plane for Laythe, and a donut lander for the other moons (with extra fuel for Tylo and Vall.) Overall a very optimized mission, complete with a near KSC landing. - @fulgur Album here. A very small and well optimized mission with a smaller-than-you'd-expect mothership. Ions were used to scoot Jeb and Vall about the system to the various moons, and then left as the small mothership made its way home, getting into Kerbin orbit with only forty m/s of delta-v remaining. (Talk about close margins!) The crew were returned safely by an Aether SSTO. - @Pro100kerbonaut ISRU Mission report here. Used an SSTO spaceplane to go to Minmus to refuel, then flew off to Jool. This mission is the most impressive in how it handled the Tylo landing. Not only was the landing done using the SSTO, but it came directly from Vall without refueling at Bop or Pol. The landings were all completed flawlessly, but was destroyed in a crash landing back on Kerbin. The pilot survived though, and any landing you can walk away from... - @dnbattley Album here. A direct ascent mission to all five moons, starting with Pol and Bop, then Vall, Tylo, and finally Laythe. The tensions on this mission were very high, as Jeb began his Tylo descent on a NERVA powered craft with a TWR of .9, managing to get it above 1 just in time to pull off the landing. From there Jeb flew to Laythe where he somehow missed the ocean (this might be a KSP first) and used the craft's jets to push it into the water for an ocean launch. After struggling back into orbit, Jeb flew by Tylo back to Kerbin, using a Duna aerogravity assist to get the right trajectory (ARE YOU SERIOUS?) Upon returning to Kerbin he was able to sneak in a Minmus landing. This mission is without a doubt one of the more Kerbal ones submitted, complete with Jeb gliding the final stage down to Kerbin with his EVA chute. - @EveMaster Grand Tour, ISRU Thread here. Additional album here. EveMaster managed to complete the Jool 5 challenge with an ISRU craft, utilizing the power of two mammoth engines and a detachable spaceplane. Also went the extra few million miles and completed a grand tour! Both Bob and Jeb were on this mission, however Bill stayed behind on Eve, so only Jeb is being considered for this entry. Regardless, an excellently executed mission. - @ManEatingApe, @Jacke, @dvader, @Muetdhiver, @Rakaydos, and @Pds314 Mission thread here. What these users have completed is the first community Jool 5 mission for this specific thread, possibly the first ever. Furthermore, this mission was done in a 'caveman' style approach, meaning no maneuver nodes, tier one buildings, and launch mass restrictions. These restraints meant the main ship was built over multiple launches. The landings were carried out by a plane and three identical landers, which carried Jeb to, around, and back to Kerbin from the Jool system with excruciating precision. I highly suggest checking out this mission's thread, it's one of a kind! - @Space Nerd Album here. Using a long nuclear mothership, Jeb and Malvis conquered the Jool system in a surprisingly easy manner. An off-center Bop/Pol lander was docked onto the side of the mothership, leading to one of the more interesting mothership designs. Jeb took Laythe, Tylo, and Vall, and Malvis handled Bop and Pol. Once all the landings were done, they flew back to Kerbin and used a 10 meter heat shield to slow down and splashed into the ocean. - @ralanboyle Video here. Using a single brute force launch, a main station of sorts was put into Jool orbit,. From there a Laythe-plane was released, and upon returning from Laythe, a lander/fuel tank combo (and an extra part for Tylo) took on Tylo, then Vall, then Bop, then Pol. They forgot to put a flag on Pol, but who cares. Also, the lander was able to return to Kerbin all by itself. Quite the capable craft I'd say. The mission is edited into a very nice video, and I suggest giving it a watch if you've got the time. - @Carbonjvd Album here. Using the incredibly stylish IPV Excelsior spacecraft, Tridous Kerman flew to Minmus to refuel, where she picked up two more crew members in Minmus orbit. From there they flew to Jool, where they refueled at Bop. After the tanks were full, they hopped to Pol, then Tylo, then Bop again, then Vall. From Vall the crew hopped back to Bop for more refueling, then flew to Laythe. After converting stored ore into liquid fuel, the crew touched down on an island, then (you guessed it) flew back to Bop! (for more fuel) From this final Bop landing, the Excelsior returned to Minmus where it all began, then safely touched down on Kerbin. A stylish landing for a stylish craft. - @camacju Grand Tour. Album here. This mission is impressive as it not only visited the five moons of Jool, but also every other landable surface in the Kerbol System. The Jool portion of this mission was completed after the mothership completed the Eve portion, then used gravity assists to get to Jool. A Tylo assist put the ship on course to aerobrake at Laythe, and after landing on Laythe the lander was then reused for Tylo. The other moons were completed using a smaller lander, and the brave Kerbonaut landed back at Kerbin after quite an exciting trip. Video here. A very well edited video of a Jool 5 mission which used only liquid fuel! Launching from the runway as a spaceplane, the craft flew up before staging its rapier engines and continuing to orbit on nerva-power. The Laythe landing was done using a smaller spaceplane, and the rest of the landings were done using a very impressive lander which used only 1 nerv engine to land on all the other moons, including Tylo! The lander also served as a trip home and as a heat shield so that the brave kerbonaut could parachute to safety. This mission is beautifully summed up in the video link, and I highly suggest checking it out. A truly unique mission! Video here. Another liquid fuel only mission! This one utilized multiple relaunches of the same spaceplane to put multiple fuel tankers in orbit. From there, the craft departed for Jool after some gravity assists and once again demonstrated the unusual, difficult, and impressive use of a nerv-powered Tylo lander. The video this mission was edited into is nice and tidy as well, and I suggest watching so you can see all the work that went into it. Video here. And yet another Jool 5 mission, but this time with only one engine! A cargo spaceplane with a single rapier made multiple launches to place several fuel tankers into orbit before flying a gravity-assist-utilizing course to Jool. Once in Jool space, the Laythe landing was conducted first, and then the plane ditched its outer shell so that just the rapier engine and a few fuel tanks remained. The craft then docked to a fuel module in orbit and flew to Vall, landed, then went to Tylo where a dedicated fuel drop-tank was used with what I'll dub "backflip staging". From there the Pol and Bop landings were done, with fuel to spare. After a fiery return to Kerbin, the brave Kerbonaut, Wildard, paraglided safely into the ocean. I recommend giving this video a watch, because it's short, to the point, and an amazing display of Kerbal engineering. Grand Tour. Video here. This mission is truly a record breaker, as not only was it a Jool 5, but it is the lowest mass Grand Tour without ISRU record holder, with a take off mass of 14.447 tons, less than a Mammoth engine! To focus on the Jool 5 portion of the mission, a spaceplane made a bouncy, thrash-flippy landing, then a tiny tiny lander was used to tackle Tylo. Pol and Bop were handled by a small ion lander, and Vall was handled by a lander so small it looks like a pancake. You should definitely give this mission's video a watch, as words cannot truly describe just how insanely optimized this mission was. - @Goufalite Video here. This mission began with the assembly of a main mothership in LKO. Once complete, the ship cruised to Jool where it used gravity assists to achieve orbit. From there, the spaceplane was deployed to Laythe, but missed its target island. Never fear! The spaceplane had such high performance it was able to fly to a nearby island. Once back with the mothership, the SSTO was drained and detatched, and a capsule on its nose was undocked and docked to the Tylo lander. The Tylo lander used 2 aerospike engines to blow its way to the surface, and the final stage of the lander redocked to the mothership to be reused as the lander for Vall, Bop, and Pol. After visiting Vall and Pol, the lander flew by itself (and out of connectivity range) to Bop, where it landed and returned to Pol all on its own (Goufalite found this method was more fuel efficient). After returning to the mothership at Pol, a Tylo gravity assist sent the crew home, and both safely landed only 50 kilometers from the KSC. This mission made me nostalgic for my first Jool 5 mission, which in turn makes this mission special to me. Nice job, @Goufalite. - @king of nowhere Grand Tour. Mission thread here. This mission was done using Kerbalism, and an absolute UNIT of a mothership. Appropriately named the DREAM BIG, this ship conducted the Jool 5 challenge with dozens of farms, radiation shields, and drop ships to keep itself self-sufficient. Fighting food limitations, mod issues, solar storms, insanity and radiation damage, the crew of DREAM BIG flew throughout the entire Kerbol system planting flags on every world. The mission thread is an entertaining read, and has a video tour of the DREAM BIG spacecraft, which I highly recommend you check it out. I congratulate @king of nowhere on completing the mission, and for not losing their sanity in the process! Mission thread here. This mission was done with tremendous build constraints, and done entirely in a no-contract career mode save. Each launch was limited to 20-25 tons, meaning it took dozens of flights to finish the main ship, the Marco Polonium. The ship used many cost and weigh saving methods, including using the Laythe lander as a stage on Tylo, and by using claws instead of docking ports in some cases. The mission also visited Duna, Ike, Eeloo, Dres, and Eve (orbit) as well. This mission is one of the most entertaining ones I've reviewed (along with one of the most optimized) and I highly recommend giving it a read. Mission thread here. This mission was much like @king of nowhere's previous two in the sense that it involved Kerbalism and self-imposed building constraints. The result was a Jool 5 mission designed and flown to be as realistic as possible, and done with a maximum LKO mass of 140 tons. Bill and Bob took the Economic Downturn and its support craft to Jool and visited Tylo first, using the Seated Man lander, then made way for Laythe to deploy the Sole spaceplane, each accompanied by the space tug Right Answer. Sole's upper stage was reused as a Vall lander, while Seated Man's upper stage was used to land on Bop and Pol. For the inner three moons, great care was taken to limit the radiation damage incurred on the crew, with Bill being irradiated all the way to 95% upon his return to Economic Downturn. The return trajectory had to be tweaked a few times to prevent the capsule overheating, but Bill and Bob ultimately prevailed, and returned to Kerbin with nearly 500kg of samples. This mission is one of the few anxiety inducing submissions due to the challenges imposed by Jool's radiation belt. If you are a fan of gripping mission threads, I suggest giving this one a read. - @Lt_Duckweed Video here. This Jool 5 mission is notable for three reasons. Firstly, it is fully recoverable. Secondly, it only uses two engines, being the nerva and rapier. And thirdly, it was edited into a masterpiece of a video. This mission began with a launch just west of the KSC, and made a direct transfer to Jool. Upon Jool arrival, the elegently designed craft deployed a nerva-propelled lander, which performed the Tylo landing. After refueling at the main ship, the lander then visited Vall, Bop, and Pol with refueling trips to the main ship in between. The lander then returned to the main craft, which transfered to Laythe, completing the final landing. The craft then returned to Kerbin and came to a stop on the KSC runway, returning with it every part it launched with. I must repeat the high quality video the mission is edited into, and strongly suggest giving it a watch. - @bwest31415 Album here. This mission began with the launch of a long thin rocket which was followed by a normal transfer to Jool. Upon arrival to Jool however, inflatable heat shields were used to induce a Joolian aerobrake, a maneuver I've scarcely seen used since the addition of reentry heating to the game. The first landing to be done was Laythe, and the final stage of the lander was used to land on Vall and Tylo. The lander then left the main ship behind and traveled to Pol, then Bop, then back to Kerbin all without refueling. Jeb landed safely back on Kerbin after a toasty aerocapture, and exited the pod to take in a nice mountain view. - @18Watt ISRU, Thread here. This mission was done as both a Jool 5 and a Kerpollo submission. The mission began with a brute force launch and direct transfer to Jool. The mothership used wolfhound engines, which was good for TWR but slow when the ship was fully fueled. The ship flew first to Tylo, and after landing, the Tylo ascent stage would be reused for later landings. Next, the ship went to Bop to refuel, then to Laythe, where a staged spaceplane returned the brave Kerbonaut to the mothership. Next Val went to Vall, then the ship went to Pol and landed, before returning the crew to Kebrin, who parachuted to the surface of one of Kerbin's icecaps. - @OJT ISRU, Thread here. This mission was fully reusable* (apart from deployed fairings but we couldn't decide if that counted or not) and landed every component of the main ship back on Kerbin upon finishing the Jool system's exploration. The mission began with three launches, one for the mothership, one for the lander, and one for the SSTO spaceplane. Due to unfortunate moon placements, no gravity-assisted captures were possible and a retroburn was conducted. From there, a surprise Laythe aerocapture was conducted, saving much needed fuel. After the Laythe landing, the main ship flew to Vall, left the plane in orbit, and then landed with the lander beneath it and refueled on the surface. Next up was a Tylo landing with razor thin fuel margins, followed by Pol and Bop. It is worth noting that this mission did not repeat OJT's previous Jool 5 mission's Pol refueling process, in which the lander did numerous trips to the surface to bring tiny bits of fuel up to the main ship. With the landings complete and plenty of fuel to spare, the ship flew back to Kerbin where it landed piece by piece, with the lander being launched an SSTO parachute module. An excellent mission, and no doubt a fine achievement. - @kspfreak Video here. This mission not only visited the moons of Jool, Bop's Kraken, and in a rather small vehicle, but also visited every other moon in the entire Kerbol System! This mission's video is a fun watch, and ends with a fun paraglide back to the KSC. A mini grand tour of sorts, and very well done. - @JeDoesStuff ISRU, Video here. An SSTO submission! Coming in with a mass at just under 30 tons, JeDoesStuff showed off an incredibly refined ISRU SSTO by flaunting it around the Jool System. Included on the spaceplane are subtle but clever features to aid in launching horizontally, such as Vernier thrusters on the nose to raise attitude during takeoff, as well as a large landing gear that is only deployed to angle the craft. I haven't seen the latter of those additions on an SSTO before, so I applaud the ingenuity! The video this submission is contained within is also very well edited, resulting in a brief, yet concise viewing experience. If you're looking for a fun video to watch, or to see a razor-thin-margin Tylo landing, then this submission is for you. Low Mass - @EvermoreAlpaca Video here. Mass of 6.2 tons. Spaceplane launch, gravity assists off Kerbin and Eve to reach Jool. Landed on Laythe with the same rapier used in the launch stage, returned to orbit with an incredible TWR, scooted over to Tylo where the most bare-bones Tylo lander I've ever seen was used to land on and take off from Tylo (saved fuel by having Bill push it to the top of the mountain), flew over to Vall where the landing was done using staged batteries and a single ion engine. The Vall lander (which was also part of the Laythe lander) completed the last two landings on Bop and Pol and returned to Kerbin using many more gravity assists before preforming an aerobraking, with Bill parachuting to the space center and landing atop the RnD. - @Alpaca Z Video here. Mass of 5.8 tons (Current Record!). Vertical launch using a whiplash ramjet engine, which was staged prior to orbital insertion. Resonant orbits with Kerbin and Mun assists were used to set up a KEKKJ gravity assiste route to save fuel. Spider engines were used in a two-stage Laythe lander design to save weight, and EVA construction was used to rebuild craft to negate the need for decouplers or rebuild the craft (or get away with only bringing one chair). Landings were otherwise routine apart from an incident on Tylo where the lander fell on its side, requiring an intuitive solution to rebuild the craft in such a way it could use redundant engines as support pillars. The video is very well narrated and goes into much more detail regarding the craft's design and flight plan, I highly recommend watching it to get the full picture of this mission. - @camacju Video here. Mass of 5.2 tons (Current Record!). This mission not only shatters the previous record, but does so with an impeccably made video. Launch mass was saved in numerous ways, one of which involved using tiny flags in place of landing gear for the horizontal KSC Runway takeoff. EVA construction was used to reassemble the craft(s) into what was needed at any given point during the mission. The vessels flown and techniques used are difficult to describe, so I highly encourage a watch of this mission to see some of the best of Kerbal engineering. - @camacju and @Ultimate Steve Grand Tour, Video here. Mass of 7.6 tons. This is a meticulously crafted and borderline perfectly executed low mass mission. This was not only a Jool 5, but also an entire grand tour weighing not even 8 tons! The video's excellent editing allows it to speak for itself, and I highly recommend you watch this mission to see perhaps the greatest low mass mission in the history of KSP. Low Cost - @jinnantonix Video here. 34,663 funds. The thread's first low cost submission! Using a low cost launch vehicle and a K-E-K-K-J flyby route, the mission put Val and a fuel-tanker station in elliptical Laythe orbit. From there one lander tackled Laythe, and another tackled the other four moons, with an extra few stages for Tylo. It is worth mentioning that this mission used no electrical charge and relied entirely on engine gimbal and some RCS to steer. On the way back, a double Eve flyby helped slow down, so an aerocapture could be done at Kerbin, where Vall proceeded to parachute onto the VAB. - @camacju Mission here. 24,070 funds. This mission used a SRB powered launch stage and a terrier powered transfer vehicle to get the landers to Jool (after numerous gravity assists). A dedicated Laythe lander tackled the ocean-world, while a multi-stage Tylo lander tackled the rest of the moons, and returned the brave Kerbonaut Wildard Kerman to Kerbin. Before heading back however, the new space-construction method was utilized to steal a solar panel from the transfer stage, marking the first time this creative form of staging has been used. Mission here. 17,635 funds (Current Record!). This mission is a more stripped down version of @camacju's previous low cost mission. This mission featured a visit to Laythe's ocean floor, and utilized eva construction to manually remove empty fuel tanks from the mission. Additionally, eva fuel tanks were used to refill the brave kerbonaught's jetpack to enable fuel savings by extended jetpack use. Low Parts - @bayesian_acolyte ISRU, Album here. A small, single stage craft comprising of 31 parts. Bayesian_acolyte said there could have been some part count improvements, but even without it the mission still did so much with so little. This mission shows just how far ISRU can be stretched, especially with that Tylo landing. - @Majk Thread here. A simplistic Jool 5 mission consisting of only 30 parts . The mission began using a very basic launch stage, and flew to Jool using a long nuclear ship. Lander reuse enabled part count savings, and usage of the nuclear ship as an ablative heat-shield helped return Val to Kerbin's surface in one piece. - @Majk Video here. Easily the most simple Jool 5 mission completed to date, accomplished using only 9 parts (Current Record!). This mission started with the 9th part, an RTG, stowed inside the command pod before installing it in orbit. It is also worth recognizing that a clever method of timewarping in the tracking station enabled refueling to take place while utilizing only a single RTG. The submission takes the form of a short, concise, and wel narrated video, and I highly encourage giving it a watch. 2nd Level - @jinnantonix ISRU, Album here. Used a big launch with a self-refueling vector-powered lander that made multiple Laythe landings and mined ore from every moon. Two kerbals were landed on each moon and the lander was recovered at KSC. - @Kerbolitto ISRU, Album here. Excellent mission done using two space shuttles capable of refueling on moons. Absolutely amazing job. In all things I ever thought I would see happen in KSP, a space shuttle landing on Tylo was not one of them. - @Marschig ISRU, Videos here. Not one, not two, but three ISRU planes flew to Jool and to all five moons on both the 3rd and 2nd levels. The SSTOs also visited Duna and Minmus in their missions before landing back at the KSC. Truly exceptional. This is the first time I've seen three Jool 5s all submitted at one time! - @PhoenixRise86 Album here. Used a mothership for the first part of the mission, then resorted to ions to get to Ike and Minmus, then safely back home. Also, this is the first 2nd level mission to not use ISRU. - @GRS: Album here. The highly anticipated Sheep v2 did not disappoint, and went above and beyond by visiting not just Jool's moons but also Kerbin's and Dres. Used massive nuclear boosters to get around the Jool system and the Tythe lander to get two Kerbals on every moon and Dres, before using the Sheep v2 to land the entire crew on Minmus and Mun. Spectacular! - @Xurkitree ISRU Video here. This modded mission utilized ISRU, a nuclear mothership, and eight aerospikes to land on all five of Jool's moons with Cerdrin and Lodous Kerman. Returned the lander and mothership to LKO where a separate rocket retrieved the crew. I highly encourage watching the video submitted, it is excellently edited and the music supports the awe of the mission. - @QF9E Thread here. This mission used a blunt-force approach by lifting off on a powerful launch stage, and made quick work of Jool's moons. The moons were all visited by one lander, which dropped various attachments that helped it land on some of the bigger moons. At the end of the mission, the three brave kerbonauts safely touched down in the ocean, and a BFR style spacecraft recovered the remains of the lander in Kerbin orbit for historical preservation. Truly an impressive mission indeed! - @Mars-Bound Hokie ISRU Mission here. Using the Anubis II SSTO, Tancan, Fernal, and Kenby Kerman flew to Minmus to refuel, then blasted off for Jool. After touching down on Laythe to refuel, the crew went for Bop, then to Tylo. After landing with no liquid fuel to spare, the Anubis II was refueled, then launched for Pol. After a risky auto-piloted landing, the ship refuel before bounding to Vall, where the crew had a group picture. Heading back to Kerbin, a mix of brute force and aero-braking was used to get the trajectory needed to get back to the KSC, and then the crew refused to ditch the plane and pulled off the legendary runway landing. - @king of nowhere Mission here. "And so I completed the Jool 5 in day 383, 1 hour and 9 minutes of a new career" are the words typed by @king of nowhere at the end of the mission thread, and fundamentally capture the astronomical accomplishment documented within it. In a career save speedrun, it was decided to focus on a Jool 5, and the mission was optimized for time rather than mass or cost. The amounts of delta-v put into each maneuver to achieve bullet-like trajectories around the Kerbolar and Jool systems is simply jaw dropping. Over the course of the flight, the La coscienza di xenon and its landers managed to plant flags on all 5 moons within a 12 day window, which I don't believe has ever been done before. If you wish to see the chronicles of a one-of-a-kind, record setting Jool 5 mission, the flight of the La coscienza di xenon is the mission thread for you. Grand Tour Mission here. @king of nowhere's second Kerbalism Grand Tour, but with radiation shielding 3 times less effective, bugs, life support issues, frantic crew members smashing fuel cells and dumping food overboard, and so much more! This mission chronicles the Nail Bolt on its tour around the solar system, finding monoliths on every world and making it back in roughly two decades. This mission thread covers the begins, rebeginnings, redesigns, quick fixes, and compromises that took place during the Bolt's journey not just to Jool's 5 moons, but to every other surface as well. This is one of the most thorough submissions the challenge has seen, and is a great resource for those considering Kerbalism entries of their own. - @Lyra Mission here. A single launch mission! Using a spaceplane for Laythe, a notably slim Tylo lander (with a reusable upper stage for Vall), and an ion lander for Bop and Pol, this mission was a pleasant, self contained romp around the Jool System. One unique aspect of this mission I've seldom seen elsewhere was the use of claws on the nuclear mothership's outer hull. This allowed the landers to not need docking ports and attach to the hull like barnacles. A very clever, mass saving decision for the landers for sure! 3rd Level - @iAMtheWALRUS Grand Tour, ISRU, Album here. Used SSTOs to launch the mission and used moon hopping to get around the Kerbol system. Very nicely done. Also, first 1.4 submission - @sturmhauke Album here. To put it in the words of the pilot them self; "A mostly reusable mission to all 5 of Jool's moons. Single launch SSTO carrier drone, with a separable mothership and 5 landers." Very well done and efficient mission. Used fuel cells to power ion crafts for Bop and Pol, sent a plane to Laythe, and conquered Tylo with a rocket lander. - @mystifeid Album here, ISRU. Used two launches to put a mothership and a universal lander into orbit. Then used left over launch stage to boost to Jool and then around the system until it ran out and was staged at Tylo. Bob landed on every moon, accompanied with a different Kerbal for every moon. Very nice mission, and even had the added bonus of a near KSC landing. - @PhoenixRise86 Album here. Used a single launch of pure rocketry, no jets, ions, or nukes used in the entire mission. This mission did the Jool 5 mission in style, with some of the most interesting landers I've ever seen, including an aerospike Laythe plane. - @Marschig ISRU, Videos here. Not one, not two, but three ISRU planes flew to Jool and to all five moons on both the 3rd and 2nd levels. The SSTOs also visited Duna and Minmus in their missions before landing back at the KSC. Truly exceptional. This is the first time I've seen three Jool 5s all submitted at one time! - @jinnantonix ISRU, Video here. Of all the Jool 5 missions I have seen in this thread so far, none treat their Kerbals better than Jinnantonix has. The craft was modular in design and split into several different arrangements for various landings, and came with a gravity spin for deep space transit. Very considerate, and very awesome. - @Grogs Album here. Two launches to build the main ship in orbit, one crew launch for realism. Used a giant transfer stage to get the landers to Jool. Chemical engines pushed the landers about the Jool system, with nine Kerbals in total being involved in the mission. Once the landings were completed the mothership returned to Kerbin where a fourth launch collected the Kerbals and returned them safely to Kerbin. - @Pipcard ISRU Thread here. A well executed, eight Kerbal mission with one of the longest ships I've ever seen in this game. Excellent mission that toured the Jool System in an engaging thread. Mission was assembled in multiple parts, flew to Jool, landed on the moons (being sure to refuel on Bop and Pol when needed), EVA jetpacked off Tylo, and the crew was returned to Kerbin by a separately flown space plane. - @Kerbolitto ISRU Mission here, here, and here. Kerbolitto's second submission! Using a space shuttle with several surface experiments, a crew of eight explored the system. The Tylo landing was done with perfect margins, landing with no fuel left! This craft may also hold the record for lowest TWR launch of Bop in history, and an outpost on Laythe with a mini-plane was even constructed. Bob chose to stay behind and man the base while the crew returned home. Excellent end to an excellent mission! - @Ksp Slingshooter Album here. Assembled the main ship using multiple launches, then flew to Jool, settling in an elliptical Jool orbit with some help from a few gravity assists. From there the landers detached and flew to their moons, one by one and completed their landings. Due to some unexpected occurrences at Laythe, the Vall lander swooped in and rescued the Kerbal, taking both back to the mothership. Without enough room in the command pods for everyone, two brave Kerbals rode back to Kerbin on ladders, detaching and re-rendezvousing during timewarp. A rescue craft was launched, and met the mothership just in time, with only three minutes to transfer the Kerbals before a fiery re-entry. Truly a Kerbal mission! - @RoninFrog ISRU Thread here. Using the gloriously huge HMS Sauron, Jeb and 16 friends took to Jool in this massive SSTA. First they stopped at the Mun, then flew to Pol, then Tylo, then Vall, Laythe, and finally Bop. On the way back to Kerbin, time and fuel and the positions of the planets made a Duna landing prove itself most useful, before heading back to the Mun, and finally, back to Kerbin. This 1 stage mission has some amazing screenshots in its thread, as well as most amusing comments for each picture. If you're wanting to learn more about an ISRU approach, I suggest giving this mission a peak. - @OutInSpace Video here. Using a total of eight launches, this mission's mothership was constructed methodically, complete with an enormous pair of transfer boosters. After heading to Jool directly, the mothership flew to Tylo, Vall, and Laythe by itself, and sent an ion craft to Bop and Pol instead. After numerous attempts, the Laythe plane was finally able to show what it could do, and the 5 crew returned to Kerbin orbit, where they were picked up by a landing craft. If you want to see the nitty-gritty maneuvers used during a Jool 5 mission, I suggest you check out this mission's video. Its editing and methodicalness make it an unintentional flight-tutorial for getting to Jool. - @Entropian ISRU Mission here. Using a 5 meter tank with 5 meter tanks strapped on the side and a large cluster of mastodon engines, the craft rocketed off the pad to Minmus, where it refueled and went off to Jool. Landing on Laythe proved to a close call, with ZERO delta-v remaining upon touchdown. From there the ship bounced to Vall, Tylo, Pol, and Bop, before making a rough splashdown on Kerbin. It is worth noting that the crew did forget to put a flag on Bop. However since every other mission criteria was met and the craft was landed on Bop it is still being counted. - @GRS Grand Tour. Mission here. This time with the Sheep v4 the Jool moons were visited again, along with 60 other destinations! Relying heavily on ion power, landing after landing was accomplished visiting worlds close to the sun, around Jool, and even outer dwarf planets. So many worlds were mentioned that the Jool 5 portion is only a tiny fragment of the overall mission. There is genuinely too much in that mission to describe here, so I highly suggest you check out the most expansive sheep yet's thread! - @s_gamer101. Mission here. This mission began with the launch of an enormous reusable launch system that placed the main ship in orbit. A trip to Jool ended with a fiery aerocapture above Laythe, where two of the crew members took a small spaceplane to the surface. After a tricky fuel situation in which drop tanks were accidentally kept as huge pieces of ballasts, the Tylo tug was used as an extra stage to boost the main ship. This proved to be enough delta-v, as once the landings were completed the ship cruised back to Kerbin, where they parachuted safely to complete the mission. - @AlpacaMall Mission here. This mission began with the launch and orbital construction of the KSS-J "Orca". Engineer construction added fuel lines and removed unneeded RCS thrusters, and the craft departed for Jool with a reusable lander upper stage, with lander stages for Laythe and Tylo. The landings were completed in the following order: Laythe, Tylo, Vall, Pol, Bop. From Bop, the Orca was left to serve as a relay station while the crew module left for Kerbin. The vessel landed with all the crew and 23458 science. - @BeanThruster Album here. This mission began with the launch of Vapidity, the mothership used during the mission. Instead of going to Jool, Vapidity made its first flight to an E-class asteroid so it could refill all of its fuel tanks (it launched almost empty to save weight). After flying to Jool, the first landing took place on Tylo, before leaving the engine nacelles in case later refueling was needed. Next, the last stage of the Tylo lander was used to land on Vall, then the lander flew solo to Bop where it awaited the rest of the ship. Vapidity took the time to take a spaceplane to Laythe, then went back to low Tylo orbit to refuel. Vapidity met the Vapidlander at Bop, conducted the landing, then went to Pol to do the same. Vapidity returned to Kerbin before the crew landed using the Laythe spaceplane. In total, the crew collected 20113.6 science. - @RuBisCO ISRU Album here. This mission began with a lot of mainsail engines to push the main craft into orbit, and delivered not one, but seven Kerbals to the surface of each moon. The first visit was Pol, where cleverly built piston legs kept the refueling craft perfectly level. Next was Bop, then Vall, then Tylo, where a rover and lab were brought to the surface and returned to orbit (except Tylo where it got left behind). For the Laythe landing, the crew took down a spaceplane, as well as a helicopter and a floating lab with plane-refueling capabilities. The helicopter was used to collect science from the local area, and after being refueled, the plane returned to orbit. After the main ship was refueled on Pol, the crew returned home. - @18Watt ISRU , Mission here. This mission is nearly identical to 18Watt's previous submission, but now has accommodated a unique Kerbal for each moon, bumping it from a 1st to a 3rd level submission. Main ship refueled on Minmus before heading to Jool, refueled on small moons, and pilots Val and Billy Bobfurt flew each unique specialist to their respective moons. - @Krazy1 ISRU, Album here. This mission was done with the Principia mod, which makes gravity and orbits behave more realistically. The spacecraft used was the "2 by 4", named after its two mammoth engines and four nervs. First the craft launched to Minmus, then visited a passing asteroid, then went back to Minmus to refuel, then shot off to Jool. After the Laythe landing, there was some trouble getting to Vall due to orbital issues. After Vall came a very bouncy Tylo landing, which was followed by a Pol landing, and then a Bop landing. It is worth noting that Bop is orbiting retrograde in this mod for orbital stability. After completing the landings and experimenting with weird orbits, the 2 by 4 traveled home, refueled on Minmus to prep for landing, and then touched down safely on Kerbin with its crew of 5. ISRU, Album here. This mission utilized an orange and gray aesthetically pleasing spacecraft. Once launched into orbit, the craft refueled on Minmus, then shot off to Jool where it landed on Vall, then flew to Tylo where it performed this landing, before nearly burning on Laythe, then finished up with Bop and Pol. Upon returning to Kerbin, some excess ore was turned to fuel to save weight, and the crew splashed down 10km from the KSC. - @Kimera Industries. Mission here. This mission's mission thread chronicles the Avocado on its journey to Jool's moons and back, using appropriately named components and landers. Due to its nuclear propulsion, the escape burn was split in two, though did not go gently into that good night, and upon arriving to Jool, took use of a convenient Tylo assist to go almost directly to Laythe. From Laythe, a lander was dispatched to Vall and Pol, then the entire ship reunited and migrated to Tylo where the landing was achieved on the fifth try. Next came Gilly 2.0 Bop, where an interesting SPOILER was discovered. Upon returning to Kerbin with little to no time for caution, the cargo container and its draggy friends kept the craft from overheating during airbraking, and the crew landed to live another day. Jeb's Level - @Xurkitree Grand Tour, ISRU Album Here. Collected 19,711.3 science from Jool on a girl's night out mission with no lack of gravity assists. A note from the author said that the mission greatly improved their skills in KSP and proved that fact well with the insane gravity assists they pulled off. Also first Jeb's Level on the new thread yay! - @ManEatingApe Video here. And here. And here. And here. And here. And here. Collected 16,532.0 science from Jool. There isn't anything I can say about this mission except you need to see it for yourself. Exclusively low tech was used, and collected in space science from all biomes. This mission did the near-impossible, with primitive parts, and landed all Kerbals safely back on Kerbin. - @SolarAdmiral Video here. Collected 42,296 science from the Jool System. Single launch on a cluster of three meter parts, before heading off to Jool. Started with Laythe first, landing using a floating platform. Science was collected with a small jet-powered boat. Next stop was Tylo, where a rover was used to collect science from many biomes. On Vall one landing was done, and a hop added to it before heading to orbit again. Numerous biomes collected from Bop and Pol by hopping around in their low gravities. Direct shot home and landed all seven Kerbals to tell the tale. Absolutely astounding mission! - @jinnantonix ISRU Video here. Collected 82,510 science from the Jool System. Single launch, one much smaller than you might expect. Used a plane to gather large amounts of science from Laythe, dove into Jool's atmosphere, grabbed science from almost if not everywhere, and even managed to use the Laythe plane as the final stage on the Tylo landing. Had an artificial gravity system to facilitate the kerbals, and landed back at the KSC. Honestly jinnatonix managed to do so much in this video I can't describe it all here so I suggest you just watch the video. Amazing job. - @GRS Album here. Collected 28,643 science from the Jool System. The long awaited Sheep mission that satisfied both the Kerpollo and Jool 5 requirements led by Simone Kerman that explored the Jool system and returned home Apollo style. The mission had a heavy launch and went to, around, and from Jool using a massive nuclear stage. The usage of the Scifi visual pack gave the mission a unique look as it took science from every moon (including Jool's upper atmosphere!) in style. Incredible. - @Jim123 Video here. Collected 8780.9 science from the Jool System. Single giant launch put a large nuclear mothership in orbit. Flew straight to Laythe where the landing was completed with a dual stage to orbit (and Jeb's jetpack). From there the crew went to Vall and landed, before heading to Tylo and dropping one of the most Kerbal looking Tylo landers I've ever seen to the surface. After Tylo biome hopping was used on Bop and Tylo, before a pair of service modules detached and went back to Kerbin, boosting each other home where the crew landed. Nice video. - @jost ISRU Album here. Collected 16940.2 science from the Jool system. Flew to Jool using a long nuclear mothership. From there an ion ore probe helped find ore on every moon but Laythe for the rocket lander. Laythe used a three seat plane for the landing, and even found a geyser while on the surface. Landed on Tylo with 1m/s to spare before refueling, and landed everyone safely back on Kerbin after leaving the nukes in a graveyard orbit around Kerbin. Excellent! - @Beriev Album here. Collected 49430.1 science from the Jool system. This entire mission was done in a 6.4x solar system. Launched off the pad with an absolutely enourmous rocket, fittingly dubbed the 'Absolute Unit'. Used many kicks to get out to Jool, where the ship split up to tackle the moons. For Laythe and Tylo, ascent vehicles were landed separately, before the crew arrived on-surface. Later, both sets met up at Vall, then flew to Pol, then Bop, and then to Dres. After a fun journey, the Absolute Unit returned to Kerbin, and the crew landed safely. This mission has an incredible execution and design, as well as a well-captioned Imgur album. I highly suggest giving it a look. - @Pro100kerbonaut Video here. Collected 10238 science from the Jool system. This mission was done with a rather interesting, asymmetrically balanced ship, and had quite the bouncy ride. On Tylo parkour was done, on Laythe swimming. On Vall two landings were done, and on Pol and Bop the lander bounced around. This mission used a combination of a gravity assist off Tylo and a retro-burn to capture at Jool, and upon return to Kerbin parachutes were attached to the crew section using a klaw. A fun mission with great editing. - @king of nowhere ISRU Mission thread here. Collected 105136 science (Current Record!) from the Jool system. This mission was insane from its conception, with the goal to collect every single bit of science from the Jool system as possible. While this goal was not ultimately accomplished, the mission is still one of (if not) the greatest Jool 5 submissions I have ever seen. To collect science on each world, a durable lander known as the Dancing Porcupine was deployed and driven on all moons but Laythe. For Laythe, a spaceplane called Absolutely NOT Albatross was used to collect science from each biome. In fact, Absolutely NOT Albatross did even more than just Laythe. Using a multi-stage attachment, Absolutely NOT Albatross visited the lower atmosphere of Jool and returned to tell the tale. The craft's brave pilot even took an EVA report while in flight before ascending. The main ship dubbed the Flying Christmas Tree, and was capable of refueling on low gravity worlds. Upon returning to Kerbin, a craft launched to return the brave Kerbonauts to their home-world. Having visited every biome on every moon, it is no surprise that this mission amassed more science than any other Jool 5 mission before it. I highly recommend viewing this mission's main thread. Amazing job king of nowhere! Mission thread here. Collected 11395 science from the Jool System. This is my favorite submission to the Jool 5 Challenge I have ever reviewed. The sheer amount of effort put into this mission cannot be overstated. King of Nowhere started this mission as a nanocristalline diamond caveman mission, which in short meant no contracts, no facility upgrades, no quicksaving, on career mode, while starting the save with severe limitations. While the mission ended up needing quick-loading, it still is eye popping to see just how much work went into it. Each launch (in the VAB) was limited to 18 tons maximum, so a work around was used by having docking ports around the base of the rocket, to which separate boosters would be docked using a runway-launched rover. This meant that many launches required multiple launches of booster attachment vessels before the rocket itself could attempt to leave the pad. After over 100 launches, the Navis Sideralis Neanderthalensis and all its cargo were ready, and the ship departed for Jool, leaving a most amusing pattern of drop tanks in its wake. Upon reaching Jool, disaster struck when the Tylo lander suffered an anomoly, and quicksaves were needed to complete the Jool 5. While at Jool, science modules were discarded after use because a lack of KSC upgrades prevented their resetting, and every aspect of the mission, from flying between moons to the landings themselves, were executed with meticulous testing and prior calculation. I cannot possibly explain everything this mission did in this little blurb, so I highly encourage anyone who wants to see some of the best Kerbal engineering I've ever seen to check out the linked mission thread above. - @OJT ISRU Mission thread here. Collected 26871.3 science from the Jool System. This mission thread contains some of the most eye-catching, visually stunning KSP screenshots I have ever seen in a Jool 5 submission. The mission itself was tested and proofed in sandbox, and consisted of a long, skinny mothership, a spaceplane, and an ISRU lander for Tylo. With the lander and plane hanging from docking points on the main ship, the craft boosted to Jool and used a Tylo flyby to capture. Visiting Vall first, the lander took around 100 days to refuel. The ship then flew to Pol where the relatively tiny lander (in relation to the mothership) flew to Pol's surface and back numerous times to refuel the main ship before it could head to Bop. At Bop a kraken was discovered, and on Tylo the crew found it refreshingly eventless. The last destination was Laythe, where the plane and lander were left in orbit so the main ship could return to Kerbin. A return craft returned the crew and science, and crew XP was had by all. - @Robin Patenall Mission thread here. Collected 61174.6 science from the Jool System. This mission began with the construction of the Emerald Star, a large and reconfigurable interplanetary vessel that required 17 launches to complete. Once built, the Emerald Star used Eve and Kerbin gravity assists to efficiently sling itself to Jool and started with Tylo. Using one of the Emerald Star's 3 drive cores to send itself down to a lower Tylo orbit, the lander successfully brought the crew to and from the Tylic surface. When the mission reached Vall, a magical anomaly was discovered, one which would prove to be only one of many odd discoveries made on Jool's moons. An SSTO found one on Laythe as well, during one of its three total landings. A monolith was found on Pol, and a deceased kraken on Bop, one which caused a crew member to lament their inability to bury it. Once the landings had been complete, the remains of the Emerald Star returned home, where it was parked in Kerbin orbit awaiting future assignment. - @problemecium Mission thread here. Collected 8755.7 science from the Jool System. This mission thread covers the finally completed tale of the Aletheia, a massive, nearly 1.3 kiloton mothership. With numerous cargo bays, it brought landers, an SSTO, a deployable space station, numerous pieces of scientific equipment, and two ARKS to return the crew to Kerbin if needed. Upon construction, Aletheia and its seven crew members proceeded to Jool, using 46% of its total fuel. The transfer section was left behind in Laythe orbit while the rest of Aletheia continued on. After Laythe came Vall, where one of the ARKS was used to refuel the Tylo lander to enable it to tackle Vall (the ARK was then joined to the deployable station and left behind). The lander then tackled Tylo, and was left behind for future use. Bop saw the discovery of a hopefully deceased Kraken, and Pol marked landing number 5. This romp unfortunately depleted Aletheia of the fuel sufficient to return to Kerbin, so the second ARK spacecraft brought the crew home safely, using a Mun assist to tweak its final trajectory. This is one of the more aesthetically pleasing Jool 5 missions, and done in career mode in a very well typed out and necromanced thread, so if you are a fan of large stylish motherships, I would recommend giving this thread a view. Gatecrashers / Honorary Mentions - @JacobJHC Grand Tour, video here. Giant single launch craft, also visited every planet and moon from the OPM planet pack. Very big. Gatecrasher because crew hasn't landed yet. - @Fraus Mission here. There's nothing that can be said about this, other than that this mission definitely had more thought put into it than any other Jool 5 I've seen. - @cqIpb Mission here. This mission was flown on an Xbox, and pushed the console to its framerate limits! cqIpl was inspired to do a Jool 5 mission after finding this thread, and despite not being able to land on Laythe due to lander instability, still had a lot of fun finishing the rest of the mission, and took a few great screenshots along the way! As of writing this, cqIpb is still new to the KSP Forums. Welcome, we're glad you're here! - @Alpaca Z, using a craft built by @Lt_Duckweed (with permission) Grand Tour, ISRU . Video here. Using a rather simply built SSTA, this mission was a simple case of flying around the entire solar system and refueling everywhere. This craft utilized air-fans, ions, vectors, and nerv engines, allowing it to be not only capable of high efficiency maneuvers, but also those requiring high TWRs. A highlight of this mission was the strategy to use EVA construction to rebuild the back of the plane to enable it to land vertically on Tylo's surface. Why bring landing legs when you have wings that could do the job just as well? This mission's video submission is also of a high quality, so I recommend giving it a view. In all, the crew of three finished their grand tour in only 15 years and 117 days! Efficient and speedy Moved to Honorary Mentions due to the fact that the crew could not exit onto Tylo's surface.

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i5-10600k | GPU: RTX 3080 | RAM: 32GB DDR4-3600 Severity: None Frequency: Always Issue: There is a typo / grammatical error in the part description of the LV-2000 "Trumpet". The wrong speech article is used in the first sentence, which reads: The "an" article is typically only used when proceeding a word that begins with a vowel. Expectation: In "to build an deep space engine", "an" should be "a". Steps to Reproduce: In the VAB (or R&D Center), hover over the LV-2000 "Trumpet". Press Shift to expand the part info and description. Read the first sentence. Included Attachments:

Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes OS: Windows 10 | CPU: i5-10600k | GPU: RTX 3080 | RAM: 32GB DDR4-3600 Severity: None Frequency: Always Issue: There is a single character typo in the description of the RE-L10 "Poodle". The last sentence of the description reads : Expectation: The : after Poodle should be another ' in order to close the quotation, i.e., 'Poodle'. Steps to Replicate: In the VAB (or R&D Center), hover over the "Poodle" part. Press Shift to expand the part window and description. Read the last sentence in the description. Included Attachments:

Starship Expansion Project Starship Expansion Project (SEP) is a mod being developed by me, Kari, and our amazing team. Our project aims to bring our intepretation of the Starship vehicle by SpaceX into Kerbal Space Program. While a lot of the design choices are based on the actual vehicle sitting on Boca Chica, creative freedom is used to expand our mod even further. Special thanks to @damonvv for allowing us to adapt tundra's plugin to ourselves, @SofieBrinkfor her hard work adapting the code and overall improvement of the mod, @IsaQuestfor the raptor model and textures, @Janus92 for the amazing IVA models, @EritoKaiofor indirectly helping me improve myself over the last few months, and you everyone on our discord server for their immense support to our mod, I could not have done without you Screenshots Dependencies Module Manager Waterfall (0.8.1 or higher) B9 Part Switch Extremely Important but not required mods Textures Unlimited (for shiny parts!) Tundra Exploration (For more engine modes on SH) KRJ Next or KJR Continued (Avoid wobbly joints) Starship Launch Expansion Recommended Mods Flight Manager for Reusable Stages Community Resource Pack Trajectories Modular Launch Pads HullCameraVDS & NeptuneCamera (custom cameras on ship and booster) IVA Dependencies Near Future Props Reviva Free IVA Raster Prop Monitor ASET Props IVA Recommended Mods JSI Advanced Transparent Pods Realism Overhaul is supported* *not 100% working right now feedback and help is appreciated Download SEP is officially found at Spacedock, GitHub and CKAN. Any other form of download is not official and should not be trusted FAQ 1. Where is *? R: If you have not found a feature you like, please check our roadmap to see if it's not already planned, otherwise feel free to ask nicely and we'll happily look into it 2. Why there's only 2 engine modes on the booster? R: When we where authorized to use part of Tundra's plugin, we agreed to leave the engine switch on Tundra's mod, as it was made mainly for falcon, if you want an extra mode, install Tundra and it will be on your game 3. What are those names? R: I renamed the parts to match The Expanse (my favorite show) names, if you're not familiar or want to have real names, there is an option for it on the extras folder when you download it 4. WHERE IS THE FROST I SAW IN THE PICTURES? R: It's currently in development and will be integrated into SEP, right now it's a separate mod that adds a part that attaches to a node on the ship and booster, you can find it on our discord server under the #sep-addons channel on a pinned comment along with other mods made by our community 5. My plumes are different R: Not a question, but could be pro plumes made by Fossil, it's currenly in development and you can find a version of it on our discord server under the #sep-addons channel on a pinned comment Licensing Configs are distributed under CC-NC-SA-4.0 License. Nertea's HabUtils.dll is distributed under MIT license. All Textures/models and our plugin StarshipExpansionProject.dll are distributed under All Right Reserved License.

When you build and test stages, especially first stage, you need some part that have mass and volume and do not have other properties (i.e. fuel, elrctric charge etc) right now it is very difficult job to construct "mass simulator" from fuel tanks or engine or smth else. It would be cool to have different size (mass) dummy steel discs for this purpose. Thnx.

The source code is available on GitHub under the MIT license. Abstract This mod aims to replace KSP's unstable physics integration with a higher-order symplectic integrator, adding n-body Newtonian gravitation in the process. Acronyms Documentation and download Principia is not built in the same way as most other mods (most of it is native code, with a thin C# interface layer), so that compatibility issues may arise depending on the platform. Binaries are available for Windows, Linux (built on Ubuntu, your mileage may vary when using these on other distributions), and Macintosh (thanks to @Jim DiGriz). Note that the mod only works with 64-bit versions of KSP. Please read the wiki page detailing the concepts carefully; a lot of things behave differently when using principia, in particular map view and flight planning. Many aspects of the mod are unfinished, and this is detailed on that page. In addition, please read the FAQ and bug reporting guide. Note that bug reporting procedures differ significantly from those of other mods because of our custom logging system, our use of fatal failures, and our journalling system (which, if activated, allows us to replay the events that led to a crash for later debugging). A tutorial is available on the topic of going to the Mun in various ways, applying the concepts described above. There is also a guide to low orbit rendezvous that should help with understanding the target LVLH frame. Since Principia makes all bodies attract each other according to Newtonian gravitation, the stability of the solar system is a concern; when using stock KSP, Principia modifies the Jool system so that it is stable. When using a customized system (e.g. with Kopernicus), you need to make sure that the system is stable. If you wish to ask questions, you may want to do so on the #principia IRC channel on EsperNet, the #principia channel on the KSP-RO Discord, or #principia:matrix.mockingbirdnest.com. Your concerns may be addressed more quickly there than on the fora (bear in mind however that there isn't always someone around who can answer your question right away; if no-one is around, you may want to stay on the channel for a while). Download the binary (Macintosh, Ubuntu, and Windows): Principia Καραθεοδωρή for 1.8.1, 1.9.1, 1.10.1, 1.11.0–2, and 1.12.2–5; or from 腾讯微云: Principia ‎Καραθεοδωρή for 1.8.1, 1.9.1, 1.10.1, 1.11.0–2, and 1.12.2–5. Alternatively, if you don't trust our binary, build the mod from the Καραθεοδωρή release. We provide a patch to turn @GregroxMun's SLIPPIST-1 into the TRAPPIST-1 system; see the installations instructions. Status Dates are ISO 8601 extended format. 2024-04-08 For the new moon (lunation number 300), which is a total eclipse, the new release (Καραθεοδωρή) is out. Some crashes that could occur when looking at trajectories in map view using the surface frame have been fixed. See the change log for more details. 2024-03-09 For the new moon (lunation number 299), the new release (Канторович) is out. Various crashes and errors resulting in non-functional windows have been fixed. See the change log for more details. 2024-02-09 For the new moon (lunation number 298), the new release (掛谷) is out. Principia now displays predicted and planned impacts in the right location when seen in the surface frame; this replaces the experimental approach that was attempted in Jordan. See the change log for more details. 2024-01-10 For the new moon (lunation number 297), the new release (Julia) is out. Several bugs introduced in recent versions have been fixed. See the change log for more details. 2023-12-12 For the new moon (lunation number 296), the new release (Jordan) is out. Performance with high part count vessels has been improved. In some limited circumstances, Principia now displays collisions between the prediction and the surface of a celestial at the right location, when seen in the surface frame. This is still work-in-progress. Other bugs have been fixed. See the change log for more details. 2023-11-13 For the new moon (lunation number 295), the new release (賈憲) is out. Local optimization of manœuvres has been added to assist in tuning flybys. The issue underlying the cryptic error message improved in the preceding release has been fixed. A three-year-old issue in our handling of rotation with stock aerodynamics has been fixed. Other bugs have been fixed. See the change log for more details. 2023-10-14 For the new moon (lunation number 294), the new release () is out. A cryptic error message has been improved. See the change log for more details. 2023-09-15 For the new moon (lunation number 293), the new release (Jensen) is out. No user-visible changes in this version as we have been laying the groundwork for a mechanism that would help optimize burns to meet certain criteria. See the change log for more details. 2023-08-16 For the new moon (lunation number 292), the new release (Jacobi) is out. A pinnable hover tooltip is displayed when the cursor is hovered over a manœuvre marker, emulating the stock KSP node markers. Thanks to @Al2Me6 for this contribution. See the change log for more details. 2023-07-17 For the new moon (lunation number 291), the new release (岩澤) is out. The manœuvre markers (specifically their Frenet trihedra) are now draggable. Thanks to @Al2Me6 for this contribution. See the change log for more details. 2023-06-18 For the new moon (lunation number 290), the new release (伊藤) is out. The computation of the equipotentials has been improved to make the results more useful for the outer planets, and its performance has been improved. A cryptic error message has been improved. See the change log for more details. 2023-05-19 For the new moon (lunation number 289), the new release (ابن الهيثم) is out. A new rotating and pulsating reference frame has been added; it is in this frame that the Lagrange points are defined for the elliptic restricted three body problem. When this frame is used as the plotting frame, the equipotentials of the centrifugal plus gravitational potential are drawn, so that the Lagrange points can be seen. This provides valuable context when planning low-energy transfers and other trajectories involving the Lagrange points. The following animation by @Al2Me6 illustrates the case of a ballistic capture around the Moon, where the trajectory can be seen to fall into the Moon’s potential well. See the change log for more details. 2023-04-20 For the new moon (lunation number 288), the new release (Ὑπατία) is out. Two bugs, one of which could cause crashes, have been fixed. See the change log for more details. 2023-03-21 For the new moon (lunation number 287), the new release (Hurwitz) is out. The orbit analyser now displays the local time of the ascending node, and can identify sun-synchronous orbits. See the change log for more details. 2023-02-20 For the new moon (lunation number 286), the new release (Householder) is out. No user-visible changes in this version as we have been laying the groundwork for future improvements. In particular, the orbit analyser has been completely rewritten with the goal of making it work with celestials (3493). Please report any bug or oddity that you may encounter with orbit analysis. See the change log for more details. 2023-01-21 For the new moon (lunation number 285), the new release (Horner) is out. Support for KSP 1.12.5 has been added. More quality-of-life improvements to flight plan editing. See the change log for more details. 2022-12-23 For the new moon (lunation number 284), the new release (l’Hôpital) is out. Several quality-of-life issues related to flight plan editing have been addressed. See the change log for more details. 2022-11-23 For the new moon (lunation number 283), the new release (Ἱπποκράτης) is out. Support for KSP 1.12.4 has been added. A bug in the orbit analyser has been fixed. See the change log for more details. 2022-10-25 For the new moon (lunation number 282), the new release (Ἱππίας) is out. Patched conics are no longer displayed in some reference frames where they made no sense. See the change log for more details. 2022-09-25 For the new moon (lunation number 281), the new release (Ἵππασος) is out. Three bugs have been fixed. See the change log for more details. 2022-08-26 For the new moon (lunation number 280), the new release (Ἵππαρχος) is out. A bug in RCS thrust estimation with some parts was fixed by @Flibble. The UI of the flight plan tolerance selector has been improved, matching the changes to the prediction tolerance selector in Hilbert. The axes used by Principia have been made consistent: MechJeb and Principia should now report a similar longitude of the ascending node for an active vessel in a sufficiently Keplerian orbit, instead of differing by 90°. Thanks to @rnlahaye for spotting a bug in that change shortly before the release.  See the change log for more details. 2022-07-28 For the new moon (lunation number 279), the new release (Hilbert) is out. Improvements have been made to the flight planning tool: It now supports multiple flight plans; Buttons have been added to move an orbital manœuvre to the preceding or next revolution; The digits may be individually adjusted by scrolling over them or using the arrow keys. A button has been added to declutter map view when it is overwhelmed by noodles and apsis or node markers. A bug has been fixed whereby the camera spinning wildly when hovering over the UI of some mods. The issue of map view markers jumping around as the trajectory changes has been improved, though likely not entirely solved.  See the change log for more details. 2022-06-29 For the new moon (lunation number 278), the new release (Hesse) is out. All Principia windows now have a close button in the upper-right corner. A crash has been fixed that would occur when loading a save if vessels made frequent short burns (for instance due to RCS).  See the change log for more details. 2022-05-30 For the new moon (lunation number 277), the new release (Ἥρων) is out. Nothing new this time; we have been investigating the possibility of computing and displaying the equipotential lines.  See the change log for more details. 2022-04-30 For the new moon (lunation number 276), the new release (Hermite) is out. The rotation of vessels is now adjusted using Davenport’s Q method, instead of the least rotating part of the vessel; this is not noticeable in most circumstances, but might yield more realistic physical effects for vessels on which large forces (notably, aerodynamic) are exerted. Performance has been slightly improved. Thanks to @rnlahaye for helping with the investigation of an incident in the macOS build.  See the change log for more details. 2022-04-01 For the new moon (lunation number 275), the new release (Heine) is out. Thanks to @rnlahaye for contributions improving the performance of the mechanism that rebuilds histories. A save corruption bug which would lead to crashes in map view or when selecting a vessel in the tracking station has been fixed.  See the change log for more details. 2022-03-02 For the new moon (lunation number 274), the new release (Hausdorff) is out. Thanks to @rnlahaye for contributions improving the performance of operations on trajectories on macOS. No new features in this version beyond rnlahaye’s contributions; we have been working on some cleanups and investigating bugs.  See the change log for more details. 2022-02-01 For the new moon (lunation number 273), the new release (हरीश चंद्र) is out. Support for KSP 1.12.3 has been added. Load times of saves with old vessels (especially ones in low orbits) have been improved by reducing save file size (specifically making the histories more compact), fixing the long-standing issue #2400. Note that trajectories computed prior to upgrading to हरीश चंद्र will not be made more compact; only trajectories computed from its installation onwards will be compact. Load times of saves with many flight plans have been improved by deferring the reconstruction of flight plans until they are actually needed. The trajectories drawn in map view are now correctly hidden by terrain, instead of being cut off at sea level regardless of topography. The performance of trajectory plotting has been improved. Thanks to Quadrupole, @Al2Me6, @lpgagnon, and @scimas for reporting bugs in test versions of this release. Thanks to @rnlahaye for contributions improving the performance of some operations on trajectories. See the change log for more details. 2022-01-02 For the new moon (lunation number 272), the new release (Hardy) is out. Russian localization has been added; thanks to @von Kerman for contributing the translation and answering an endless stream of questions on the grammar of Russian. An issue has been fixed which led to slow camera rotation in the plotting frame if the active vessel was at a low altitude. A crash has been fixed which would occur when drawing trajectories without the UI having ever been shown since KSP was started. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2021-12-04 For the new moon (lunation number 271), the new release (Hamilton) is out. A memory leak that led to visual anomalies has been fixed; A performance issue with text-heavy windows, in particular the reference frame selector, has been fixed. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2021-11-04 For the new moon (lunation number 270), the new release (Halley) is out. Nothing new this time; we have been working on changes to the internal representation of vessel trajectories, but this is not ready yet. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2021-10-06 For the new moon (lunation number 269), the new release (Hadamard) is out. Some bugs reported by @Bellabong and @lpgagnon have been fixed. The duration parser is a little more lenient. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2021-09-07 For the new moon (lunation number 268), the new release (Haar) is out. The reference frame selector has been revamped to take up less space, allow quicker switching between arbitrary frames, and provide better explanations of the uses of the various frames. Thanks to @Al2Me6 for translating the new UI to zh-CN, and to @Zaikarion for linguistic help. Celestial-specific terminology has been added (perigee instead of Earth periapsis, lunar orbit instead of Moon orbit, etc.). Principia is localized in French. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2021-08-08 For the new moon (lunation number 267), the new release (Grothendieck) is out. Support for KSP 1.12.2 has been added. A save compatibility bug has been fixed. Saves created with Cardano or later should now be readable. An error in terminology in the Chinese translation has been corrected. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2021-07-10 For the new moon (lunation number 266), the new release (Grossmann) is out, fixing a couple of bugs reported by @Flibble and @Al2Me6. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2021-06-10 For the new moon (lunation number 265), the new release (Gröbner) is out. It addresses one part of #2400, namely the lag on scene change far from 1951 in the absence of vessels. This means that @scimas’s custom initial states are no longer needed for late-starting games. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2021-05-11 For the new moon (lunation number 264), the new release (Green) is out, fixing a few bugs (two crashes and a temporary but potentially very long freeze). See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2021-04-12 For the new moon (lunation number 263), the new release (Grassmann) is out. Support for KSP 1.11.2 has been added. The mechanism for overriding the version check so as to try new versions before we support them has been documented. Note that no support will be provided when this override is used. Some strings were untranslated in the Chinese version; this has been fixed. Thanks to @WC12366 for this contribution. A bug leading to steadily increasing memory usage up to crashing out of memory (#2919), reported by @Al2Me6 and @hxl11211, has been fixed. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2021-03-13 For the new moon (lunation number 262), the new release (Goldbach) is out. Performance has been significantly improved, especially on macOS. Thanks to @rnlahaye for this significant contribution. A bug found by @Robot_V1, which affected the handling of some aircraft, was fixed. The Chinese localization was improved. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2021-02-11 For the new moon (lunation number 261), the new release (Gödel) is out. Support for KSP 1.11.1 has been added. Principia is localized in simplified Chinese. Thanks to @CindyRIng for this significant contribution, and to @Zaikarion for helping with linguistic questions. Some crash-inducing bugs have been fixed. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2021-01-13 For the new moon (lunation number 260), the new release (Germain) is out. Support for KSP 1.11.0 has been added. The orbital analysis of the final trajectory is now available in the flight plan, making it possible to plan accurate orbital insertions and corrections. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2020-12-14 For the new moon (lunation number 259), which is a total eclipse, the new release (Гельфонд) is out. The orbit analyser now provides a short description of the current orbit, e.g., “highly eccentric semisynch. Earth orbit”. The trajectory colours can now be configured, thanks to a contribution from @Flibble (#2816). See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2020-11-15 For the new moon (lunation number 258), the new release (Гельфанд) is out. Performance of operations based on iteration over trajectories has been improved thanks to a contribution from @rnlahaye. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2020-10-16 For the new moon (lunation number 257), the new release (Gauss) is out. A bug that would occasionally lead to crashes when parts exploded has been fixed (#2716). See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2020-09-17 For the new moon (lunation number 256), the new release (Gateaux) is out. Support for 1.10.1 has been added. Note that the behaviour of Principia in the presence of comets is hard to test; users who encounter problems when comets are present are invited to report bugs. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2020-08-19 For the new moon (lunation number 255), the new release (Galois) is out. It is now possible to insert and delete manœuvres in the flight plan; in particular, this makes it possible to insert correction manœuvres after rebasing. Manœuvres can be collapsed and expanded, making it easier to manage flight plans with many manœuvres. A bug involving incorrect thrust when planning RCS manœuvres was fixed. Thanks to @Flibble for contributing this fix. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2020-07-20 For the new moon (lunation number 254), the new release (Gallai) is out. As previously announced, this release dose not support KSP 1.7.3 and earlier. A rebase button has been added to the flight plan, to take changes to the actual trajectory into account without having to recreate the flight plan. Altitude-related information has been added to the orbit analyser. A number of bugs have been addressed: EVA collision leading to absurd movement, EVA parachutes being broken, vessels disintegrating at absurd speeds, vessels deforming when coming out of warp. See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2020-06-21 For the new moon (lunation number 253), the new release (Galileo) is out. The exceptions raised by the external API for other KSP mods now include an error message. Miscellaneous bugs have been fixed (most notably, the centre of mass offsets are now taken into account). See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.9.1 & 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. This is the last release to support KSP 1.5.1, 1.6.1, and 1.7.x, as Realism Overhaul and Real Solar System now support 1.8.1. 2020-05-22 For the new moon (lunation number 252), the new release (Fuchs) is out. The issues with rotation (uncontrolled spin-up, jerky motion, oscillations, etc.) introduced in Frobenius and Fubini have for the most part been solved. We are aware of one remaining case of aberrant spin-up, reported by @scimas, but this seems to be a very rare issue at this point. Prior to ignition, the manœuvre node marker on the navball for guided burns now points to the orientation at ignition, instead of following the current Frenet frame. This is more useful for manual burns (the spacecraft can be oriented correctly prior to ignition, instead of having to be guided even before the manœuvre starts). Perhaps more importantly, in conjunction with change MuMech/MechJeb2#1264 (available in MechJeb dev builds ≥ 958), this means that MechJeb can execute all Principia manœuvres. New APIs have been added for use by @Sir Mortimer’s KerbalismContracts. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.9.1 & 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. This is the last release to support KSP 1.5.1, 1.6.1, and 1.7.x, as Realism Overhaul and Real Solar System now support 1.8.1. 2020-04-23 For the new moon (lunation number 251), the new release (Fubini) is out. Support for 1.9.1 has been added. The flight planning and orbit analysis window are now available in the tracking station, bringing into line with map view. Some changes have been made to mitigate the aforementioned issue #2519. Wild spin no longer seems to be an issue, however some unexpected oscillations arise under some circumstances. We will keep investigating this issue. Some issues that would cause crashes have been resolved. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.9.1 & 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2020-03-24 For the new moon (lunation number 250), the new release (Frobenius) is out. After nearly a year of work and 96 pull requests, Principia now enforces the conservation of angular momentum, as had been alluded to earlier. This means, among other things, that: the long-standing bug #1639, reported by @Damien212 in 2017, whereby the orientation of vessels changed when they underwent an SoI transition, is resolved; vessels will rotate as rigid bodies, following Euler’s equations, in time warp; in particular they may exhibit the Джанибеков effect in time warp, as illustrated in the short video below; changes in mass distribution within the vessel, e.g., due to fuel transfer, will affect the angular velocity, as illustrated in the short video below. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2020-02-23 For the new moon (lunation number 249), the new release (Frenet) is out. Nothing new this time; we have been working on the preservation of angular momentum, but it is not quite ready yet. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2020-01-24 For the new moon (lunation number 248), the new release (Frege) is out. Celestial histories are now displayed as far as requested in the past (if available), rather than being limited to the time of launch. Miscellaneous bugs have been fixed (perhaps most visibly, the wild camera spin in the pause menu introduced in Fréchet).  See the change log for more details; note in particular the known issue with map view camera rotation when showing the menu. We support two sets of versions of KSP: downloads are available for 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2019-12-26 For the new moon (lunation number 247), the new release (Fréchet) is out. Support for KSP 1.8.1 has been added. The camera is oriented in map view and the tracking station so that the horizontal is the reference plane of the selected plotting frame. Further, the camera rotates with the plotting frame, so that the plotted trajectories do not rotate as time passes.  See the change log for more details; note in particular the known issue with map view camera rotation when showing the menu. We support two sets of versions of KSP: downloads are available for 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2019-11-26 For the new moon (lunation number 246), the new release (פרנקל) is out. Principia now plots the trajectories of celestial bodies. This closes an ancient feature request (#942, March 2016), and builds up on a lot of intervening work; in particular, this is based on the method for trajectory plotting introduced for vessels in Чебышёв (August 2017). The history length setting now hides the history instead of forgetting it; this means that you can shorten histories when they are visually distracting, while retaining the ability to bring them back when you want an overview of your mission. It also uses the same duration format and selector used elsewhere in the Principia UI instead of seconds in scientific notation.  See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2019-10-28 For the new moon (lunation number 245), the new release (Fourier) is out. Two crashes involving flight plan edition (one reported by @Neph) have been fixed.  See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云 2019-09-28 For the new moon (lunation number 244), the new release (Fibonacci) is out. An orbit analysis tool has been added which computes mean elements and orbit recurrence properties. This has been in the works since February; more features will be added at a later date, e.g., mean solar times of ascending nodes (for controlling sun-synchronicity). See below for a screenshot of the orbit analysis tool in action on a Молния orbit. The tool is fairly complex; documentation will be provided soon. A crash reported by @Delay has been fixed. A dependency issue that would prevent Principia from starting has been fixed.  See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2019-08-30 For the new moon (lunation number 243), the new release (del Ferro) is out. Higher degree and order gravity models have been added for Mercury, Venus, Mars, Jupiter, Saturn, Uranus, and Neptune; satellites of these planets will now have more realistic motion (this change only takes effect on new saves) Some bugs reported by @Sir Mortimer, @scimas, and @Kobymaru have been fixed.  See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2019-08-01 For the new moon (lunation number 242), the new release (Ferrari) is out.  Support for KSP 1.7.3 has been added. Some bugs reported by @scimas have been fixed.  See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2019-07-02 For the new moon (lunation number 241), the new release (Fermat) is out. Support for KSP 1.7.1 and 1.7.2 has been added; as previously announced, this release does not support KSP 1.3.1 and 1.4.x. A long-standing feature request (#1936, opened by @王小谦同学) has been addressed: all manœuvres of a flight plan can be edited, instead of only the last one. Manœuvres now take the thrust limiter into account (#2128, opened by @Kinexity). See the change log for more details. For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2019-06-03 For the new moon (lunation number 240), the new release (Fatou) is out. Support for KSP 1.7.0 has been added. Note that 1.7.1 was released after we built the release, so it is not supported. Also note that we have no special support for the new orbital information display, so that, like MechJeb or Kerbal Engineer Redux, it will display the largely-useless osculating elements at current time instead of mean elements for some appropriate theory. Further, note that we have no special support for the new manœuvre node editor, so that it will likely be unusable. This is the last version to support KSP 1.3.1 and 1.4.x, as Realism Overhaul and Real Solar System now support 1.6.1. The next version will only support 1.5.1 and up. The ascending and descending nodes are now shown with respect to the equator in the body-centred, body-fixed frame, and in the body-centred inertial frame if the central body is sufficiently close (#1841). Many bugs have been fixed that were introduced with the UI changes in Fáry and during the underlying restructuring of the UI code in Fano. See the change log for more details. We thank @Miracle Magician for reporting a severe bug that would otherwise have been introduced in this release. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, 1.6.1, 1.7.0, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云. 2019-05-04 For the new moon (lunation number 239), the new release (Fáry) is out. The UI now scales according to the KSP UI scale settings, and has been made a little more compact; those flight plan settings that are controlled by a slider can now also be edited by text entry (this includes the Δv components and timing of manœuvres); the TRAPPIST-1 patch has been updated for @GregroxMun’s SLIPPIST-1 v0.7.x.  See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, & 1.6.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2019-04-05 For the new moon (lunation number 238), the new release (Fano) is out. The predictions are now computed asynchronously, making long predictions usable; this is particularly noticeable in the vicinity of bodies with complex gravity models, such as the Earth and Moon in RSS. Some bugs involving map view markers have been fixed. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, & 1.6.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2019-03-06  For the new moon (lunation number 237), the new release (Euler) is out. Issue #2072, introduced in Erdős, which manifested as free fall unaffected by parachutes or engines below 8.4 m altitude in RealSolarSystem (leading to rough splashdowns), has been resolved. An API has been added to allow @Jim DiGriz’s guidance algorithms to access the geopotential coefficients; see #2074. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, & 1.6.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2019-02-04  For the new moon (lunation number 236), the new release (Εὐκλείδης) is out. Support for KSP 1.6.1 has been added. This release fixes a long-standing issue (reported in November 2017 by @Agustin, in June 2018 on GitHub as #1868 by @scimas, and by @Delay in January 2018) where, under some circumstances, the SAS would not point the ship towards the markers (it would point the ship towards the position that the markers would have in stock instead). It also fixes a relatively rare issue involving fragments of vessels getting close to the centre of a celestial on reentry (#2056). See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x, 1.5.1, & 1.6.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2019-01-06 For the new moon (lunation number 235, partial eclipse), the new release (Εὔδοξος) is out. We have added an enhanced selenopotential in RSS, complete to degree and order 30; this means that the moon now has mascons, making some low lunar orbits unstable. Note that you will only get the new selenopotential when making a new save. As a concrete example, consider this screenshot of a lunar orbit, whose periapsis decreases by 3400 m over the course of 18 orbits because of the irregularities of the Moon's gravitational field (another dozen orbits later, the spacecraft collides with the Moon, between craters Spencer Jones and Spencer Jones W). Saves are now encoded in base64 instead of hexadecimal, making them smaller and faster to load. We have rerun the TRAPPIST-1 optimization, this time with a small enough integration time step allowing us to accurately model the dynamics of the system. Thanks to @AloE for spotting the incorrectly-timed transits. The resulting system has residuals similar to those reported by Grimm et al., with χ² = 358.79 vs. χ² = 342.29 in the paper. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x & 1.5.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-12-07 For the new moon (lunation number 234), the new release (Erdős) is out. Support for realistic geopotential modeling at arbitrary degrees is finally available, with a 10th-degree model of the Earth geopotential in RealSolarSystem; more advanced modelling for other bodies (Moon, Mars, etc.) will be added in future versions. #1955, a performance issue on macOS (continuation of #1908), was resolved by using a different synchronization library. The issue reported by @AloE above (#1999) has been temporarily addressed by using the same integrator configuration that was used for the optimization. We will redo the optimization with a more appropriate configuration in a future version, as this issue likely indicates that the integrator had not quite converged. see the change log for more details.  We support two sets of versions of KSP: downloads are available for 1.4.X & 1.5.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-11-07 For the new moon (lunation number 233), the new release (Ἐρατοσθένης) is out. Support for KSP 1.5.1 has been added. We working on extending geopotential models beyonds oblateness (mascons etc.), but that is not yet ready; see the change log for more details.  We support two sets of versions of KSP: downloads are available for 1.4.x & 1.5.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-10-09 For the new moon (lunation number 232), the new release (Διόφαντος) is out. Nothing new this time; we have been working on improved gravity models, but they are not ready yet. See the change log for more details.  We support two versions of KSP: downloads are available for 1.4.5 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-09-09 For the new moon (lunation number 231), the new release (Descartes) is out. Important note for mac users: Principia no longer supports macOS El Capitan, as that version is no longer supported by Apple. We now require macOS Sierra or later. As a consequence, there should be noticeable performance improvements for macOS users. We have added generalized Runge-Kutta-Nyström methods, which allow for a more accurate prediction of burns that are fixed in the Frenet frame. See the change log for more details.  We support two versions of KSP: downloads are available for 1.4.5 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-08-11 For the new moon (lunation number 230), the new release (Desargues) is out. No new features in this version beyond the 1.4.5 upgrade, as we have been on vacation.  See the change log for more details.  We support two versions of KSP: downloads are available for 1.4.5 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-07-13 For the new moon (lunation number 229), the new release (Δημόκριτος) is out. Vessels are now managed by Principia when they are in the atmosphere, which means that atmospheric flights have Principia histories and predictions in map view. The “Trappist-1 for Principia” mini-mod has been improved to better reflect the physical properties of the celestials. See the change log for more details. We support two versions of KSP: downloads are available for 1.4.4 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-06-12 For the new moon (lunation number 228), the new release (Dedekind) is out. This release fixes a memory leak which could lead to increases in memory usage to the tune of 1 GiB / min when using the flight plan. Further, we are releasing a mini-mod that turns @GregroxMun's SLIPPIST-1 into the real TRAPPIST-1 system; the 7-planet resonant chain of that system makes it interesting from the perspective of n-body gravitation. The configuration is computed by transit-timing variation based on the transit timings from the recently-published paper The nature of the TRAPPIST-1 exoplanets by Grimm et al. See the change log for more details. We support two versions of KSP: downloads are available for 1.4.3 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). 2018-05-15 For the new moon (lunation number 227), the new release (Darboux) is out. This release: uses a new implementation of the cube root which is more accurate and faster than most, as part of an ongoing effort for Principia to use its own implementation of elementary functions; adds Gipfeli compression and arena allocation when saving and loading, reducing save file size by about 2.5× and scene load times by about 2× for large saves; adds support for KSP 1.4.3. See the change log for more details. We support two versions of KSP: downloads are available for 1.4.3 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). Darboux does not support KSP 1.2.2, as Realism Overhaul and Real Solar System now support 1.3.1. 2018-04-16 For the new moon (lunation number 226), the new release (Cramer) is out. This release: fixes a bug which caused manoeuvre nodes to jump at the time of ignition, especially on ejection and capture burns. Thanks to @Kobymaru and @EstrelaGaliza for reporting and helping diagnose this bug. adds support for KSP 1.4.2. Note that you may need to install a newer C++ runtime; see the change log for more details. We support three versions of KSP: downloads are available for 1.4.2, 1.3.1, and 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). Cramer will not support 1.4.3, as Principia has special handling to work around ladder-related bugs, so we will need to test the new release to see if changes are needed. This is the last release to support KSP 1.2.2, as Realism Overhaul and Real Solar System now support 1.3.1. 2018-03-17 For the new moon (lunation number 225), the new release (Coxeter) is out. This release: uses SSE2 intrinsics for improved performance; addresses numerical stability issues in the Jool system reported by @Eriksonn; introduces an API for @Jim DiGriz's guidance algorithms; introduces support for KSP 1.4.1, thanks to @awang. See the change log for more details. We support three versions of KSP: downloads are available for 1.4.1, 1.3.1, and 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). 2018-02-15 For the new moon (lunation number 224), the new release (Cohen) is out. The ephemerides are now computed using the Estrin method for polynomials expressed in the monomial basis instead of the Clenshaw method for polynomials expressed in the Чебышёв basis, improving the performance. See the change log for more details. Again, we support two versions of KSP: downloads are available for 1.3.1 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). 2018-01-17 For the new moon (lunation number 223), the new release (Clifford) is out. A bug in the implementation of DoublePrecision that caused a test to fail on Macintosh, as reported by @awang and @Jim DiGriz, was fixed. Solar system designers can now pick an integrator more suited to their solar system, as requested by @GregoxMun whose surprisingly stable Alternis Kerbol Rekerjiggered does not fare well with Principia's default integration parameters, which were chosen (in Cartan) to work for stock KSP and the real solar system. See the change log for more details. Again, we support two versions of KSP: downloads are available for 1.3.1 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). Thanks to @awang for contributions (clang warning cleanups) during this lunation. 2017-12-18 For the new moon (lunation number 222), the new release (Christoffel) is out. Vessels no longer pass through a planet unharmed at sufficiently high timewarp like in stock, and are detected by Principia as having collided with the planet, and are destroyed. In particular, this resolves the crash that occurred in 陈景润 when a vessel went through a planet unscathed (#1628, reported by @awang and @John FX). Support for KSP 1.3.0 has been dropped. We support two versions of KSP: downloads are available for 1.3.1 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). See the change log for more details. 2017-11-18 For the new moon (lunation number 221), the new release (陈景润) is out. This release solves a longstanding issue (#228) with the way trajectories were stored, which caused spikes or loops in histories computed at high timewarp. Again, we support three versions of KSP: downloads are available for 1.3.1, 1.3.0 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). See the change log for more details. Thanks to @awang for contributions (fixed a UI bug) during this lunation. 2017-10-19 For the new moon (lunation number 220), the new release (Chasles) is out. A long-standing bug, #1413, initially reported by @maccollo, and also reported by @Cristi, @DaMichel, @goldstarstickergiver, @lyttol, @nanomage, @Parafaragarmus, @rsparkyc, et al., was fixed. This bug prevented landing on peaks of some bodies (notably Minmus) as well as on the Moon in the current version (12) of RealSolarSystem. The fix involves making Principia handle vessels even when KSP's physics operate in a rotating reference frame, all the way down to the ground; as soon as a Kerbal jumps on Minmus, Principia computes its trajectory. Note that vessels within an atmosphere are unaffected; we intend to also handle these down to the ground, but this requires an update in @ferram4's FAR since we want to remain FAR-compatible. Further, Principia now supports KSP 1.3.1; downloads are available for 1.3.1, 1.3.0, and 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). See the change log for details. Thanks to @awang for contributions (clang warning cleanups) during this lunation. 2017-09-20 For the new moon (lunation number 219), the new release (Cesàro) is out. The histories of the vessels are now computed in parallel, speeding up high timewarp on multi-core processors. A bug was fixed that caused a crash when crashing two vessels into each other. Again, we support two versions of KSP: downloads are available for 1.3 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). See the change log for details. 2017-08-21 For the new moon (lunation number 218), which is a total eclipse, the new release (Чебышёв) is out. The speed of the plotting of histories has been improved by about an order of magnitude. The slow plotting in previous versions was responsible for most of the slowdown in map view. Further, the predictions are now plotted smoothly even when they are integrated with a large tolerance. The flight plan now supports burns that guide themselves to follow the Frenet trihedron, e.g., tracking the tangent (prograde), or the binormal (the normal to the orbital plane). Select "Inertially fixed" in the flight planner to use an unguided burn instead, e.g., for spin-stabilized burns. For the first time, Principia supports two versions of KSP: downloads are available for 1.3 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). A couple of bugs reported by @panourgue and @scimas were fixed. See the change log for details. Thanks to @Iskierka and @Jim DiGriz for testing the Linux and Macintosh builds respectively. Note to RSS users: Principia correctly simulates the motion of the moon, so the eclipse occurs as expected when using Principia, even after more than 66 years of numerical integreation, see below. Conversely, without Principia, the Moon's motion cannot be simulated with the requisite accuracy to get correct eclipses, since it is a heavily perturbed orbit. 2017-07-23 For the new moon, the new release (Cayley) is out. It brings trajectories in map view, an update reminder driven by the Moon, a fix to a whole class of off-by-one physics bugs, and further bugfixes. Further, the build includes a binary for Macintosh, thanks to @Jim DiGriz. Note that the version string on Macintosh will mention Cayley-4 instead of Cayley-0. This will be resolved in future versions. See the change log for details. 2017-06-24 For the new moon (lunation number 216), the new release, Cauchy, is out. It brings relative speed markers on nodes, the unification of navball speed mode and reference frame selection, and displaying the trajectory of the target vessel if it moves in the plotting frame. This addresses requests by @lawndart, @maccollo, and @scimas. This release fixes: physics bugs: 1307 reported by @Damien212 and @maccollo, 1404 reported by @Bocian and @lawndart, 1415 reported by @scimas, 1421 reported by @NathanKell and @rsparkyc; a UI bug, 1402, reported by @lawndart and @maccollo; crashes: 1422 reported by @maccollo, 1441 reported by @rsparkyc. See the change log for details. NOTE: due to a forum mishap (stares at @technicalfool ) this thread has changed address, and all followers have been lost; if you had bookmarked the thread or followed it, you may want to do so again. 2017-05-25 For the new moon (lunation number 215), the new release, Catalan, is out. It brings no new features, but fixes a number of bugs and improves the underlying libraries. See the change log for details. 2017-04-26 For the new moon (lunation number 214), the new release, Cartan, is out, bringing with it a utility for rendezvous: the target local vertical local horizontal reference frame. There is a guide to low orbit rendezvous using the new reference frames (screenshots to be added in the near future). See the change log for details. Please read the concepts page carefully, it has been expanded since Cardano. Remember to also have a look at the FAQ if you have a question. Thanks again to @Iskierka for testing the Linux build. 2017-03-28 For the new moon (lunation number 213), the new release, Cardano, is out, bringing with it axial tilt, new reference frames, and timewarp-independent free fall. It marks the beginning of lunar releases. See the change log for details. In particular, note that Cardano is save-incompatible with Cantor. Please read the concepts page carefully, it has been expanded since Cantor. Thanks to @Iskierka for testing the Linux build. 2016-08-13 Cantor is out. This version is mostly the same as بوژگانی (see the change log), the intent is to make sure it is as stable as بوژگانی was: this is the first broadly available release, with a link to binaries outside the IRC channel (see the OP). In the meantime, progress has been ongoing (note that this is about a future release, Cantor contains none of the features below). Regarding our internal libraries, we have clarified the way we handle time (which is always an extremely confusing thing), with our Instant type aligned with Temps Terrestre (TT), and support for date literals in TT, Temps Atomique International (TAI), Coordinated Universal Time (UTC), and UT1 (based on the rotation of the Earth). This allows us to specify dates more cleanly in our tests. We tested the difference between the orbits of Mercury predicted by our ephemeris and by JPL's over a century, and we find the expected error in perihelion precession due to general relativity. On the side of flashier features, we seem to be well underway to having working axial tilt, by tilting universe the current main body (with terrain) is aligned with the axis used by KSP, and rotating the other ScaledSpace models appropriately; in a future release of Principia, the Jupiter, Saturn, and Uranus systems should look much nicer, with the planet properly aligned with its satellites. 2016-06-26 بوژگانی is out. A change log can be found here. 2016-05-20 Burnside is out. A change log can be found here. 2016-05-05 Буняковский is out. A change log can be found here. 2016-02-24 There is a bug in Buffon (2016022220-Buffon-0-g0455d0cb0e4b0b584a84caf40520cf7993903e0c) that causes a crash when starting a new save with RSS (loading an existing save works fine). The hotfix "2016022220-Buffon-12-g1298cffba22d90119bd59e9933a9ef261922a423" (let's call it "Buffon + 12") resolves that, so if you run into this issue just go back to the IRC channel to get the latest build, it will be Buffon + 12. There are no other changes between Buffon and Buffon + 12. 2016-02-22 Buffon is out, you can get it by asking on IRC (#principia on EsperNet), as usual. Changes: The integrators now limit the number of steps they perform, and terminate if their step size vanishes. This avoids issues where the plugin would hang when the trajectory would accidentally get very close to the centre of a celestial body or spend a long time in a low orbit. A use-after-free bug has been fixed which caused a variety of crashes (#872, #881, #889, #896) when the historical trajectory was shortened in a way that would cause it to start after the beginning of the flight plan. The version identifier of the plugin is now displayed in the UI to make it is easier to assert what version is running. A verbosity option has been added to the journalling which makes it easier for us to reproduce crashes. The first two items above are illustrated by the following two reports. For more details see all 19 pull requests between Brouwer and Buffon. 2016-02-11 Some clarifications regarding reference frames and flight planning. 2016-02-09 Brouwer is out, you can get it by asking on IRC (#principia on EsperNet), as usual. User-facing features: The whole Frenet trihedron is now displayed in the correct reference frame when "fix navball in plotting frame" is selected. The initial state (and thus the evolution) of the system is now deterministic even when not using RSS. Tidally locked bodies no longer spin back and forth madly (on the other hand, they may not be tidally locked if their mean period differs from their Jacobi osculating period). When using stock, the Jool system is modified, cancelling the apocalypse. Specifically, we make the inner Jool system nonresonant, since we have been unable to replicate the results (Manley, priv. comm.) according to which some interpretations of the orbital elements yielded a stable Laplace resonance, despite systematic searches of the Jacobi osculating elements. In addition, at Scott Manley (@illectro)'s and @UmbralRaptor's suggestion, we put Bop in a surprisingly stable, though highly precessing, retrograde orbit. The modified system is stable for upwards of a century. Flight planning has been implemented. Modder-facing changes: When a Cartesian initial state cfg is not given, the KSP orbital elements are interpreted in a hierarchical osculating Jacobi fashion; for instance, the orbital elements of Jool are the osculating elements at game start of the orbit of the barycentre of the Jool system around the barycentre of the (sun, moho, eve, gilly, kerbin, mun, minmus, duna, ike, dres) system; the elements of Laythe are the osculating elements at game start of the orbit of Laythe around Jool; the elements of Vall are the osculating elements at game start of the orbit of Vall around the Laythe-Jool barycentre. Optimizations: The Windows build now uses profile-guided optimization (we estimate that this improves performance by ~20%); in theory this could be extended to other platforms. The evaluation of the Чебышёв series has been significantly optimized. @sarbian made trajectory rendering faster (as he pointed out, there is still lots of room for improvement). Other features: Everything that crosses the interface can now be journalled if the right flag is set, allowing us to replay the C++ side of a session; this is useful for tracking down tricky bugs, and it enables profile-guided optimization. Highlights of miscellaneous library changes; beware, this gets technical: In order to get the full Frenet trihedron, which in turn was needed for manœuvres, since the Δv is defined in the Frenet frame at the point of ignition, geometric acceleration (the acceleration of a free-falling trajectory) in any reference frame was needed. To that we created two abstractions, RigidMotion, the derivative of a RigidTransformation, and DynamicFrame, the definition of an arbitrary reference frame. The navigation frames (the frames in which the trajectory is drawn, or with which the manœuvres are defined) implement that (see BodyCentredNonRotatingDynamicFrame and BarycentricRotatingDynamicFrame). In order to interpret the orbital elements of KSP in the hierarchical Jacobi fashion described above, support was added for Kepler orbits (implementation), Jacobi coordinates, and hierarchical systems. Discrete trajectories were reworked, with a heavy dose of CRTP. In preparation for the surface frame in the future, RotatingBody was added. The C++ interface headers and C# extern declarations were repetitive and error-prone, this was exacerbated by the addition of journalling code and replaying code, so a generator was written to produce all of that from an annotated proto. @UmbralRaptor contributed some tests of lunar eclipse timings. For both Kepler orbits and lunar eclipse timings, a simple root finder was needed, bisection does the job for now. A bibliography was written, at @UmbralRaptor's request (it is somewhat out of date). SolarSystem, a class for initializing ephemerides from protobuf text format configuration files for testing purposes was written. A script for generating the initial state configuration files from the emails sent by JPL's HORIZONS system was written (the gravity model configuration file is hand-curated). An utility turns the protobuf text format configuration files into KSP ModuleManager configuration files for RSS support. Various geometric utilities were added: angles (implementation), spherical coordinates (more are needed). More C++11/14 features were used as they became available (for instance, the units are now constexpr), in addition we now use std::experimental::optional. C++14-related improvements were made to not_null. For more details, see all 195 pull requests between Bourbaki and Brouwer. 2015-08-16 Bourbaki is out, you can get it by asking on IRC (#principia on EsperNet), as usual. Please bear in mind that the channel operators may be away from keyboard, so you should wait until you're noticed (it also helps to say the name of the channel operators since that pings them). As of 2015-08-16T15:38Z, the build for Win32 is ready, we're waiting for Norgg and armed_troop for the Linux and Macintosh builds respectively. Note that you should read the FAQ before installing principia. Rough changelog: Reimplemented integrators: the symplectic Runge-Kutta-Nyström integrator was reimplemented more cleanly, an embedded explicit Runge-Kutta-Nyström integrator was implemented. Abstractions for differential equations were created. Ephemeris: the celestial bodies are integrated on their own, with their own (much larger) timestep (45 min); their trajectories are then fitted using чебышёв series, yielding continuous trajectories. This means that when there are no vessels (including asteroids, see the FAQ), timewarp at very high speed (6'000'000x was tested in RSS) is smooth. The predictions are computed using an adaptive step size, so they're faster and less fiddly (you still get a tolerance setting, but it doesn't need as much attention as the step size setting; the step size will shorten near periapsis and lengthen near apoapsis on its own). The histories are still in fixed steps of 10 s, that will likely change in Brouwer, since it is one of the biggest performance costs now. There is an initial configuration for Real Solar System: the planets will start in the right places as given by the JPL HORIZONS service, and they are given gravity models using the freshest data available (Vesta's model is from Dawn data, some Cassini data gets used). Please note the RSS-specific recommendations in the FAQ. A side effect of that is that the moon becomes far more accurate: since the motion of the moon is very much a 3-body problem, it cannot be accurately represented in RSS alone. In particular, real-life eclipses can be observed in principia + RSS (please note the unexpected inaccuracy mentioned in the FAQ). This initial configuration also includes J2 for the Sun, the planets, the Moon, and Vesta, so the resulting effects are felt (precession of Earth orbits, the possibility of heliosynchronous orbits, etc.). Bourbaki is save-compatible with Borel, for RSS users, please note that unless you reset the plugin, the new initial state and gravity model configuration files will not be taken into account. 2015-05-07 The new version, Borel, is out (you can get it on IRC, as previously; the same caveats apply). Rough changelog: ported to 1.0.x (that only took a couple of lines); custom navball settings, so that the navball can be fixed in the reference frame in which the trajectory is plotted; the IVA navball is unaffected; when using the custom navball, the prograde/retrograde vectors are now in the correct reference frame, consistent with what is shown is map view; the rest of the Frenet trihedron (the radial and normal vectors) are unaffected at the moment and will be fixed in another version; fixed a few bugs (the tetrydsbug, the melonbug, the thutmosebug); less memory-hungry; added a setting to clip histories; added a toolbar button to show/hide the UI; the UI now acknowledges the F2 key; other things that I forgot. Moreover, Norgg and armed_troop have made good progress on Linux 64-bit and Macintosh 32-bit builds respectively, so if you're on these platforms you can go on IRC and ask for a build or for build instructions. With Windows 32-bit, Linux 64-bit and Macintosh 32-bit, we should be covering most users (I don't think it's worth doing a Linux 32-bit build). 2015-03-22 Serialization has been implemented, and rudimentary predictions have been added. The predictions are currently using the same integration method (McLachlan and Atela's 1992 optimal 5th order method), with the same splitting of the Hamiltonian (kinetic + potential energy), this is somewhat usable but unacceptably slow. I am currently implementing as many symplectic integrators as I can find in order to compare them, and I will also be comparing various splittings (as as nonsymplectic methods in use for computing ephemerides). I will probably write a post about these at some point (probably an advanced one, rather than an elementary introduction, this is quite a complicated topic). It seems that there is some interest in builds of Principia, no matter how unstable or slow they may be. If you want to try out the current version of Principia (Bolzano) for the Windows 32-bit version of KSP, go the IRC channel linked below and ask me for a build (my nickname there is egg, or sometimes something of the form egg|<status>|egg). CAVEAT: The current version is not stable, it can corrupt or otherwise destroy saves, it has been known to crash, and predictions are horrendously slow. #principia IRC channel on EsperNet. 2015-01-22 The refactoring of the physics bubble has been done (and some tests have been added), as well as some cleanup in the C# adapter (including some performance improvements, a lot of the performance issues occur on the C# side since the implementation is a bit careless there). More refactoring occurred (use of a not_null template for non-null pointers). The next step on the path towards playability is persistence: the state of the plugin must be persisted so that we remember the states of the planets, the histories of the vessel trajectories, etc. (currently loading a save or reverting will result in either a crash or a loss of consistency due to the planets having moved around). Persistence of our types will be achieved using protocol buffers, stored in config nodes: we don't want to use KSP's config format directly, since we have lots of highly structured data and operate far from KSP's API it would be inefficient and clumsy. We'll probably also use protobufs for caching when implementing trajectory predictions later on. Some work has already been done in that direction. Here are some more screenshots, showing a flight from Kerbin to the Kerbin-Mun L4 Lagrange point (the reference frame for each screenshot is indicated in the "Traces of various description" window). antedated 2014-12-13 Support for intrinsic acceleration has been added. Refactoring will be needed, but it works, as demonstrated by the following plane change manÅ“uvre: 2014-11-07 Some work has been done on better abstractions for rendered trajectories, nothing significant yet (in particular there still is something in Õ(n) which could be in Õ(1), runs at each frame, where the constant factor involves evaluating trig functions, and n~10_000 is the number of rendered points, so that rendering trajectories in the barycentric rotating frame is slow), but some pretty pictures. This shows a vessel near the L5 point of the Kerbin-Mun system. In the first image, the trajectory of the vessel is displayed in the nonrotating reference frame centred on the Mun, in the second it is displayed in the nonrotating reference frame centred on Kerbin, and in all subsequent images it is displayed in the barycentric corotating reference frame of the Kerbin-Mun system. Work on intrinsic acceleration is ongoing. 2014-10-28 Code has been written to plot the trajectories in nonrotating body-centred reference frames (and barycentric corotating, not reviewed yet). While abstractions will have to be written to do that more cleanly and efficiently, this yields some pretty pictures. Caveat lector: While some of the following orbits may look very wild, bear in mind they are in non-inertial reference frames. Two of these wilder trajectories are followed by the same trajectory in a more pedestrian reference frame. In the Kerbin-centric non-rotating reference frame, they would all look like two or three elliptic orbits connected by strange segments where the perturbation by the Mun is to blame. The last picture below (in the barycentric corotating frame of the Kerbin-Mun system, that is, the unique frame in which the Kerbin-Mun barycentre as well as the line through Kerbin and the Mun are invariant) shows a trajectory that differs strongly from what stock KSP would have yielded: in stock this would have been a circular orbit around the Mun near the edge of its SoI. Instead it is a transfer to an eccentric Kerbin orbit, which is picked up by the Mun again after a while and ends with a crash on the Mun. With the addition of plotting, the C++ plugin has caught up with the features of the initial C# prototype. After the abstractions for plotting are written (we will add the remaining interesting reference frames in the process), the next step will be to take care of altering the trajectory when, e.g., engines are used. It is apparent that the C++ plugin is significantly faster, much more reliable, and easier to debug than the C# prototype (it is also correct; some hasty shortcuts were made in the prototype that resulted in unreliable initial states and other problems). 2014-09-30 Trajectory, an abstraction for a tree of trajectories that can be forked into child alternatives (useful i.e. for predictions, manoeuvre nodes, but also simply computations at different precisions), has been written (part of the physics namespace) The plugin has returned, first as a simple orbit-freezing plugin, then as a plugin that actually integrates the motion of vessels (only on-rails for the moment). Is does not plot yet, so it is still behind the C# prototype in terms of features, but it is significantly faster. As was previously mentioned, all calculations are done in a native assembly, called by P/Invoke via a (cdecl) interface. It should be noted that the plugin uses glog everywhere for logging (since logging from native code is needed). Of course, this means Principia will have its own log files (in <KSP directory>/glog/Principia, with a log of the last session in <KSP directory>/stderr.log. Another interesting aspect is that there will be no silent exceptions as in managed plugins, instead, the game will either segfault (when dereferencing an invalid pointer) or abort (SIGABRT) if a glog CHECK macro fails (on Windows the latter yields the "KSP.exe has stopped working" message). I have been informed by Sarbian et alii that this will result in Fun support. 2014-07-04 I wrote the second explanatory post, on Hamiltonian mechanics (PDF). Prerequisites are chapters 4, 8, and sections 11-4 and 11-5 of Richard Feynman's Lectures on Physics. The next post will be on symplecticity and the leapfrog integrator. 2014-06-27 The integrator (still a 5th order SPRK, same as in the C# prototype, the Saha & Tremaine stuff isn't here yet) has been implemented, tested and benchmarked (using a Windows port of google/benchmark) in C++, as well as the first level of abstraction above it, principia::physics::NBodySystem (header, body, test, header for test data, test data, test of test data (which is also a nice example of the use of principia::quantities and principia::geometry, benchmark (using the test data)). A significant change of plans has occured: As Unity uses the .NET Framework v2.0, it is not possible to use plugins compiled for the Framework v4.5. This means C++/CLI projects need to be compiled using the platform toolset v90 (from VS2008), rather than VS2013's v120. Of course v90 does not support C++11 nor C++14, so it is not an option for this code that strongly depends on C++11 features. As a result, we will keep using the C++11 codebase, compiling it to a native DLL, and using P/Invoke to call it from a C# adapter. The C# adapter will perform no calculations, only transmit data from KSP to the native plugin and apply the changes/render the trajectories returned by the plugin. A simple test P/Invoke plugin can be seen on the repository (header, body, C# adapter) and works in KSP. This means there will be separate x86 and AMD64 builds for each target operating system (Microsoft Windows and 57 varieties of Unix), possibly more if we decide to do specific optimisations for Intel chips (though ICC is not cheap). Moreover, this will allow a switch to clang in the near future, so that we can have saner error messages and better compliance with the standard. 2014-05-12 I now have a collaborator on Principia, https://github.com/pleroy (my father). This means the code gets reviewed and that development is faster. We have decided to completely switch to C++/CLI due to better test tools and useful language features. Most of the code will actually be written in standard C++, with the implementation inlined in header files, so that they are seen by the eventual C++/CLI managed assembly (If we were to use C++/CLI everywhere, we would need managed boundaries between the assemblies, which is quite inconvenient). As an added advantage, using standard C++ enables putting performance-critical parts into a native assembly if needed at a later time, without requiring a significant rework of the code. We have started switching to gmock, gtest and glog for mocking, testing and logging. These tools are more convenient and powerful than the Visual Studio testing framework and are open source, so that users of Visual Studio Express (which does not support Microsoft's testing framework) will be able to build and run tests if they want to. Here is the first test to be converted to gtest: https://github.com/mockingbirdnest/Principia/blob/master/geometry/sign_test.cpp. 2014-04-03 The Quantities library (C++) is pretty much done and tested. I am currently porting the C# Geometry assembly mentioned previously (now called CTSGeometry) to C++ in order to enable its use with these quantities. 2014-03-15 The Geometry assembly seems to be mostly feature complete, so I'll start writing tests tomorrow (Saturday) after changing a few access modifiers, replacing the ugly switch statements in Permutation by something nicer, and a few optimisations. See here for an overview of its features. 2014-03-04 I have investigated the feasibility of using other languages for KSP plugins: The following languages can be used on their own to write a plugin: C#(unsurprisingly), F#, C++/CLI (with no calls to native code). VB.NET can be used, but wrappers in one of the above languages are needed due to its case-insensitivity. Unity does not support mixed-mode DLLs, so calls to native code have to be made using DllImports in one of the above languages. I have started doing some refactoring since the sphaghettiness of the code was getting on my nerves. I have written strongly typed wrappers for the numerous reference frames spawned by KSP (direct vs. indirect, rotating vs. inertial, world vs. body-centric, etc.) as I have had numerous bugs due to a misplaced xzy, rotation, translation, scaling, inertial force etc. Of course, since KSP has the brilliant idea of using both direct and indirect reference frames, I needed distinct types for vectors, bivectors and trivectors (basically I had to strongly type Grassmann algebras; there can be no cross product, only wedge products, commutators and left and right actions of alternating forms---where is identified with through the inner product, and is identified with ). I do not think I will implement strong typing for physical quantities yet (though I'd like to), since C# generics are not powerful enough for that; I would need C++ templates. I'll do that when I rewrite things in C++/CLI. The next step is to implement my own versor, since Unity's Quaternion is in single-precision float and KSP's QuaternionD is broken. The rest should be more straightforward refactoring. 2014-02-24 It turns out I have trouble properly setting the position when off-rails (finding out where the reference frame actually is is hard). However, there are some nicer news: I seem to have found the source of the phantom acceleration bias (not the ones arising from rotation, the bias that is removed by timewarping). The floating origin sometimes floats several km away from the ship, so that's probably just floating-point inaccuracies (the usual Kraken). If that hypothesis turns out to be true, this particular acceleration bias will be easy to fix, just reset the floating origin often enough. 2014-02-19 I have successfully implemented the integration of proper acceleration for the active vessel when off-rails. Further experimentation on proper acceleration has led me to the following conclusions: There is a bias in proper acceleration coming from some improperly initialised variable in KSP. Indeed, when loading a vessel in LKO, I observe a strong bias in proper acceleration (~20 mm s-2). This bias is observed independently of the way proper acceleration is computed (differentiating position twice, differentiating any of the numerous velocities, etc.) and geometric accelerations have been checked from first principles (the difference in geometric acceleration depending on the point of the vessel it is computed at is negligible). The bias is reduced to below 1 mm s-2 when warping then coming out of warp. It should be noted that the strong bias is not seen in Vessel.perturbation, but Vessel.perturbation consistently has a bias of 4 mm s-2. As I have attempted to compute the proper acceleration in many different ways and all were consistent with each other and inconsistent with Vessel.perturbation, I assume Vessel.perturbation is mostly nonsense. Accelerations below 1 mm s-2 are biased, unavoidable, unusable in stock, and should be clamped to 0. The acceleration from low-thrust engines will have to be fetched by hand. It had previously been mentioned that spinning the ship accelerates it. If spinning the ship with angular velocity É produces a phantom acceleration a, then spinning it with angular velocity -É produces a phantom acceleration -a. It seems a is either prograde or retrograde. 2014-02-17 I have finally managed to work on this a bit over the weekend. Extensive experimentation has failed to yield a better velocity, so we are stuck with computing the proper acceleration from the rather mysterious Vessel.obt_velocity for now (for some reason in whatever reference frame this velocity is in, the geometric accelerations are as expected, except for the Coriolis acceleration which is halved ). This yields roughly the same results as Vessel.perturbation without the moving average. The same experiments have further shown that a naïve low-pass filter will not be enough to remove Unity's silliness. For instance, one finds the proper acceleration is strongly correlated with the rotation rate of the ship. Smarter post-processing will be needed. I shall now attempt to actually integrate whatever proper acceleration I have managed to grab. I also wrote the first explanatory post, which describes ODEs and Runge-Kutta methods (PDF). I have tried not only to explain how Runge-Kutta methods work (this can easily be found on Wikipedia) but why they have this structure. Hopefully you will find it interesting. 2014-02-08 I fixed a bug or two since 2014-02-05, added a few TODOs, but have not cleaned up the code to any measurable extent. I am, however, publishing it on GitHub (under the MIT license). Caveat Compilator: As previously stated, this is just a proof of concept with a bunch of traces. Pressing the wrong buttons in the wrong order will result in lots of NullReferenceExceptions and off-rails crafts will behave weirdly. Using HyperEdit to set up initial conditions, then switching to Newtonian physics and fooling around with reference frames can be entertaining though. You might learn something from looking at the Integrators part (which admittedly contains only one integrator), the rest was quickly hacked together, has no tests, is badly structured &c. The 'Simulator' project probably won't compile, it's leftover from my Alternis Kerbol simulations. It's not needed. 2014-02-05 This is currently hardly more than a proof of concept. The simulation only affects on-rails vessels, thrust is ignored (thus you can't actually play while the simulation is running) and the integrator is too slow. However, it shows a few interesting things: Near-unit-roundoff (using IEEE 754 binary64) errors can be achieved while sustaining 100_000x timewarp with B = 17, V < 5. Handwavy asymptotic calculations indicate that for V = 100, this integrator would slow down to about 20_000x timewarp. Using better integrators (and saner tolerances), performance could easily be increased by a couple of orders of magnitude, making the simulation usable for RSS as well as stock. Trajectory plotting in rotating reference frames, or reference frames centered around a body other than the primary, can be useful even for near-Keplerian orbits: it allows for visualisation of RT2 satellite coverage, easier landing prediction, etc. The stock integrator is terrible, and will have to be overriden at all times while in space (when near a Lagrange point, a fraction of a second under stock integration will turn a Kerbin capture into a Mun collision). If you think floating SOIs (or worse yet, SOIs with repulsive gravity) are a half-decent model for Lagrange points, you don't really understand how Lagrange points work. Expect a slow development cycle, due to a combination of laziness, exams, and this actually being a complicated project. I'll put the source on GitHub as soon as I can clean things up a bit (there are quite a few traces that were too hastily implemented for my taste). This might take a few days, see above. Nonetheless, here are some pictures that illustrate the fun trajectories in the N-body problem. The second and third pictures have a misplaced trajectory, this bug has been fixed. Some pictures have three strange red, green and blue lines, which indicate the origin and axes of world space. Notations Terminology Considerations on numerical integration The current prototype uses a straightforward fifth order SPRK method. The coefficients used are from (Atela & McLachlan 1992). The increments are accumulated using Kahan summation. The integration is performed with a constant 10 second timestep (numerical experiments suggest that the error is close to an unit roundoff with a 5 second timestep for LKO). Regarding implementation details, the integrator is written in C# (compiled with VS2013) and uses double (IEEE 754 binary64) for all computations. Scott Manley suggested using hybrid symplectic integrators (Chambers 1999) in order to speed things up. It should be noted that the concerns that the Chambers paper attempt to alleviate might not be critical for gameplay purposes (the main integration can probably be done with a very small timestep compared to the ones commonly used in astronomy. Moreover, timestep reduction occurs de facto when getting out of warp, as the game cannot conceivably be played with timesteps of several seconds). It could become relevant for trajectory predictions in vessels under thrust, which has to be done in a few hundred milliseconds over several years. For those predictions, the timestep would have to be increased to durations comparable to those used in the paper, and similar concerns would arise. The results from the papers quoted by Chambers, namely (Saha & Tremaine 1994) and (Holman & Wisdom 1991), will probably have to be used in order to make the main integrator faster. Experiments will have to be carried out in order to find out whether a higher order (> 2) integrator is worth using, and how the added cost of Keplerian evolution (which requires numerically solving the Kepler equation for all bodies, which is very costly due to the trigonometric functions) affects performance at acceptable time steps. Open questions for the interested reader Regarding KSP modding The method I currently use for drawing trajectories (LineRenderers, object in layer 9, transform.parent = null, useWorldSpace=true, updated every time the GUI is drawn) has some issues: when rotating the camera in map mode, the lines lag behind. Does this have a known solution? (I guess so, RT2 doesn't have this problem). And indeed, the RT2 code contained the solution. Thanks, Cilph! Is there a way to directly set the position and velocity of the planets and vessels in world coordinates? OBE, the API does not make sense in highly original ways. Can anybody think of a way to mod in axial tilt (even a hacky one; remember that I'm the one moving the planets around anyway)? OBE (done in RSS, we actually have axial tilt, it's just that all planets rotate around parallel axes). Regarding aerodynamics Could somebody help me with the implementation of orbital decay drag when I get to implementing that? ferram4 told me he'd help. Thanks! Would it be conceivable to predict the results of aerobraking/aerocapture/ballistic reentry with FAR (within some error margins, to be displayed on the predicted trajectory)? How slow would that be? Answered by ferram4. This might end up happening. Regarding astrophysics and astrodynamics The uniformly rotating reference frame around the barycenter with respect to which the two massive bodies are fixed is very useful when looking at trajectories in the CR3BP (Lagrange 1772). What would a good reference frame for the ER3BP (for bodies with highly eccentric orbits, e.g., Eeloo in stock, Pluto in RSS) be? the uniformly rotating one around the barycenter that follows the mean anomalies, the nonuniformly rotating one that follows the true anomalies, or something else entirely? In the rotating-pulsating reference frame that fixes both bodies, the equilibrium points are fixed. Is there a way to draw things in that reference frame on the in-game map that's not too confusing? Can it still be useful to draw the potential for the parts of the equations of motion that derive from a potential, given that the independent variable is true anomaly rather than time? Should long-term trajectory predictions for vessels under thrust be inaccurate, is there a good way of estimating the uncertainty (for instance, would predicting a few perturbed trajectories and plotting them all give a representative idea of what might happen)? ferram4 suggested a few interesting things. Would drawing the gravitational potential in the current orbital plane (together with the centrifugal potential if orbits are drawn is a rotating reference frame) be useful? Answered by ferram4 with visualisation suggestions. The answer is 'yes'. How should stationkeeping be implemented? In particular, how should the user set the orbit they want to maintain? Regarding the KSP fora Do we have LATEX support? If that isn't the case, is it conceivable to have it in the foreseeable future? Further modding Once the mod gets to a functional state (taking thrust into account), I shall attempt to solve the problem of trajectory prediction for vessels under thrust. In the process, the smarter integrators mentioned above will be implemented, and the most efficient one will be kept. This should significantly increase computation speed. This will also enable instantaneous-burn maneuver nodes (the kind of maneuver node we have now). The barycenters will be fixed in order to stabilise the Jool system. Scott Manley (illectro)'s predictions indicate this will make it stable over at least 1_000 years (Pol was not part of those predictions, its stability remains to be determined). Speed will be further increased by rewriting the numerical integration in (unmanaged) C++, interfaced with C# through C++/CLI. The unmanaged C++ (compiled with clang) will use 80-bit extended precision 'long double' (64-bit mantissa instead of 53-bit) for added precision. Once the mod becomes playable with N-body gravitation with point masses, the following effects should be relatively easy to add: Conservation of angular momentum through timewarp and outside timewarp (allowing for spin-stabilisation and thus fixed RT2 antennae if Cilph decides to implement that); Thrust through timewarp, for ion engines and the like, together with maneuver nodes for non-instantaneous burns; Orbital decay drag, with ferram4's help; Stationkeeping, to deal with orbital decay and unstable weakly bound orbits; Gravitational moment (quadrupole) for planets, enabling such amusing things as Sun-synchronous orbits; Insert crazy idea here... Acknowledgements I would like to thank (in alphabetical order of forum usernames) Anatid for his attempt at documenting the KSP API, armed_troop for his help in making the codebase clang-compatible. Ezriilc, Forecaster, khyperia, Payo and sirkut for their HyperEdit plugin, which is really useful for setting up initial conditions, Scott Manley (illectro) for his help with numerical integration of the N-body problem, Matt Roesle (Mattasmack) for writing an integrator which was far better than the one I used, thus prompting me to write my current SPRK integrator, NovaSilisko for his Alternis Kerbol mod, which piqued my interest in the simulation of the N-body problem, The entire KSP modding community (especially the subset which writes clean, well-commented code) for providing code examples from which one can learn the subtleties of dealing with the KSP API. If I forgot you in the above list, please complain! Bibliography Mathematica documentation on SPRK methods. [Atela & McLachlan 1992] Robert I McLachlan and Pau Atela, The accuracy of symplectic integrators, 1992. [Chambers 1999] John E. Chambers, A hybrid symplectic integrator that permits close encounters between massive bodies, 1999. [Holman & Wisdom 1991] Jack Wisdom and Matthew Holman, Symplectic maps for the N-body problem, 1991. [Kenniston 2002] Michael Kenniston, Dimension Checking of Physical Quantities, 2002. [Lagrange 1772] Joseph-Louis Lagrange, Essai sur le problème des trois corps, 1772. [saha & Tremaine 1994] Prasenjit Saha and Scott Tremaine, Long-term planetary integration with individual time steps, 1994. [Tao 2012] Terence Tao, A mathematical formalisation of dimensional analysis, 2012. Eric Weisstein's World of Physics, Gravitational Moment. [Yoshida 1990] Haruo Yoshida, Construction of higher order symplectic integrators, 1990. [Yoshida 1992] Haruo Yoshida, Symplectic Integrators for Hamiltonian Systems: Basic Theory, 1992.

Hmm, this is a point of discussion, but when the dev version was started to test-run future changes I reworked the fuel switches to automatically switch to methalox when CRP is detected, for an overall simpler and less error-prone setup. I don't think CC should cause the issues, as I tested specifically for that back when I made the changes. I will check again and report back. You're right, I also experience this issue now. Something must be messed up in the release, so I'll investigate.. In the meanwhile: Got a log? Can you check if it's a .craft (or part, if you pick a fresh part) issue? KSP sometimes messes up the fuel in saved crafts for no reason.

==================================================================================================================== Restock Waterfall Effects 3.0.0 by AtomicTech based off of Stock Waterfall Effects by Knight of St. John and Waterfall Restock by Nertea. ==================================================================================================================== Restock Waterfall Effects contains a set of template and engine configuration files, that gives Knight of St. John's awesome waterfall effects to the stock engines. This is a config mod and does nothing by itself and is built from Knight of St. John's Stock Waterfall Effects, Nertea's Waterfall Restock, and Jet Sounds Continued. You need to install the dependency mods for it to work. =============================================== ENGINES INCLUDED (Differences between Waterfall Restock 0.2.3) =============================================== The Bobcat with its original Hypergolic Plume (SWE) along with a new Kerolox and Hypergolic Plume. The Cheetah with a new Hypergolic Plume and Kerolox Plume, along with the original Hydrolox Plume (RWE). The Thud with its Hypergolic Plume from SWE. The Swivel with its original Kerolox Plume from SWE. The Reliant with its original Kerolox Plume from SWE. The Skiff with its original Hydrolox Plume from SWE. The Goliath, Juno, Panther, Wheesley, Whiplash, and RAPIER's SWE Plumes all included. The Vernier (RCS) with its original Kerolox Plume from SWE. The Wolfhound with a new Methalox plume. The Vector with its Hydrolox, Methalox, and Stratzenblitz configs from SWE. Along with everything else from Waterfall Restock! ================================ DEPENDENCIES (RWE 0.1.0 - 0.3.0) ================================ Required: ModuleManager Waterfall B9PartSwitch Restock Waterfall Restock ================================ DEPENDENCIES (RWE 2.0.0 to RWE 2.2.0) ================================ Required: ModuleManager Waterfall B9PartSwitch Restock ================================ DEPENDENCIES (RWE 3.0.0+) ================================ --- NEW INSTALL/UPDATE INSTRUCTIONS FOR 3.0.0 (and later) --- 1.) If you have existing RestockWaterfallExpansion, StockWaterfallEffects, and/or WaterfallRestock folders, DELETE ALL OF THEM. 2.) Extract all of the contents of the RWE-Master folder (RestockWaterfallExpansion, StockWaterfallEffects, and WaterfallRestock) to your GameData folder. 3.) Update/install dependencies: Realplume, Realplume Stock Configs, ModuleManager, Waterfall, Smokescreen, and TUFX (I think). 4.) Enjoy! --- UPDATING FROM 2.2.0 TO 3.0.0 (and later) --- 1.) If you have existing RestockWaterfallExpansion, JetSoundsUpdated, StockWaterfallEffects, and/or WaterfallRestock folders, DELETE ALL OF THEM. 3.) Update/install dependencies: Realplume, Realplume Stock Configs, ModuleManager, Waterfall, Smokescreen, and TUFX (I think). 2.) 2.) Extract all of the contents of the RWE-Master folder (RestockWaterfallExpansion, StockWaterfallEffects, and WaterfallRestock) to your GameData folder. ============= INSTALLATION ============= Read the included instructions in the .zip. NEWS & UPDATES ================= - (Nov. 27th, 2022) Restock Waterfall Expansion (0.3.0, [The Titan Update](https://i.ibb.co/Hg4BCgc/Titan-Update.jpg)) is now in beta testing, release expected soon! - (Nov. 30th, 2022) Research has begun to create a full replacement for Restock Waterfall using Stock Waterfall Effects 0.6.3 & 0.7.0. - (Dec. 17th, 2022) Restock Waterfall Expansion 0.3.0, the Titan Update released. - (Dec. 18th, 2022) Restock Waterfall Expansion 0.4.0 (Modern Rocket Rockin') in development. - (Dec. 29th, 2022) Restock Waterfall Expansion 0.4.0 (Modern Rocket Rockin') development temporarily halted. - (Mar. 1st, 2023) Restock Waterfall Expansion 0.4.0 (Modern Rocket Rockin') cancelled. - (Mar. 6th, 2023) Restock Waterfall Expansion 2.0.0 (New Age, Old Thing) in development. - (Mar. 6th, 2023) Restock Waterfall Expansion 2.0.0 (New Age, Old Thing) released. - (Mar. 6th, 2024) Restock Waterfall Expansion 2.2.0 (Turbo Turbines) released. - (Mar. 19th, 2024) Restock Waterfall Expansion 3.0.0 (Stainless Steel Solids) in development. - (Apr. 25th, 2024) Restock Waterfall Expansion 3.0.0 (Stainless Steel Solids) released. ========== LICENSING ========== This content is distributed under the Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) (For the RestockWaterfallExpansion & StockWaterfallEffects Folder, for the license for the Waterfall Restock, see Chris Adderly's custom license below.) You are free to: - Share — copy and redistribute the material in any medium or format - Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: - Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. - NonCommercial — You may not use the material for commercial purposes. - ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original. - No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits. ========================================== FROM WaterfallRestock BY CHRIS ADDERLEY ========================================== Copyright (c) 2019 Chris Adderley Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ========== PICTURES ==========

Introducing... (Source code is included in the download) License: Code and Configs are licensed under the GPL v3 license. Author: TheShaddow1138 Tester(s): @Puggonaut Here's a spacedock by @StinkyAce that @Puggonaut has been featuring in his videos: https://spacedock.info/mod/1815/USS Nimitz and Drydock A scaleFactor of 0.6 makes the best fit for the NX. A compatibility config is included that creates a copy of the drydock and modifies the included resources to include the resources needed by the NX. StinkyAce's mod must be installed for this config to work. Dependencies: (bundled with the Spacedock download) ModuleManager 4.1.4 B9PartSwitch Community Resource Pack Waterfall Small Trailer for TrekDrive made by Puggonaut This fantastic video was made by @Puggonaut, and you should definitely give it a watch. If you like what you see, and would like to support development you can make a donation. One-time Donation through PayPal Mod(s) that Expand or Supplement TrekDrive: @Shammyofwar Is updating the Old SciFi Shipyards mod by implementing TrekDrive modules on that mod's USS Voyager and USS Stargazer, among others. The TrekDrive plugin will be bundled with their mod upon release. Change Log: v1.0.3b - Log Spam Hotfix * Updated TrekDrive.dll to remove spamming the debug log with the number of warp coils that are charged. v1.0.3a - Warp Drive Hotfix * Updated TrekDrive.dll * Updated the CheckStatus function to check if the minimum number of nacelles have been charged instead of all nacelles on the ship. Fixes an issue where embarked warp-capable shuttles prevents the mothership from going to warp. * Updated the warp coil code so that coils that are not charged will not try to drain themselves and prevent the ship from going to warp if the minimum number of nacelles are in fact charged. v1.0.3 - The Galileo Seven * Added Type F Shuttlecraft (all parts have two texture variants) * Main Hull (crew capacity of 7) * Impulse Engine * Warp Core * Type F Warp Nacelles (Port & Starboard) * Added warpEffectParent.mu (an empty transform model) This model is in "TrekDrive/Generic" along with usage instructions * Added a WaterfallFX template for the TrekDrive warp stars effect to make it easier for others to add the effect to non-TrekDrive parts. * Added Mirror Universe texture variants and registry/name variants for the Type F Shuttlecraft. * Updated all parts with the SW_ModuleWarpGenertor module to have a warpEffectParent transform to standardize the transform to which the warp stars effect is parented. (Doesn't affect anything, all effects are intact and the same as before.) * Updated all parts with RCS thrusters to use LqdDeuterium, removing MonoPropellant entirely from the parts. To maintain propellant consumption rates all RCS thrusters' ISP were increased by a factor of 25. * Updated surface attach node on NX-class warp nacelles allowing for sane surface attachment. * Updated TrekDrive.dll to apply forward and reverse impulse thrust per-part instead of to the vessel as a whole (thrust vectoring still works). v.1.0.2 - The Original Reborn * Added Constitution-class Starship (all parts have two texture variants) * Bridge Module (crew capacity of 6) * Saucer (crew capacity of 30) * Impulse Engines (includes a docking port) * Engineering Hull (crew capacity of 20) * Navigational Deflector * Nacelle Pylons (two variants: flared and straight) * Warp Nacelles (Port and Starboard) * Starship Registry Variants (present on Saucer, Engineering Hull, and Nacelles [port & starboard] * USS Bonhomme Richard (NCC-1731) * USS Cassie (NCC-1711) * USS Constellation (NCC-1017) * USS Constitution (NCC-1021) * USS Defiant (NCC-1764) * USS Eagle (NCC-956) * USS Emden (NCC-1856) * USS Endeavour (NCC-1895) * USS Enterprise (NCC-1701) - The Default * USS Essex (NCC-1709) * USS Excalibur (NCC-1664) * USS Exeter (NCC-1672) * USS Hood (NCC-1703) * USS Hornet (NCC-1708) * USS Intrepid (NCC-1631) * USS Kearsarge (NCC-1733) * USS Lexington (NCC-1709) * USS Porthos (NCC-1712) * USS Potemkin (NCC-1657) * USS Ticonderoga (NCC-1714) * USS Yamato (NCC-1716) * USS Yorktown (NCC-1717) * Added two (2) new registries for the NX-class and NX-class * Cassie (NX-11) * S.S. Cassie (NX-11) * Porthos (NX-12) * S.S. Porthos (NX-12) * Added Mirror Universe Kerbban Empire Content in "Extras" (content is encapsulated and may be easily removed by deleting either the "Extras" folder, or the "MirrorUniverse" folder inside "Extras") * Kerbban Empire Texture Variants to the following parts * NX-class Saucer * NX-class Engineering Section Refit * NX-class Warp Nacelle Refit (Warp 7 Nacelles) Port and Starboard * Enterprise-era Shuttlepod fuselage * Constitution-class Saucer * Constitution-class Engineering Section * Constitution-class Warp Nacelles Port and Starboard * Kerbban Empire Registry variants for all currently available registry variants on the NX-class and Constitution-class ships * Flag of the Kerbban Empire * Added Textures Unlimited patch - authored by Puggonaut with "excludeMesh" statements provided by TheShadow1138 so that registries appear correctly with this config. v1.0.1 - Thrust Vectoring * Updated plugin to add thrust vectoring to impulse engines. Thrust vectoring is toggleable in the PAW and by Action Group * Added a new parameter to impulse engine CFGs, "maxVectorAngle" a value in degrees to control the amount of vectoring. Default value is 15º. v1.0 - Initial Full Release * Includes: * Phoenix Warpship * Phoenix Warpship launcher * Enterprise-era Shuttlepod (can be docked in the aft bays of the NX) * NX-class starship (has two aft shuttle bays for the shuttlepod) * Added A User's Manual * Added NX-class Bridge IVA and Props * Updated warp stars configs so that they are visible in the Bridge IVA * Updated the plugin to add an ambient rumble sound for the warp core. The sound is customizable by simply editing the CFGs with SW_ModuleWarpCore to give the path to your desired sound. * Added ENT-era Shuttlepod IVA (Stock and MAS versions) * Updated Shuttlepod Impulse engines to have a hover altitude of 1000m * Added ModuleLiftingBody to the Shuttlepod fuselage improving flight characteristics * Balanced the RCS and COM of the Shuttlepod removing most if not all unwanted movement during docking or other maneuvers. * Updated SW_ModuleImpulseEngine to apply Takeoff/Landing forces to every part to provide even acceleration to the entire vessel almost entirely removing the need for RCS or SAS to keep the vessel level during takeoff/landing in atmosphere. Below are the previous WIP Change Logs: v0.99.1w - Spacedock * Added a ModuleManager patch for StinkyAce's Spacedock, available at this link: https://spacedock.info/mod/1815/USS Nimitz and Drydock The patch scales the dock down to 0.6, a near perfect fit for the NX-class, and instead of modifying the drydock that comes with StinkyAce's mod, it creates a new part with the aforementioned scale, an impulse engine (no part, just the module), and produces the resources used by TrekDrive ships. This will be a good refueling station for the NX. * Updated the plugin * Fixed an NRE spam in the impulse engine code while in the editor * Added the ability to select a "forward" or "reverse" mode for the impulse engines. Toggleable in the PAW, and can be set as an action group. * Cleaned up the Waterfall patch by splitting the warp effects into their own patch. * Tweaked the texture tiling on the NX warp effects (both the Warp 5 and Warp 7 versions). v0.99w - NX-class Release * B9PartSwitch is now a hard dependency. (Included in download) * Updated the TrekDrive.dll * Warp speed formula changed to allow faster interstellar travel * OnLoad function updated to not automatically set the warp drive to "Not Ready" if it was in a "Ready" state at the last save. This allows the player to immediately engage the drive after the vessel loads, if the drive is in a Ready state upon loading. * Added NX-class Starship Parts * Bridge module (Crew capacity of 6) * Saucer section (Crew capacity of 20) * Engineering section * Nacelle Pylons (B9PartSwitch variants) * Upper variant (2 upper pylons) * Lower variant (2 lower pylons) * Four variant (2 upper & 2 lower pylons) * Warp Nacelles (Port & Stbd) * Main Impulse Engines (Port & Stbd) * Secondary Impulse Engines (Port & Stbd) * Navigational Deflector (2 variants) - Serves as a transmitter * NX-01 Oval "Mark I" Deflector * NX-02 Rectangular "Mark II" Deflector * Added NX-class Refit Starship Parts * Engineering Section Refit (Includes warp 7 warp core and warp drive, Crew capacity of 10) * Refit Warp Nacelles (Port & Stbd) * Added Custom Waterfall FX model and texture for streaking stars at warp effect. * Updated the warp stars effect on the Phoenix * Added six (6) craft files for the NX-class and NX-class Refit * NXClass_A: Standard NX-class starship (as seen in Star Trek: Enterprise) * NXClass_B: NX-class starship with two (2) ventrally (lower) mounted nacelles * NXClass_C: NX-class with four (4) nacelles * NXClass_Refit_A: Standard NX-class starship Refit * NXClass_Refit_B: NX-class Refit with two (2) ventrally (lower) mounted nacelles * NXClass_Refit_C: NX-class Refit with four (4) nacelles v0.9w - Shuttlepod & Impulse Engine Release * Updated the TrekDrive.dll * All TrekDrive buttons/toggles can now be set as Action Groups * SW_ModuleImpulseEngine Added - automatic takeoff and landing modes when sub-orbital, it will not automatically land from orbit. * SW_ModuleBussardCollector Added - When the collector is activated it will collect at a random rate for a random period of time before choosing another random rate and period of time. Collects LqdDeuterium and Antimatter with LqdDeuterium collecting at a higher rate. Collection will only occur at sub-light velocities. * Updated Waterfall version. * Updated Waterfall effect on the Phoenix Launcher Main Engine to correct a position issue. * Added a Waterfall effect to the Phoenix - visible when traveling at warp; the effect is based on the streaking stars warp effect from TNG - VOY and ENT. * Added Enterprise-era Shuttlepod * Shuttlepod main body - holds 5 kerbals with airlocks on both sides (No IVA) * Shuttlepod Impulse Engine v0.7.5w - OnLoad Hotfix: * Corrected an issue that prevented engaging the warp drive after switching to another vessel, after reloading the game, or any other loading action. Upon switching back to the warp ship, or loading the save, the warp drive will be automatically disengaged and set to "Not Ready" status. Simply clicking "Check Ready Status" and then engaging the warp drive will get you ready to go. Thanks to @Tanner Rawlings for finding this issue and bringing it to my attention. v0.7w - Phoenix IVA release: * Added Phoenix IVA (Stock and MOARdV's Avionics System) * The MAS version replaces some of the central props with MAS props, and replaces the Main Display with a functional MFD * MAS version of the IVA will only be available with MAS is installed. v0.6w - Phoenix Initial release: -------------------------------- * Updated Code: * Added nacelle glow animation capability, giving a visual indicator of coil charge. * Fixed coil charge logic to allow charging a partially discharged coil * Fixed a logic issue with the Warp Field Generator code. Now the "not enough charge" warning will only occur if the warp drive is active. * Moved to LqdDeuterium and Antimatter from Community Resource Pack * Added Phoenix Parts: * Phoenix Crew Cabin (no IVA currently, built-in RCS, no effects yet) * Phoenix SAS (contains Monopropellant and Electric Charge) * Phoenix Fuselage (contains LqdDeuterium and Antimatter) * Phoenix Nacelle (deployable warp nacelle) * Phoenix Warp Core/Warp Field Generator * Phoenix Main Thruster (matter-antimatter rocket engine) * Phoenix Vernier Thruster (matter-antimatter rocket engine) * Phoenix Fairing (to conceal the warp nacelles during launch) * Phoenix Interstage Decoupler * Phoenix Launcher First Stage * Phoenix Launcher Main Engine (Liquid Fuel Oxidizer engine) * Added Phoenix Warp Ship Test craft. * Added Community Resource Pack and Waterfall as hard dependencies (bundled) Inspired by RoverDude's Standalone Alcubierre Warp Drive, this warp drive aspires to operate in a Star Trek-like manner requiring at least two types of parts to operate: warp coils/nacelles and the heart of the drive, the warp core and warp field generator. I have seen in other threads here where people were trying to figure out how to require the use of warp nacelles to get that Star Trek feel to their KSP warp drives, and that's what I set out to do with this, my first plugin mod. Maybe a bit ambitious, but I think it turned out well. Now, on to the details. Technical Aspects: The plugin includes three Part Modules: SW_ModuleWarpCoil, SW_ModuleWarpCore, and SW_ModuleWarpGenerator. SW_ModuleWarpCoil: This module would typically be attached to a warp nacelle part, but could be added to any part for a design that perhaps doesn't use a nacelle, or similar structure. Requires: Warp plasma, which is generated by a warp core part using SW_ModuleWarpCore. Restrictions: Cannot be added to the same part as the SW_ModuleWarpGenerator. This is the restriction that requires at least two types of parts. Example Config: MODULE { name = SW_ModuleWarpCoil warpPlasmaConsumed = 5 // Amount of warp plasma consumed per second during charging and operation warpPlasmaNeeded = 250 // Amount of warp plasma needed to fully charge the warp coil cutoffThreshold = 2.000 // When the charge percentage drops below this percentage, the coil and drive cut off (1 - 100) coilEfficiency = 0.01 // Thermal efficiency of the coil (0 - 1) maxWarp = 2 // Maximum warp factor this coil can safely achieve } SW_ModuleWarpCore: A simple generator module that takes in deuterium (matter) and anti-deuterium (antimatter) to generate warp plasma and electric charge. (Could be replaced with a stock ModuleGenerator I suppose, but it's included all the same). Requires: Deuterium and Anti-Deuterium. Restrictions: None hardcoded. Example Config: MODULE { name = SW_ModuleWarpCore minAntimatter = 0.05 // Minimum amount of anti-deuterium required to operate minMatter = 0.05 // Minimum amount of deuterium required to operate warpPlasmaProdRate = 10 // Amount of warp plasma generated per second ecProdRate = 100 // Amount of electric charge generated per second } SW_ModuleWarpGenerator: The heart of the warp drive that actually moves the ship at warp speeds. Just like RoverDude's Standalone Alcubierre Warp Drive, the drive uses translation, not acceleration, to move the ship through space. Also, like RoverDude's drive, I used a slightly modified version of his gravity braking code (RoverDude's source code including the GravityBrakes() function) so that ships will slow down when they near gravitational bodies. Requires: At least one part implementing SW_ModuleWarpCoil that cannot be the same part implementing SW_ModuleWarpGenerator. This is what forces the requirement of multiple parts. Restrictions: All warp coils must be charged before the drive can be activated, and enough electric charge to run the drive is also necessary. If either of these is not true the drive cannot activate, or will automatically disengage. Example Config: MODULE { name = SW_ModuleWarpGenerator maxWarp = 2 // Maximum warp factor this drive can attain minNacelles = 2 // Minimum number of nacelles required by the drive to operate (must be at least 1) electricityReq = 50.000 // Amount of electric charge that is required per second of warp operation } NOTE: Some part on the vessel should have a container for warp plasma. In the included test parts the nacelles have their own warp plasma containers, but it can be on any part of the vessel. Warp Speed: The ship's warp velocity is computed using a simple cubic function, which was used for the original series and in Star Trek: Enterprise. So, velocity = (warp factor^3) * c In my initial testing, I find that Warp 2 is a good speed for traveling to the edge of the Kerbol System in a comfortable amount of time. I haven't tested higher warp factors, but will install appropriate mods on my end to further test travel times with increasing warp factors before final release. How to Use: I have kept the operation of the drive entirely within the Part Action Windows (PAW) of each part. Follow these steps to activate the drive. All of these actions can be set as Action Groups to somewhat simplify the process. Step 1: Activate the Warp Core by clicking the "Warp Core Status" toggle. Step 2: Charge the Warp Coil(s) by clicking "Charge Warp Coils" in the coil PAW Step 3: Once the coils are charged click "Check Ready Status" on the Warp Generator (combined with the Warp Core Test Article here). The drive will not enter the "Ready" status until all the coils are charged, and will not do so if there are any other active Warp Generators. Step 4: Once the "Ready Status" reads "Ready", click "Engage Warp Drive" on the Warp Generator. This will change from "Drive Inactive" to "Drive Engaged" Once the drive is engaged, any throttle input will move the ship at warp speeds. To return to non-warp operation, simply click the "Engage Warp Drive" toggle in the PAW to disengage the drive, or use an Action Group. Current warp factor is determined as a percentage of the drive's maximum warp rating, based on the amount of throttle: 50% throttle is half of the maximum warp, 100% throttle is maximum warp. E.g. for a drive with a maximum warp of 2, 50% throttle will be Warp 1, and 100% throttle will be Warp 2. The warp factor can also be selected using a slider in the PAW. The slider moves in 0.25 increments from Warp 0.25 to the maximum warp of the drive. The slider defaults to Warp 1. Increasing the slider scales the throttle so that your warp speed does not increase until you manually increase the throttle. The current warp factor is displayed in the Warp Generator's PAW Step 5: Once you have reached your target destination simply throttle to 0%, or use "x" to cut the throttle. There is an "Orbit Mode" option in the Warp Generator PAW that defaults to "Easy", this places the vessel in as close to a circular orbit as possible when the throttle hits 0 after having been non-zero. That is, it doesn't continually change the orbit while the drive is active, only if it had been moving the ship and then stopped. If the Orbit Mode is toggled to "Realistic", it will simply use the vessel's velocity vector to determine the current orbit, in the same manner as RoverDude's Alcubierre drive. Limitations: I tried to implement some limitations to make the drive less "cheaty". I took cues from Star Trek, particularly Star Trek: Enterprise, which dealt repeatedly with the limitations of the ship's warp drive. In the show, most problems occurred with the plasma injectors, but I though trying to code some kind of simulation of the injectors would be cumbersome and place unnecessary computational overhead. Other limitations that come to mind are the stability of the warp field, and the warp coil temperature. I opted for warp coil temperature to place a limitation on time at maximum warp. Warp Coil Temperature: While the drive is active, and moving at warp speeds, to emulate the warp plasma cycling through the coils I have implemented an exponential function that increases the temperature of the warp coil part. The smallest amount of heating occurs at low warp, while the maximum heating occurs at maximum warp. There is a built-in warp coil efficiency that can be used to aid in cooling. The value in the config file is between 0 and 1, and the upper limit is enforced in the code to prevent config editing to make the coils cool themselves at high warp. If a value greater than 1 is used in the config, the plugin randomly chooses an efficiency in the correct range. So, you may get a decently efficient coil, or a really inefficient one. This is also done per coil, so you could have one coil that is really efficient and one that is terrible, which could hamper your warp travel to keep one coil from overheating and exploding (the stock behavior). The maxWarp parameter of the warp coil also plays a role in temperature calculation. A ratio is taken of the active drive's maxWarp to the warp coil's maxWarp to further scale the exponential function. If the warp coil's maxWarp is equal to the drive's, there is not scaling, if it is less, there is more heating, if it is greater it is less. The reasoning is that if you have a warp coil rated for Warp 1, and try to push it to Warp 2, it would burn out much faster, but if it's the other way around, it would be able to handle the temperature better. Warp Coil Discharged: If the source of warp plasma runs out, or is shut off, the coils may completely discharge, if the user doesn't notice that warp plasma production has stopped. If the coils completely discharge (or their charge goes below the threshold set in their config) the drive will automatically disengage and either be automatically placed in a nearly circular orbit (Easy orbit mode), or be in a realistic orbit based on the vessel velocity vector. Running out of Electricity: If there is not enough electric charge to run the Warp Field Generator, the drive will automatically disengage and enter an orbit based on the selected orbit mode. Multiple Warp Generators?: If there are multiple parts on the vessel that implement SW_ModuleWarpGenerator, only one may be active at a time. If you try to activate a second warp generator when one is already active, it will not activate. If you disengage the active drive, you may then activate another. Screenshots Phoenix Warpship: NX-class: NX-Refit NX-class Bridge IVA Custom Registries There are ten (10) different names and registries in two variants each, so 20 textures in all giving you NX-01 through NX-10 and names with and without the "S.S." prefix. The registries are B9PartSwitch selectable on the saucer part and the refit engineering hull part. I have included instructions on how to make custom names/registries in the config file that sets up the variants under "TrekDrive/Parts/NXClass/Registries/Registries.cfg". The instructions are at the bottom of the file. There are also two (2) template images, one in PNG format and another in PSD. To use the PSD file you will need to have the font "Airborne", or one that looks close enough to it, if you want show-accuracy, or any font of your choosing will work.

I can't seem to determine if there is any specific rhyme or reason behind the way parts are organized in the research nodes on the tech tree. It's not alphabetical, by size, by mass, or by part type. At least not consistently across all nodes. For instance here's a few nodes that directly follow each other in Tier 3, [Part name (Size - Part Type)]: Enlarged Power Systems: SP-XL "Gigantor" (MD - Solar Panel), FC-01 (XS - Converter), Z-1K (S - Battery) Long-Range Generation: PB-NUK (XS - Generator), Z-4K (M - Battery), RA-100 (S - Transmitter), Communotron 88-88 (S - Transmitter), FCA-06 (S - Converter) Nuclear Power: Z-375 (L - Battery), SP-XXL "Colossus" (L - Solar Panel), KR4-P3 (S - Converter) They're all over the place! In some nodes there's fuel tanks followed by an engine and others an engine followed by fuel tanks. Generally similar parts are grouped sensibly in individual nodes, although there are exceptions to even that. Medium Orbital Rockets has two pods, three other parts, a pod again, and one last other part. If there's any formula to this I can't tell what it is. I wouldn't call this a bug because technically there isn't anything wrong, I don't know what the correct order would even be, it's just a weird quirk to the layout of parts in the nodes. It would be nice to see some cohesion in the parts list for the nodes just for the heck of it, but I recognize this is about as pedantic as a suggestion gets.

This mod introduces astronauts' health management to KSP. You have to consider health implications when building vessels, planning and executing missions. It covers various factors affecting health including living space, microgravity, radiation, diseases, accidents and more. It is highly customizable and works well alongside most popular mods. Download latest release Wiki Source Features Kerbals have Health Points (HP) that gradually reduce during missions and restored at KSC. Maximum HP is determined by kerbal's level (+10 HP per level). HP change based on several factors such as available living space, presence of crewmates, gravity, and specific ship parts. If a kerbal's health goes below 20%, he/she may become exhausted (technically, turn into a Tourist). They will eventually get back to work after health goes above 20% again. If a kerbal's health falls to 0, they will die! Train astronauts at KSC to prepare them for space travel and reduce their stress. They will also gradually learn to use their equipment during missions. Kerbals are affected by radiation, which permanently reduces their maximum health. It can come from the Sun, including CMEs, radioactive parts, galactic cosmic rays etc. You can protect from radiation by using shielding and choosing safer mission profiles. Planets and moons can reduce radiation within their magnetic fields and atmospheres. Kerbals may fall sick, have health accidents, panic attacks and other contingencies. When kerbals level up, they can acquire quirks that affect their health reactions, to the better or to the worse. All necessary data is shown in the Health Monitor (at KSC and in flight) and Health Report (in the editor). Compatibility patches support a range of parts mods (see below). All of these settings are easily changed or disabled in-game and/or with ModuleManager patches. Health Factors The following factors may affect kerbal's health: Stress (kerbal is on a mission): -2 x (1 - Training Level) x Number of Colleagues HP/day (see details below) Confinement: -2 x Crew / Living Space HP/day (Living Space is provided by most crewed parts depending on their size, capacity, function etc.) Microgravity (orbital or suborbital flight or under 0.1 g, e.g. Minmus): -1 HP/day Loneliness (only one kerbal in the vessel): -1 HP/day Isolation (no working CommNet or RT connection to home): -0.5 HP/day EVA: -18 HP/day Home (in Kerbin's low atmosphere): +2 HP/day KSC (kerbal is recuperating at KSC, i.e. available): +3 HP/day You can adjust all factors' effects in the Difficulty Settings. Quirks of a kerbal may also affect their health factors. You can check current values for a specific crew member in the Health Monitor. Certain parts (such as Hitchhiker and crew cabins) can additionally reduce the effect of a health factor (Confinement in this case) allowing for much longer and healthier flights, at a cost of Electric Charge. Hab rings in some mods can help overcome Microgravity issues for long-term stations and interplanetary missions while cupolas alleviate Loneliness. Stress and Training One of the drains on kerbals' health is Stress. Stress may be reduced in two ways (combinable): training and having colleagues on board. Training level for a part can range between 0% and 100%, and the vessel training level is its parts' weighted average with weights being their Complexity. Kerbals can be trained to specific part types, e.g. Mk 1 Pod or the Science Lab. Only parts that are marked to have Complexity (which is measured in %) need to be trained for; these are mostly crewable parts. The more different part types are on the vessel, the longer training will take. Stupider kerbals will also train slower than smarter ones (depending on your difficulty settings). Training can take two forms: In-flight training takes place automatically whenever the kerbal is on a mission and not landed on the home planet (i.e. Kerbin). They will gradually get used to the parts on their vessel and therefore slowly reduce the Stress they take from spaceflight. More challenging situations provide significantly more training speed, based on their science multiplier. However, this process gives diminishing returns. For instance, an astronaut with 0% training may increase their training level by 1% per day, but when they reach 50% training, they will only get 0.5% per day, and so on. So you can never really reach 100% training, but the experience using a part a kerbal has, the less Stress they will take. Training at KSC has the obvious benefit of preparing the kerbal for their mission without exposing them to its dangers. It is recommended that you train your kerbals at KSC before sending them to where no kerbal has gone before. The drawback is that KSC training has a cap, which depends on your Astronaut Complex level. You can't increase their training level beyond that without actually going to space. The kerbals also have to be healty (i.e. have no health conditions) to train, and they won't recover their health while they are training at the KSC. KSC training level caps based on your Astronaut Complex facility level: Level 1: 30% reduction (i.e. -1.4 HP/day) Level 2: 50% reduction (i.e. -1 HP/day) Level 3: 60% reduction (i.e. -0.8 HP/day) To start KSC training, load the vessel in the Editor, open the Health Report and click "Training Info" button. From there, you can select which kerbals to train. If you disable KSC training in the Settings, kerbals are always assumed to be fully KSC-trained for all parts. In-flight training still takes place as usual. The other way to reduce Stress is to have more than one kerbal of a certain profession on a vessel. Then they are assumed to be working in shifts or helping each other, and their Stress level is reduced accordingly. For instance, a Pilot that loses 0.8 HP/day to Stress when alone will lose 0.4 HP/day if there is another Pilot on the ship. Tourists don't benefit from having more "colleagues" on a vessel. Instead, they get peace of mind from knowing that there is professional crew to look after them. Their Stress is reduced by the number of non-Tourist crew members on the vessel plus 1. For example, a Tourist that normally loses 0.8 HP/day to Stress will lose 0.4 HP/day if there is one crew member, ~0.27 if there are two crew members etc. Health Recuperation Certain parts (such as the Cupola) provide Recuperation bonuses. If a kerbal receives, say, a 1% recuperation bonus, he/she will recover 1% of their lacking health (i.e. of the difference between their current HP and the maximum HP) every day. This change works in parallel with the normal health factors above. Example: A 5-star kerbal (maximum HP = 150) currently has 55 Health Points and is in a vessel that gives him 2% recuperation. The vessel has 10 units of living space, he has connection and he has a crewmate. Therefore he recovers (150 - 55) x 2% = 1.9 HP per day and loses also (0.5 + 2 x 2 / 10 + 1) = 1.9 HP per day. It means that the marginal change balances out the "normal" change and his health will stay around 55 HP (37%) until the situation changes. As you see, this mechanics may allow some kerbals to stay relatively healthy indefinitely. It may look cheaty, but the point is that: (1) there should be a way to design long-term missions without spamming crew space, (2) it requires a lot of heavy parts and therefore still difficult, (3) the balanced health level is usually far from 100% and may fall lower if circumstances change (e.g., new crew arrives and fills the station), (4) these bonuses require a lot of EC, (5) radiation still keeps mounting (see below). Recuperation is not stacked and has crew cap. It means that one Cupola provides 2% Recup for 1 kerbal, 2 Cupolas give 2% for 2 kerbals (not 4%!), etc. If you have more kerbals than the crew cap, Recuperation will be split among them evenly (e.g. 2 kerbals with 1 Cupola will get 1% Recup). Decay is the opposite to Recuperation: for every percentage point of Decay, your kerbal will lose 1% of their remaining health per day. Fortunately, it is very rare. Radiation All kerbals on missions are affected by radiation, which slowly but permanently reduces their maximum HP. Radiation is measured in banana equivalent doses (when you eat a banana, you get approximately 1e-7 Sv of radiation). 1e7 (10M) bananas reduce max HP by 10%; 1e8 (100M) bananas kill a kerbal. The amount of Radiation a kerbal receives depends on many factors. Most importantly, it is determined by their location. Many planets and some moons have magnetic fields that stop some radiation; atmospheres are also very effective in shielding it (see wiki for more). Being close to a celestial body helps screen some rays too. E.g., radiation level at Kerbin's sea level is 1,000 times lower than in interplanetary space just outside Kerbin's SOI. Cosmic radiation is also greater closer to the Sun. To check environment before sending astronauts, you can use magnetometers and Geiger counters provided by supported mods or embedded in advanced stock probe cores. Being on EVA takes away all the protection your ship provides and dramatically increases radiation level. Artificial radiation is created by certain parts like atomic engines and nuclear reactors. You can protect kerbals from radiation (both cosmic and artificial) by adding shielding to the vessel. It is provided by some parts, like structural panels, heat shields and mk3 cargo bays. These parts and most crew pods can be improved by adding Radiation Shielding to them in the Editor. You can never eliminate all radiation, but you can reduce it to non-dangerous levels. Beware of solar radiation storms! They can blast your kerbals in a planet's SOI or in interplanetary space with amounts of radiation ranging from high to enormous. You will be warned, usually, a few hours in advance and the kerbals will automatically take cover in the shelter, if there is one. The shelter is determined as the most protected part (or set of parts) that can fit the entire crew. You will see shelter exposure in the Health Report and Health Monitor details. The frequence of solar storms depends on the phase of the solar cycle going (on average) from one storm every 6,667 days to one storm every 437 days. If you have Kerbalism installed and enabled "Use Kerbalism Radiation" option in the settings, Kerbal Health's radiation calculations will be replaced with those of Kerbalism (but Kerbal Health shielding will still apply). Kerbalism has a more realistic and complex radiation model, but its balance is very different from Kerbal Health's. It is possible to cure radiation by decontaminating a kerbal, but it is hard. To start decontamination, the kerbal has to be at KSC at full health and with no health conditions. You also need fully upgraded R&D Facility and Astronaut Complex. Every decontamination costs 100,000 funds (in Career mode) and 1,000 science points (in Career and Science mods). It cures 100,000 banana doses per Kerbin day and stops if you send the kerbal on a mission. The kerbal undergoing decontamination temporarily loses 70% of their health and will need to rest afterwards. As always, each value can be adjusted in-game. If your astronaut discovers an anomaly, they may also be miraculously decontaminated by unknown forces (but only one kerbal per anomaly). Quirks Whenever a kerbal levels up, there is a 25% chance that he or she will acquire a health quirk (unless he/she already has two). Discovering an anomaly can also grant a free quirk. These can be positive or negative and usually affect kerbals' vulnerability to various health factors and dangers. Chances of getting some quirks depend on courage and stupidity of a particular kerbal. The full list can be found in the Kerbal Health Wiki. Random Events Kerbals' organisms, like ours own, are not always predictable. Sometimes, not very often, you may see unexpected events that can impact your whole mission. Kerbals acquire (or lose) certain conditions as a result of these events. Having parts with a Sick Bay (such as the stock Science Lab) helps alleviate the symptoms. Sickness: A kerbal can become sick and start losing health quickly. His/her crewmates may catch the disease too, including during the incubation period. This condition usually heals itself after some time, but it can also lead to a pneumonia, a really dangerous condition. Having Scientists or Medics aboard helps. Injuries: A kerbal can immediately lose some health in an accident. Stupid kerbals are naturally predisposed to this condition. It may cause sepsis, which is mortally dangerous. Bring your kerbal home immediately or pray Kraken it will heal on its own. Food poisoning: Kerbals are known for their love of snacks and they don't always wash their hands. Food poisoning may not be as bad as some other conditions on its own, but if dehydration develops, they will become unable to do any work at all and effectively turn into space Tourists until it passes. Panic attacks: Though not posing danger to health per se, panic prevents kerbals from doing any useful work. At least it doesn't last long and courageous kerbals are less prone to it. Conditions can be disabled or their chances and effects changed in game settings. You can also easily add, modify or remove conditions (see wiki for details). Requirements Module Manager Supported Mods Kerbal Health should work well alongside most other mods and will try to adapt to them with smart MM patches. Some have better, native support though: Atomic Age B9 Aerospace Blizzy's Toolbar Bluedog Design Bureau Connected Living Space (integration can be toggled in the settings) Crew R&R Deadly Reentry Continued DeepFreeze Continued Deep Space Exploration Vehicles Far Future Technologies FASA Feline Utility Rovers FTmN Atomic Rockets (classic and Improved) JNSQ Kerbal Atomics Kerbalism (stress, comforts, living space, and radiation features are disabled by Kerbal Health by default; you can use Kerbalism's radiation model instead of Kerbal Health's) Kerbal Planetary Base Systems Kerbal Reusability Expansion KSP-AVC KSP Interstellar Extended Malemute Near Future Technologies (Aeronautics, Electrics, Exploration, Launch Vehicles, Spacecraft) Outer Planets Mod Probes Before Crew Rational Resources & Rational Resources Parts RemoteTech ReStock+ RLA Reborn RSCapsuledyne Snacks SpaceY Heavy Lifters SSTU Stockalike Station Parts Expansion Redux Surface Experiment Pack Tantares Tokamak Insustries Refurbished Parts USI Freight Transportation Technologies USI Kolonization Systems (MKS/OKS) + Karibou USI-LS (see notes below) Making History expansion is supported too but not required. If you would like to include special support for your (or your favorite) mod, let me know. Conflicts & Incompatibilities Any mod, which can temporarily make kerbals Tourists, can conflict with Kerbal Health if both mods change kerbals' status and then turn it back. In some situations it may mean that your kerbals will remain Tourists indefinitely or become active too soon. Kerbal Health tries to fix some of these situations, but cannot prevent all of them. Custom solar systems with multiple stars can work in strange ways with radiation mechanics. Disable radiation in the settings if you have problems. It is recommended to disable habitation mechanics of USI-LS (and other similar mods) as these largely have the same goal as Kerbal Health. Feedback & Bug Reports I love feedback! Tell me what you think about the mod, what ideas, suggestions or complaints you have. If you have a bug report, please provide an output log while in Debug Mode (use in-game settings to enable) or at least give exact instructions how to reproduce it. License: MIT Enjoy the mod? Buy me a coffee! Changelog

I am trying to make a patch so all WBIGraviticEngineGenerator modules have their input_resource set to this: This is what a standard gravitic engine part looks like: But the relevant part is this: And this is my patch: Patch seems to have no effect and doesn't show up in MMPATCH.log

"Ever Tried. Ever Failed. No Matter. Try Again. Fail Again. Fail Better." -Samuel Beckett Hello, KSP players! My name is Ultimate Steve, and this is my sandbox mode mission report, "Project Intrepid!" At its core, Project Intrepid is the story of Kerbalkind and their quest to evacuate Kerbin, but, really, it is so much more: Project Intrepid is also the story of Jebediah Kerman and his quest to defeat the Kraken. It is also the story of Thedney/Tedfry/Tomfurt Kerman and his quest to save the Monolith. It is also the story of Hudson Kerman and his quest for power. It is the story of space pirates, strange boulders, dramatic rescues, forgotten secrets, teleporting Kerbals, and dare I say, Time Travel... But I'm getting ahead of myself here. Project Intrepid is - well, you'll just have to read it to find out! Mod list (Outdated, I went uber-visual mods around part 40): Kerbal Engineer Redux Kerbal Alarm Clock Reentry Particle Effect Time Control Hyperedit (Mostly for testing) Inspiration: @Kuzzter's wonderful series of Kerbfleet Graphic Novels (Which I couldn't resist referencing throughout this story ) Note: For anyone who thinks I copied the name "Intrepid," I promise, it is a coincidence. The idea of a fleet of giant motherships, the first of which would be called "Intrepid," was floating around my head as early as 0.23.5. I have the notebook pages to prove it! @Parkaboy's Plan Kappa (Again referenced in parts of my story). @Just Jim's "The Saga of Emiko Station" (Referenced once or twice), in particular for inspiring the line I end each part with. @max_creative for supporting me early on with the story. Thanks, dude! @Monkey Taylor's Jool-Sarnus 10 challenge, for providing the grounds for an epic backstory (See: Nightmares, a Jool-Sarnus Ten Story). And of course, @HarvesteR for his model rocketry adventures that later became the game we all know and love, Kerbal Space Program! Notes: This was my first mission report. The first few parts are, uh, not up to par, to say the least. If you can muscle through the first seven or so, my writing quality improves greatly after that point. As of June I'm trying to edit the first few so I at least get all the names correct. An important piece of canon that is only really supported for the first few chapters: If Kerbals die, they release spores and can be regrown, but this is a process that only works if the spores can be recovered and it is not always successful. Kerbals are mortal, just a bit resilient. My other story, "Nightmares: A Jool-Sarnus Ten Story," is a flashback that chronologically happens decades before this story even begins, but should be read in between parts 35 and 36 for maximum effect. When I first started this story, I did not expect it to go very far, but it did! So, some of the information in the first few parts (timeline, spelling of names, consistency in "..." styles, etc.) may not be the same as in later parts. If two parts contradict each other, feel free to ask me which one is correct. MAJOR easter egg spoilers throughout the story, be warned. Chapter list (Chapters were called parts for a while): Mega OP edit brought to you 3/12/2017. Second mega OP edit brought to you 6/18/2018. Enjoy the story! Any and all feedback is appreciated! Part 1: I guess that’s the end of Part 1, I guess. I am open to any suggestions, and I have flown the missions up to ITV-008. No spoilers, though! Part 2: It was at this point that Imgur capped my screenshot album. Will Shercott survive? Find out in part 3! Coming whenever I upload more screenshots! Part 3: End of part 3. Part 4 will be when the story starts getting interesting... Part 4: Part 5: Part 6:

The last optimization for KSP1's loading was a GameDatabase system overhaul released in 2013 in version 0.20 . "Optimization" is not lineally correlated to time, it's not even guaranteed to happen as sometimes it's just not possible to make an algorithm better, or not worth it to pursue an overhaul/refactor under budgetary and practical limits. Don't sit out hoping for magic optimizations to come, specially when some very foundational systems can't really be optimized thanks to the way they have been designed. It's primitive because parent-child systems have been as old as... the need to sort data. In the case of KSP1 a part has nodes, and anything that attaches to those nodes is a child, save for the node that attaches to a previous part which is the parent part, all the way up to the root. In the case of surface nodes, they're an arbitrary node created at arbitrary coordinates where another branch of the tree spawns as a child, pointing to the surface attachment node of the new child part. Almost every engineering game uses this method because it's proven to work, it's fast to cycle through all the nodes, and you do not need to check for recursions in circular structures. As for alternatives, I can't just produce an answer because that goes beyond my skill level, but don't take that as "something different than tree based" but rather "let me use the 1 to 3 adapter, and then a 3 to 1 at the bottom without it not connecting 2 of the nodes." Currently, such a thing would mean that bottom adapter has 3 parents, something not possible as they're inheriting force, fuel flow, and other data from the parent part. It's also why the game dies when you dock vessels to themselves as it reconfigures the tree in real time. The PAW has to be one of the worst crimes against everything good in UI/UX design. "Let's make a UI that shows everything at the same time"... then they fond out it obviously lags the game to hell to load tooltips for all parts at the same time and that people are having a hard time finding something specific in a sea of parts that share the same names. The first is somewhat fixable... the other not so much, it's just one of those "we have to be different at any cost" things even if the cost is making an objectively worse feature. That and the amateur navball design/positioning.

I agree with that first part, but the 2nd part was established in Empire (though partly not verified until Jedi), when they established that the only 3 known and still living people who could use the force were a dad and his 2 kids.

@CobaltWolf A lot of parts need to be rotated, they don't come out of the part list in the right oreintation. Also, why the size reduction? Also also, now it is unstable, really bad. I get endless aileron roll spinning and the control surfaces and RCS combined can't counteract it. Even Atmospheric Autopilot can't cope. Also also also, the extended fuselage doesn't seem to have a node. Also also also also, would you put a node on the engine to allow for vertically mounting the X-15 on rockets? Like in this picture:

Agree, extended family groups was the standard social unit until 10 K years ago. Yes it was larger units but they was mostly to meet others, trade and solve conflicts. Slavery was mostly ancient, it died out in most of the world, yes you had forced labor, but much softer. Slavery got an upswing after colonization of America as it was an labor shortage. Now part of the reason slavery died out in Europe and probably other places is that slaves has an added cost, you have to hire guards to keep them in line or treat them well enough that they stay. If you can hire people cheap enough why use slaves, if you have enough hungry unemployed they are likely cheaper. Back in the bronze age wage labor was not really invented yet, you was part of the family or you was paid for an task like gig or day work, or you was an slave. Rome and some other place probably took so many slaves because their wars they became an slave economy. Taking Jerusalem after the Jew revolt paid for Colosseum. Imagine wars being profitable, expensive weapon system has multiple benefits

Kapitalism. V0.0.2 This mod adds in the biggest missing feature that the devs have said will never be added. **Money**. Please report bugs Here Please report feature requests Here How to install: Use CKAN! Do not manually install (no mod support for manual installs) WARNING about Toucan Mod Manager: If you see this mod on any other mod site or mod manager Its not me. I only put mods on CKAN and spacedock. Your money is made up of funds + remaining budget for that year You can think of funds as how a private company would operate You can think of budget as something a government would give to NASA Budget renews every year based on your budget modifier. Base budget is 1000 features: - Currency - Mission Rewards - Part cost - Patch Manager compatibility Pick your administration type Optimize your rocket for cost savings Earn rewards for doing missions This mod uses the open source Bitstudios Public Use License (BPUL)