Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by Timmon26

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

    On 11/18/2022 at 11:23 AM, poopslayer78 said:

    One potential exploit could be a player manually running a delivery route at the optimal time with very favorable gravity assists, and then getting future deliveries for less dV than they really should cost.

    Personally, I wouldn't mind this, and if a player is smart enough to exploit this... maybe they should be rewarded for it?  This is one of those cases where I believe satisfying gameplay is better than realism.

    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.

  2. 5 hours ago, Laxez said:

    Could you give me a reference image just to understand the shape of the reactor?

    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 :P

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




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

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

  6. 1 hour ago, Kasyan said:

    Intercept should hire you, your style looks awesome!

    Haha, if only! Hire me, Intercept! Sometimes I draw things, sometimes kerbals, sometimes decently! :D

    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. 

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

  8. 17 hours ago, The Aziz said:

    Highly depends on what this thing is:

    It's (almost) clearly an interstellar ship, but the engine is tiny compared to the Crucible.

    10 hours ago, Zaffre said:

    It's entirely possible this is a large interplanetary vessel heading out from its base. It reads like one at first, but this could also be interstellar, albeit a somewhat lower grade one. Though... I don't see a shield at the front. Perhaps one traveling across a binary star system? Looks to me like a Z-pinch magnetic confinement engine or something along that vein. Those are not super high-octane like the all too common Daedalus engine that may be our "crucible" motor.

    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. 

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

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

  11. Encountering a recurring issue and I can't tell if it's a bug or what.

    When designing a new craft I'll naturally check to make sure the center of lift is behind the center of mass, including both when tanks are full and drained. Invariably, when designing spaceplanes or similar craft, a CoL placed ahead of the CoM will have moved behind the CoM after test flying the craft and returning to the editor at least once.

    Here's a VHTL plane I was working on and the CoL was well behind the CoM when I launched it (with both full and dry tanks). It flipped out on reentry so I reverted to VAB and the CoL was suddenly here:


    This explains the instability, but it would have been nice to have known this was the true CoL beforehand. This has happened with every single VTHL spaceplane I have ever built. KSP is apparently able to calculate the true CoL, but will not until the craft has been launched, otherwise it will show the CoL as being behind where it actually is. Naturally this makes adjusting control surfaces unplayably tedious, as a flight is required between each adjustment.

    Has anyone else encountered this issue or can replicate it?

  12. Like others are saying here, the biggest problem beginners face when doing anything new in KSP, like precision landing, is not lack of fine control over their ships that they need an autopilot to make up for, but lack of information they need to approach a situation without doing a bunch of scary math. The Trajectories mod doesn't automate anything but is absolutely invaluable for the information it provides. With just the Time-to-Impact and Impact Velocity indicators, you have almost everything you need to perform a close-enough suicide burn anywhere you want. I suspect players who learned by watching MechJeb would find that they could learn just fine, maybe even better, if the game just had better tutorials (which we're getting) and flight planning information available. 

    The one main advantage of autopilots is the reduction in the tedium of flying dozens of missions to LKO to build up the infrastructure to do anything interesting beyond it. Right now, progression in KSP is like having to replay all the previous levels in a game that you've already beaten, again, before you're allowed to advance to the next one. 
    But the delivery route system in KSP2 may actually help eliminate this problem. By using delivery launches to cache resources and production facilities in orbit, players may be able to reach a point where they never have to launch from Kerbin's surface again if they don't want to. As the player's colonies expand outward from Kerbin, there's decreasing need for them to ever retrace their steps.

    3 hours ago, Pthigrivi said:

    Maybe there's a compromise in which its a piloting skill that unlocks after players have already had their hand at landing on a few bodies and put a basic colony together? Or maybe it would only work if it was locking on to a manually placed beacon, meaning you had to land in or near that location manually at least once?

    I'm hoping for something like this myself. A stock autopilot won't be a crutch so long as its functions are earned over time by the player's manual actions. Launching enough times into orbit unlocks AscentGuidance, manually rendezvousing unlocks InterceptPlotting, manually docking unlocks AutoDock, landing on a pad unlocks DescentGuidance, and so on. These functions could be tied to Kerbal pilot experience (although that may encourage players to grind out training missions so their pilots have all the "skills") or scientific data, e.g. DescentGuidance is unavailable on planets with atmospheres until you've collected atmospheric pressure and composition readings. A slow rollout of autopilot functions over the course of a playthrough can hopefully mitigate tedium without spoiling the game at the same time.

  13. 2 minutes ago, Kebab Kerman said:

    That's a unique SSTO design, I'm intrigued! What's it based on, and how does it take off? Vertical SSTOs aren't very common, as far as I'm aware. Might have to attempt one myself!

    It's just a small payload atop tapering fuel tanks, with six aerospikes and an inflatable heat shield for reentry. Has about 3.5-4km/s dV and a TWR of 1.4 or so,  depending on the payload mass. It's not as fuel efficient as an equivalent HTO space plane, but it sure is expedient - just flies straight to orbit, then reenters like a capsule with parachutes.  This design can't land without crushing the heat shield, so it has to splash down just east of KSC. Definitely improvable with a few tweaks, could maybe lose the heat shield if the engines won't explode... I just needed something to GTFTO quick.

    The closest real life equivalent is probably the DC-X.

  14. I sent Bill, Bob, and Jeb on a mission to the edge of Duna's northern polar cap to collect science from six different biomes (Science mode, hard settings).

    The launch of the Duny I rocket:






    The Duny I spacecraft consists of a nuclear mothership carrying a science base rover, a hab module, and a descent/ascent command module to return the crew to the mothership from Duna, and land them on Kerbin later.



    Kerbin departure and Duna arrival:






    Bob and Bill descend in the base rover. The rover is equipped with parachutes and monoprop jump jets for landing and hovering.




    After collecting science from all six target biomes, Jeb lands the command module to pick up the crew. Bill repacks two of the parachutes for the Kerbin re-entry and Bob transfers the experiments. They pose for a photo op before heading home. 



    Thanks to my massive overbudgeting of dV (I forgot to account for the gains from leaving the rover on Duna), I'm able to capture the mothership into LKO instead of ditching it. Hope to reuse it for future missions. The command pod makes an easy descent:




    OVER 9000 science from one mission to Duna, and without a lab. Nice. 




  15. This post is a bit hard to categorize. It’s part fan art, part suggestion, part general discussion topic, and part personal creative exercise. Mods, move this if necessary.

    In the Celestial Architecting video and latest atmospheric scattering show and tell, we saw a planet in development called Lapat that was apparently covered in vegetation. While the devs have been cagey about the possibility of complex life on other planets, I think this provides us with ample grounds for rampant, optimistic speculation about life on Lapat, particularly animal life. This post is my “blank check” wishlist for the kinds of things I’d like to see.

    In designing these alien animals, I'm trying to keep things both within the bounds of scientific plausibility and KSP's art style. With kerbals setting a precedent for the kind of life appropriate for the KSP universe, we can assume that any alien animal life will, like kerbals, be fairly simple, colorful, and funny-looking. Staying rooted in biology, the aliens also have to look like they're related to each other, but not to the kerbals. It should be possible to identify different phyla and draw speculative cladograms, but the Lapat family tree should still be kept fairly simple (like how the planetary systems are simple "toy" versions of real life). All major ecological niches should be filled, and we can expect that the Lapatians have found recognizable ways to fill them by convergent evolution, e.g. there will probably be things like "whales", "lions", "turtles", "birds", and "crabs". The animals must also be reasonable to implement into the game as animated actors with limited AI, hypothetically as DLC or something; so no intelligent aliens allowed, nothing so complex that the game becomes all about them and not the rockets. Gameplay-wise, aliens should be like mobile surface features for the player to find and catalogue.

    I have a loose family tree that in mind that I'm building as a draw these. I wanted most of the dominant "vertebrates" to be tripods because it's simple, funny, and creates weird design constraints. We also have to have to goofy-looking bugs and squid things of course, since you can't have an alien planet without those. I decided that all the eyes should be just like the kerbals': white spheres with black dot pupils. This is the KSP version of a camera eye, which has developed in many unrelated species on Earth by convergent evolution, and is one of the features we would expect to see in real aliens if we ever found them. So not only are the googly eyes funny, they make scientific sense in-universe if we assume the kerbal eyes are "typical".

    Anyway, my wild speculations follow. I will update this post as I add to the list.

    Life on Lapat, A Traveller's Guide:




    Stompachonkus seesawi

    Stompachonks are the dominant herbivores on Lapat. Their enormous size makes them unassailable by predators, and their long necks allow them to reach vegetation anywhere. Like all members of phylum Tripoda, they have three legs, and while they walk on all three, they can stand on their front two, which they often do when they eat low-lying plants. The rear leg acts as a counterweight to the neck, allowing them to stand in one place and hoover up grass like a bucket-wheel excavator.



    Chungutherium hedbutti

    Chungutheres travel in herds across Lapat's savannas, feeding on grasses and other ground-level plants. Their antennae are encased in large bony sheathes that they use as weapons, to contest dominance with other chungutheres and to repel attacks by large predators. 



    Jumpalopus hippidihoppidi

    Jumpalopes are nimble herding herbivores. When threatened they can leap great distances and bound across Lapat's plains at high speed. They often find themselves running desperately from...



    Cursorus Vex

     C-Vex is the apex land predator on Lapat, running down and chomping its prey with its massive jaws. Unlike most other tripods, it moves entirely on its front two legs, its third leg being entirely modified as a tail counterweight to its massive head. This bipedal stance is an evolutionary holdover from its flying cousins like the Duffin, which perch on two legs when landed.



    Dromidudius wileium

    Dromidudes are small, nimble land predators. They are extremely fast and will chase down anything they think might be mocking them. Thankfully they seem uninterested in prey that's kerbal sized or larger.



    Smeerpium mintyleafium

    Smeerpies are tiny and ubiquitous herbivores. They can jump high in the air when threatened and their antennae are long and leaflike to disguise them amongst Lapat's grasses. Dromidudes interpret this form of camouflage as mockery.



    Duffus duffus

    Duffins are a plague. They are stupid and they are everywhere. Avoid flying your rockets through flocks of them.



    Thtorkus nosedivius

    Thtorks are Lapat's seabirds, patrolling the cliffs and coastlines of Lapat's oceans. They will patiently soar on thermals until they spot something in the water for them to dive upon and spear with their pointed head.



    Dagronium lockheedi

    Dagrons are large, predatory, flying tripods that mostly hunt other fliers like thtorks and duffins. They are solitary creatures that build their nests on remote mountain tops and cliff edges. Although their names sound similar, they should not be mistaken for dargons, and certainly not for dragons. 



    Galumphagumpis swirlitops

    Galumphagumps are the turtle-analogs of phylum Noodleboia. They use their four proboscises as legs, stomping on and swallowing appetizing herbs as they walk. They can retract into their spiral shells when threatened. Their secondary appendages are modified as manipulators which they use to dig for food. Like all Noodlebois, they are radially symmetrical and have eyes on both sides of their bodies, providing 360 degree vision.



    Dippidorpus kyklopter

    Dippidorps are flying "insect" noodlebois that feed mostly on carrion or decaying plant matter. They're mostly harmless and mostly annoying and often preyed upon by Duffins and Dromidudes. 


    [To Be Continued]


    If there is ever to be alien animal life in KSP 2, I think it needs to be a balanced combination of silliness and plausibility. It needs to make you laugh first, then think "hey, that kinda makes sense". This bestiary is my humble attempt to check all those boxes and make a desperate case to the developers that they should add aliens to the game, because... I want them. Really bad. 

  16. 3 hours ago, shdwlrd said:

    Not a bad idea, it would help with passing the general locations along to other players. But it could destroy people's head canon. There will be players that won't want to use the stock naming and will make up their own names. 

    Yeah, that's a downside to stock landform names. A renaming function would fix this, but even if there wasn't one, I think the benefits outweigh the drawbacks. In almost ten years of head canon, almost no fan consensus has emerged about what to call specific places, aside from the canon biome names. The one exception may be the mohole, which was canonized in response to fan consensus. So I don't think people will mind if the landforms are named in advance by the devs. It also gives the devs another creative channel, as it's an easy way to world-build, and many of the labels could be humorous, based on easter eggs or in-jokes.


    This is a bit of a tangent, but landform names being revealed as players discover them would tie into the exploration system. My hope is that planets and moons won't be detailed at the start, and will only become visually interesting when players actually reach them. Exoplanets and exomoons initially won't be visible in the map at all, and once discovered would only present as indistinct spheres. Direct telescopic observation from Kerbin (or within the same system, for exoplanets) would reveal rough shapes and colors. Only when a player gets up close will the landforms of the planet appear, at which point they would be given names. From there, the player can do more detailed scans to find biome boundaries, resource deposits, and anomalies. Something like this:




  17. This is more of a cosmetic thing, but I'd love to see the landforms and regions on different planets named and labeled, in the style of an atlas, like this NatGeo map of Mars:



    The labels would follow the curvature of the planet and bend around natural borders, as if they were printed on a globe, and could be toggled on or off along with the biome overlay. Here's how the Mun might look from space:



    Labels would only appear after the landform or biome was discovered by a telescope or overflying spacecraft.

    I think something like this could give players a real sense of direction and place within the game world, which is sort of lacking in KSP1. It's often hard to tell apart the islands of Laythe or craters on Tylo; one region is the same as the next. Having consistent names for all these places would also give the community a sense of continuity when they share stories of where they've been or what they discovered. Having proper names for landforms is a lot more convenient than having to refer to "the big island" or "that little archipelago west of KSC, you know, the wiggly one".  The major landforms would be custom named by the developers, while smaller ones could use a random name generator like KSP1's waypoint naming system.

  18. On 1/16/2022 at 8:41 PM, SunlitZelkova said:

    I just hope the Soviet and Russian method of putting reactors on a long boom away from the crew module will work :D

    I mean it ought to. And not just for crew modules but for probe cores and scientific experiments too. The Pioneer probes had their RTGs mounted on booms to keep their radiation from interfering with science instruments:



    I'd love to see players do this for gameplay reasons instead of just role-play. Giving nuclear powered parts restrictions on where they can be placed relative to other parts makes for much more interesting game balance than simply making them more expensive or heavy to offset their usefulness. The more I think about it, the more I like radiation as a mechanic, because it will force players to use good design principles organically, in a way that can't be brute forced...

    Well, that or everyone just adopts the adage MOAR SHIELDING! to go along with MOAR BOOSTERS and MOAR STRUTS! :D

  19. Been thinking about radiation effects on ships lately.

    Based on screenshots and comments from Nate, we know radiation will be modeled somehow in-game, and will have an effect on kerbals. The VAB UI shows a "center of" symbol for radiation, similar to the ones for gravity, lift, and thrust. This suggests that a major source of radiation will be engines and reactors, namely NTRs, NSWRs, Orions, and fusion engines. So I threw together a sketch of how this might be visualized in the VAB interface:



    Here we have the ship from one of the show and tells. I believe that's the mmH vacuum engine, but let's pretend it's nuclear for a bit...

    The player will have to have some way of seeing how intense the radiation from this engine will be when it's running, how far the radiation flux reaches, and what other parts the radiation impinges upon. I don't know how granular the devs want the model to be, but presumably it should represent both how radiation intensity falls off with distance and how it can be blocked by parts. At some maximum range, radiation flux should be too weak to bother calculating and simply drop to zero, like air density at the tops of planetary atmospheres.

    The obvious way to model this would be to treat radiation as a point light source that illuminates parts and allows them to cast shadows on other parts. The parts have to be somewhat transparent however, to allow for intense radiation to penetrate them. One way to visualize this in the VAB would be to make this "light" visible, illuminating the ship with the radiation source so the player can see which parts are irradiated and which are shielded. The effect would look similar to the light of reentry as we see it in KSP1. Another way would be to show the radiation as concentric sphere overlays, although this could be visually confusing. A third way would be to cut to the chase and color code the parts of the ship according to how much radiation each is receiving, much like the temperature overlay in KSP1.

    If parts can block radiation from reaching others, this opens the door to fun design problems. The player has to make sure the parts that bear the brunt of the radiation are the strongest or simplest, and don't contain fragile electronics or squishy kerbals. It also presents an opportunity to include shadow shield parts specifically designed to block radiation from certain directions, perhaps being procedurally modifiable in diameter or thickness. This potentially creates an additional docking challenge, as players must keep each ship in the radiation shadow of the other to avoid either from being irradiated. Parts' radiation opacity may also change over time, as in the case of a fuel tank becoming increasingly transparent to particle radiation as it empties.

    Something to consider is the variation in the types of ionizing radiation. Generally radiation comes in either the electromagnetic or particle varieties, with each being more effectively blocked by dense metal plates or lots of low-density stuff (i.e. hydrogen or water tanks) respectively. Most of the radiation the player's technology will produce will be in the form of neutrons and x-rays, so both are an issue. If it were me, I would handwave a bit and consolidate the two together, modeling them as just "radiation", and giving each part a single opacity to both for simplicity's sake. 


    This all raises the question of what radiation actually does to parts or kerbals. 

    On the parts front, one thing radiation should do is simply heat parts up. In the case of NTRs this heating is small, but if you consider the detonation point of an Orion drive a "center of radiation", then any parts not in the shadow of the pusher plate would receive flash after flash of radiation until they are heated to the point of failure, first glowing, then exploding.

    Another way radiation may damage parts is by neutron embrittlement, where materials are made weaker by exposure to neutron radiation. One way to model this could be to decrease the part's impact or pressure tolerance gradually the longer it is exposed to a radiation source. The part won't be destroyed, but it will become easier and easier to break if collided with.

    Thirdly, radiation exposure may cause electronic parts to fail. Random failures are controversial and I tend to think they're not very fun, but if probe cores or science experiments each had a cutoff "rad hardness" or level of radiation flux they can handle indefinitely, so long as it's not exceeded, that would be a good compromise between realism and simplicity for me. A similar "steady-state" model could also apply to neutron embrittlement, with parts weakening under intense exposure, then returning to normal when no longer irradiated, to save the player the headache of parts being permanently reduced to the durability of balsawood, while still imposing radiation consequences...

    On the kerbal front, much depends on how the kerbals' skills and abilities are modeled. I doubt cumulative dose would ever kill a kerbal (although heat surely would), but it could cause them to be less effective at their jobs or drain their XP or something. Not much to say here until the devs reveal more.

  20. I just assumed Minmus used to be an icy body, like Enceladus, that formed in the outer Kerbol system (a previous moon of Jool?) before being perturbed inward and captured by Kerbin-Mun at some point, and that the global ice and oceans boiled away and left behind the rocky core covered in salt flats:

    Green Sandstone analysis suggests Minmus once had oceans.
    Surface samples describe an "inedible crystalline substance," likely a salt of some kind.
    Seismometer readings indicate the presence of subsurface liquid, which could be the remains of the saltwater ocean.
    Salt flats can be very bright and resemble ice.

    Seems like the simplest explanation for all the evidence. The volatile deposits that make Minmus useful as a fuel base in game are explainable as leftover pockets of saltwater or brines trapped beneath rock layers. 

  • Create New...