Timmon26

Hopefully sometime this month, fingers crossed? Really depends on Dakota and I being able to wrangle a few unsuspecting test subjects co-workers on relatively short notice. I already have the slides prepared for the next one though. We'll be going a bit more in-depth about ISP, covering launch vehicle control and stability, then flying efficient gravity turns in-game.

Hi, all! Last Friday we did a livestream of our KSP Academy: Rocketry 101! This started as an internal Slack channel where I could give KSP lessons and post tutorials for the Community Team or new Intercept hires who were new to the KSP franchise. We decided we should start streaming them, and the first lesson is now up on Youtube! This stuff probably pretty basic for you all, but it was a lot of fun to make, and I hope you enjoy! Some corrections: Escape velocity from LEO is closer to 11km/s, not 8. That's LEO orbital velocity. The boiling point of LH2 is about 20K, not about 3K. That's liquid helium. (See, even when I'm wrong about things, it's only because I'm right about other things. HA! ) Class slides (click to view in full res):

Thanks!

I was just wondering about this the other day. I also think the "Abstract Network" is the most likely solution and the way to go, even if it is a bit gamey, particularly since it's so robust. I totally agree with this. Setting up low-consumption flight paths is hard and time consuming and players should be rewarded for pulling it off. It's pro-problem-solving and anti-grind game design. Might not be absolutely realistic, but it's an acceptable abstraction. ____ Some hiccups with the Abstract Network though: Let's say you have a colony Alpha producing 100 widgets/launch window. You want to ship these widgets to colony Bravo, but Alpha doesn't have the best shipbuilding infrastructure yet and can only build and launch a small ship carrying 10 widgets. So you do that, and save it as a delivery route: 10 widgets, Alpha -> Bravo. Cool... But once you've established that as a delivery route, in principle there's no reason why you couldn't multiply it. "Hey, Alpha, just send ten of those same ships per launch window, okay?" 10 widgets, Alpha -> Bravo, x10. Now you have all 100 widgets going from Alpha to Bravo per launch window, despite Alpha's low state of development. This is how things might work in real life, with Starships colonizing Mars for example. Hundreds or thousands of Starships could be loaded and staged in LEO, then depart all at once in flotillas every two years. But is that fair in the game? Should there be a button in the Delivery UI to duplicate export shipments up to the maximum a colony could support? Maybe, but it would obviate the need to launch bigger delivery ships, which would eliminate that as a design challenge for the player. I'm sure bigger ships could be more efficient and replace the smaller ones later, but still... Okay, so let's say you don't include a multiplier button. Well now you've just incentivized the player to manually launch 10 identical low-tech transport ships, stash them in orbit, then have them all burn for their destination in one launch window. That's the same as doing the first delivery route x10, just grindier. Might as well give the player their route multiplier button back and save them the trouble. Mining missions have this issue too. If a colony sends out a rover to dig up and return 100 ore from a nearby deposit, can the player just... do it again and make 200 ore? Then 300 and so on until their colony has an unreasonable income due to grind? What's the launch window for a mining mission? Nearby craters don't have synodic periods. One option is to simply restrict the number of abstract delivery routes from any colony A to any colony B to 1 ship per window. This is quite unrealistic of course, but now all of the trade from Alpha to Bravo depends on one ship design and one flight plan, which seems in the spirit of the game as a rocket design and astrogation challenge. The amount of resources transferrable from Alpha to Bravo depends on the player's design of one ship for that purpose, and larger more ambitious designs are incentivized to maximize payload. It simplifies things a bit further too, in that there's now only one route to be replaced if the player launches a new mission to update it; there won't be a mess of different ship designs going from A to B to keep track of. Resource locations could also function as "colonies" for this purpose, so players will need to make their mining missions count. Of course, this creates the problem of having to constantly design new ships to update your delivery routes as your colonies grow, which is its own brand of grind. Maybe the delivery multiplier button is the best option and only the prospect of better ship design or flight path efficiency creates the incentive to update delivery routes. TL,DR: I'm confused and I hope the developers aren't.

Here's the SP-100, the kind of reactor the one in the screenshot was likely based on. Space fission reactors tend to be conical so shielding can be minimized – everything is designed so that sensitive bits and the rest of the spacecraft can fit inside the radiation shadow of the shield. In the screenshot, some of the outboard fuel tanks and radiators look like they're still in the radiation zone. Hope that won't cause any problems

You should always be in one star system's SOI, no matter where you are in interstellar space, as long as we're assuming patched conics. Although it's less of a sphere of influence now and more like a "cell" of influence. A local map of SOIs would resemble a 3D Voronoi diagram, although not exactly because the stars have different masses and the boundaries would be convex or concave.

Here's my spitball attempt at a highly simplified life support design that still ticks most of the boxes. This is based somewhat on my speculations on colony LS detailed here... ... as well as the Snacks mod and similar ideas. (Ships ought to work a bit differently from colonies though) _____ Per the poll, I think life support should be nonlethal on colonies, lethal on vehicles, and take into account food, radiation, living space, flight time, and power. All direct consumables like oxygen, water, and food are rolled into one resource - Snacks. Kerbals each consume 1 snacks/day (every 6 hours) and turn them into 1 volatiles/day. Snacks/Volatiles are stored in radial or inline pods that come in a few sizes and their flow to kerbals obeys crossfeed rules. Command modules and space suits also have token snack storage. Kerbals must continually consume snacks (as if it were electricity) or become Starving. Starving kerbals live for some number of hours to days before they shrivel up like raisins and die. Starving kerbals lose access to class abilities. Upon entering a craft with available snacks, kerbals immediately lose the starving condition and return to normal activity. ECLSS modules are radial or inline parts that provide recycling and reduce the rate of snack consumption on the vessel by some factor (I picked 0.9 because that's the reclamation efficiency of the ISS's ECLSS but the factor could be anything for balance). The parts come in a few sizes and each has a certain capacity (points?) representing the number of kerbals the module ideally supports. These points can be stacked with multiple modules. If there are more kerbals on a vessel than the ECLSS modules can support, the reduction in snack consumption is reduced, reflecting the oversaturation of the environment systems. Snacks can only be 100% reclaimed from volatiles by colony greenhouses. Vessels always experience losses. Bunks represent the living space a kerbal needs to be comfortable on a long trip. Habitat modules like the Hitchhiker provide bunks. A Kerbal with a claimed bunk on their vessel will remain happy indefinitely. A kerbal without access to a bunk (if you didn't include one or they left their ship temporarily on a rover mission or something) will remain happy for some number of days before becoming Grumpy. A grumpy kerbal loses access to class abilities. Upon returning to a vessel with an open bunk, a grumpy kerbal becomes happy again. Bunk-providing modules generally require power. Kerbals can handle a certain amount of constant radiation flux up to some threshold (in watts). If the threshold is exceeded, the kerbal becomes Irradiated for the duration of the exposure. While irradiated, kerbals lose access to class abilities. Radiation sources include nuclear engines, radiation belts, and stars. If kerbals are exposed to a radiation flux past a second, higher threshold, they melt and die. Basically, walking on the Mun is fine, standing next to an active fission reactor is bad, and staring into a running open-cycle NTR is deadly. Kerbals also have a limited endurance for space missions, and eventually will go Space Crazy. Kerbals that have gone crazy lose access to class abilities and must return to Kerbin or a colony for them to be restored. Craziness typically takes a long time to set in; probably a few Kerbin years. The statuses and cutoffs above would be affected by a Kerbal's Level and their attributes - Courage and Stupidity. Higher level kerbals take longer to starve, can handle more radiation, and can stave off grumpiness and craziness for longer. Courageous Kerbals tend to be bad a rationing and don't heed radiation warnings, reducing their starvation time and radiation thresholds, but they're better at staying happy and sane no matter their living conditions. Stupid Kerbals' small brains require less food, and are highly resistant to boredom. But they tend to wander into radiation fields and become upset if they aren't kept comfortable. I like reversible class ability loss, then outright death, as consequences of life support failure. Class ability loss would be punishing but not crippling, hurting the player for making suboptimal or unrealistic decisions but giving them a way to recover. Death only occurs when the player truly screws up, like forgetting to pack any food or blasting their kerbals with NSWRs. I don't consider kerbal death unfair so long as it comes with forewarning. If the UI gives the player enough information, like how long a trip will take and how long their Snacks will last, then packing enough life support for a mission becomes part of the play/fail/learn/play loop just like packing enough fuel. Space missions revolve around time, and it's reasonable for time limits (what life support effectively is) to be a part of that gameplay. ____ Colonies, on the other hand, are a whole other ballgame. The purpose of colonies is to be sort of like "checkpoints" that the player builds themselves; safe spaces they can retreat back to or sortie out from as they explore deeper into space. They should be more or less closed-cycle and never fail once established, and their life support systems have to be stable for the colony to grow at all, making them effectively timeless and impervious to time warp, much like KSC already is. Of course, for this to work, the technical division between what is a "colony" and what is a "vessel" needs to be precisely defined.

Really, no one's gonna make a Command & Conquer joke? Okay.

When it comes to mining gasses from atmospheres (let's assume planetary and not stellar to keep things simple), there are generally two proposed methods. The first is to drop a refinery into the atmosphere, a big airship basically, held aloft by either lifting gasses or heated air. This refinery would take in atmosphere, crack whatever propellants you need out of it, liquify them, and store them for visiting spaceplanes and rockets. This was the method proposed for fueling Project Daedalus. The main problem with this is that in order to get the mined fuel into orbit, your visiting tanker ships need to accelerate it up to orbital velocity from near zero, fighting gravity and atmospheric drag and all that, presumably in a deep gas giant gravity well. So there are a lot of losses getting the fuel to orbit, naturally, and your tanker ship needs to be fully reusable and capable of reentry, docking with the airship again, blah blah it's a hassle... The other method is to collect fuel gradually from the rarified upper atmosphere, with some sort of dedicated scoop ship, while near orbital velocity. This has been proposed as early as 1959 in the form of PROFAC (PROpulsive Fluid Accumulation), and ToughSF has a good rundown of the method here. The scoop ship doesn't have to be especially aerodynamic, it just needs to have lots of frontal area for collecting gas. Basically the main problem with this method is power. Your scooper needs power to cool the incoming (at orbital velocity) air so it can be stored as a liquid, it needs power to perform whatever ISRU chemical conversions are needed, and it needs power to re-accelerate the collected air back up to OVER-orbital velocities with some kind of rocket engine to counteract the drag forces so it doesn't re-enter. This suggests some kind of high-Isp electric engine is probably needed, like a plasma or MPD thruster. The high power requirements could be met by a nuclear reactor or gobs of solar panels (stretched long and thin along the scoop's main truss so as to not increase drag). The scoop will also need substantial radiators to handle the heat from the engine, reactor, cryocoolers, turbomolecular pumps and such. An alternative source of power could be via remote beaming, from one or several laser satellites or stations in higher orbits. The overall mass of the scoop ship almost doesn't matter, only the frontal reference area and the available power, as these determine how much drag the ship experiences and how much it can overcome with thrust. Somewhere along the scoop's truss will be a number of tanks that will slowly accumulate propellant. When the scoop is full, the engine throttles up to kick the scoop into a higher orbit where it will rendezvous with a depot or waiting ship. The propellant is offloaded, then rinse and repeat. With the delivery routes system in KSP 2, player's should be able to model something like this, by launching a scoop ship from a space station and recording a delivery mission with it. If there won't be any aerostat colonies or vehicles in the game (no evidence so far), it'll be the only practical way of mining gas giant atmospheres, which are realistically the best source of He3.

Haha, if only! Hire me, Intercept! Sometimes I draw things, sometimes kerbals, sometimes decently! I did this in Photoshop, but first made a very simple model in Blender and took a screenshot of the wireframe to give me a guide for the perspective.

AAAAAAH, I almost missed this! I only just saw this thread Monday! Would've liked to have added more details and funny things going on, but I wanted to make sure I made the deadline.

Learning 3D animation by testing a tripod walk cycle, which the big herbivores will need to move around... This is the left>right>back cycle. There's a case to be made for the L>B>R>B cycle but I thought it overworked the back leg too much. Since the abdomen is unsupported when the back leg lifts, it needs to be counterbalanced, so I had the long neck jut forward during the back step to act as a counterweight. This suggests even tripods that spend most of their time on three legs should still have their centers of mass just behind the front two. Probably not the most convenient walking strategy for poor Mr. Stompachonk; I guess that's why we don't have any true tripods in real life.

It definitely looks like a Z-pinch engine. If you look close you can see the ring of capacitor modules like in the HOPE design. Atomic Rockets says these get ~38 KN thrust at ~19,000 seconds Isp, vs Daedalus' 7.5 MN at 1 million seconds. That suggests an interplanetary ship.

Found some time to get some more work done on these and have updated the OP. In addition, I've decided to finally buckle down and learn Blender to possibly bring some of these guys to life. The results of Day 1 (I have no idea what I'm doing): Assuming I manage to produce a game-ready asset eventually, would anyone be interested in trying to mod some critters into KSP1, as a proof of concept? I don't have experience in these matters, but I should think it would be possible to piggyback on the surface feature system to randomly scatter aliens around other bodies like Laythe. I'll start a thread for it in the addons forum if anyone's interested.

So this kinda blew up when I wasn't watching. Don't worry guys, I haven't forgotten about these. There won't be a "Part 2" but I'll be adding drawings to the original post periodically. As far as something like this being in the game on release, I actually hope it isn't. I want my spaceflight/colony simulator ASAP, please. Adding aliens to Lapat, not to mention doing them justice, will take a lot of dev work, and will represent a shift in artistic focus from hard-surface modeling, terrain modeling, and physics optimization, to organic modeling, rigging, animating, and AI. AFAIK, there're only one or two creature-style rigs used in KSP2 - for the Kerbals - and they don't have any AI that we know of. However, I do think something like this can be done, but only as a DLC after the core game has shipped. My understanding is that the artists on a big project like this will usually get their work done first, then the second half of development is the engineers squashing bugs, so the artists need something to do between late alpha and gold that can be easily added to the game after release. A suite of funny aliens to sprinkle around on Lapat would seem to me to be a more art-heavy than code-heavy project, so something like this could fit the DLC bill. The question for the devs will be, is the time and effort to bring all these animals to life worth getting what is basically Surface Features 2.0?