Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Timmon26

  1. 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.
  2. 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.
  3. 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.
  4. 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?
  5. 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?
  6. 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. 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.
  7. 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.
  8. Visited the artificial gravity station I'm building with a new reusable SSTO ship. The station will take six more launches to finish the contra-rotating lab and habitation sections.
  9. 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.
  10. 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.
  11. 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:
  12. 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.
  13. 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!
  14. 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.
  15. 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.
  16. This is a really good point. Ideally, each resource location should present a unique landing or navigation challenge, so that getting more resources for a colony becomes a piloting and mission design puzzle instead of a Factorio puzzle. Once the resources have been got, turning them into ships should be as straightforward as possible so the player can get back to designing and flying new ships. Keeping with this idea, resource locations should be widely scattered about a body, so that you'll be forced to change orbital inclinations, precision land, and choose orbits for new stations or depots carefully. Maybe close bodies like the Mun or Minmus would have more equatorial resources to be convenient in the early game, while farther-flung locations have more poleward deposits to ramp up the difficulty. Because all essential resources are rarely found in the same place, colonies would have to trade to be self sufficient. Here's how Munar resources could work, as an example: Another thing to consider is that the resources should also be widely scattered about the solar system, so that players are forced to venture out to get enough to go interstellar. The Mun might be a good source for starting metal and building material, and Minmus makes a good fuel base, but they'll give you just enough of a leg up to start colonizing the other planets.
  17. You could timewarp until your colony's tanks are full, then set that as a production cap, but if we know the player's just going to do that anyway, might as well just assume the tanks are full and spare the player the timewarping; let them go design and fly their next rocket. An economy management sim where a) the player can freely fast-forward to see the results of their actions, and b) where the player needs to also not be distracted by the economy management, creates really weird design constraints. The more I thought about it, the more I realized that time as a variable shouldn't really be a thing in such a system. Any of the player's changes to a colony need to ignore time as a factor, and simply alter the colony system's steady state to reflect the change. The obvious exception to this is ships themselves. So much of spacecraft design and mission planning revolves around time passage and resource consumption, so for a steady state colony system to work, there has to be some fundamental division between what is a "colony" and what is a "ship", because different rules apply to each. This division could get hairy when it comes to establishing colonies. If I land a ship with a hitchhiker on a moon, is that a "colony"? When does it become a colony, or are only BAE-constructed buildings part of the colony? Does a landed ship become a colony when I click an "Establish Colony" button, and can I un-establish it? Blurriness around the division between ships and colonies is a problem for this steady state idea, and I'm still trying to noodle through it. I completely agree about having maybe 3-4 resources, and that these should be found in different places, and sometimes in the same place. This is enough to create interesting decisions for the player, not to mention piloting challenges, but also not enough to be overwhelming and confusing. The the idea of atmospheric resources and air mining is something I glossed over in my proposal, which is silly of me considering how big a deal atmospheric resources are in real ISRU systems, like MOXIE. In a steady state, air mining would have to be modeled as if the whole atmosphere was one big "deposit" with a finite, if high, output that any colony on the planet could tap into. In the case of Kerbin, Laythe, and maybe Duna and Eve, the air would be a volatile deposit. Jool would be the obvious source of He3, assuming we can build aerostat colonies (fingers crossed). This also opens the door for atmospheric scooping or PROFAC systems. An orbital colony could deploy a hypersonic scoop ship to collect atmospheric volatiles and return them to the station, establishing that as a delivery route and increasing the station's steady state volatile stock. And I haven't played Frostpunk, but it sounds like I probably should.
  18. I've been thinking along these lines for a while too. Put this flowchart together recently. Was working on some kind of kerbal resources "thesis" and got sidetracked... Here I was trying to reduce ISRU into something simplified that also reflected reality. Came up with just a handful of raw resources like you did. I was inspired a bit by the simplified resource gathering in RTS games and Age of Empires in particular, which uses Food and Wood as your army's basic "fuel" and "building material" and Gold and Stone as rarer special resources you need for upgrades or unique units. Here, Volatiles (ices) fuel your rockets and kerbals, Metal (ore) is basic building material, and Uranium and Helium-3 are your special resources for building advanced stuff. Things like plastics or xenon are handwaved and rolled into volatiles and metal for simplicity's sake. Incoming Wall of Text _____ The problem with any colony ISRU system as I see it, no matter how simplified, is that timewarp will throw a wench into it. Option 1 for life support in colonies (but maybe not in ships?) is definitely preferable to life support that's consumable and needs to be replenished. If you don't have enough habs or snack production, then you just can't add more kerbals to the colony, period. If the colony loses production of one or both of these resources, because you crashed a rocket into a greenhouse, then a corresponding number of your kerbals will stop working and consequently shut down non-essential buildings they're running, like refineries. But I think we could take that concept even further than life support though. This principle of colony life support being in a steady state and always expressed as an income or rate can be applied to all the other colony resources as well. Why? Because free timewarp makes resource collection speed, efficiency, and stockpiling meaningless. If a colony has even a tiny surplus of, say, metal income, then the player can simply timewarp until they have enough metal to build a giant supership. Moreover, they can build as many giant superships as they want by timewarping further, no matter how inefficient their resourcing operations are. We've all used timewarp this way to refuel in KSP1. Because of timewarp, an inefficient mining vehicle is just as good as an efficient one. A possible solution is for colony resources to always be expressed as income rates and never as stockpiles or reservoirs. If a colony has 100 Metal, then it just has 100 Metal all the time, and can build ships or buildings that cost <= 100 Metal. Doesn't that mean the player can build infinite ships from that colony? Yes, but they could do that anyway with timewarp. What the 100 Metal cap does is restrict the colony's capabilities until the player does something, i.e. flies a mission, to upgrade those capabilities. If a young colony with 50 Volatiles can't launch a ship with tanks that take 100 Volatiles to fill, that creates an incentive for the player to upgrade that colony somehow so they can launch bigger ships from it. Yes, they could launch smaller ships and dock them together or something, but future convenience is plenty motivating. Every Career player knows the pain of hitting the early part count cap in the VAB and wishing they could add just one more part to their rocket. Better upgrade the VAB then! Not only can colony resources be expressed this way, raw resources in the ground could as well. Metal, Volatiles, U, and He3 (or whatever the resources will be) would all be found in deposits with a limited output of 10 or 200 or whatever. Sending a vehicle to mine from that deposit and return it to the colony will reduce the deposit's output and increase the colony's income by the capacity of the vehicle. The game would need to remember that resources are being taken from a deposit continuously, but this should be possible because of the delivery routes system. Mining a deposit with a delivery route is conceptually the same as transferring resources from one colony to another with a delivery route. In addition, delivery routes should probably be unaffected by synodic periods or travel times, again, because of timewarp. If a delivery route has reduced throughput because of time between launch windows, there's nothing to stop the player from stockpiling supply ships at one base between the windows and sending them all at once during the next window. It's simpler to just let players transfer their darn resources in one mission and let them move on to designing new missions elsewhere. So for example: Say your Mun Colony Alpha has 20 Uranium income, and you need 30 to build a ship with 3 NERV engines instead of just 2. So you need more Uranium at that colony. There's a U deposit nearby that you're currently mining the 20 U from, but it's depleted. There's another deposit on the other side of the Mun with 10 U. You could fly a mission there to mine that and return it, establish that as a delivery route, and now have 30 U at your base, minus the Volatiles you spent fueling the mining vehicle (you get to keep the mining vehicle's Metal because it returned to the base, unless it uses expendable drop tanks or something that costs metal). Alternatively, you could launch a delivery flight from your second Mun Base Beta with 10 U carrying the 10 U for your first base. This would get you the U you need, plus the salvaged Metal cost from the ship, unless you return the ship to the other base, but the second Mun base now has no U and can't launch nuclear ships from there or run any reactors. This essentially turns colony building into a game of increasing consolidation of resources, with the ultimate goal of building a single massive colony with the resource capacity to build a whole interstellar ship like the one from the trailer. The giant space station seen in the trailer is just such a colony. Also, because delivery routes track the loss of expendable ship parts and fuel between launch and destination, this creates an incentive to design efficient and reusable delivery flights to minimize those losses and get the most out of each delivery or mining mission. Needless to say, this also affects colony placement. [TL:DR] Timewarp makes stockpiling resources meaningless and running out of them frustrating. Therefor, all resources, be they in ground deposits or colony coffers, are expressed as steady state income rates that cap production of ships or the feeding of kerbals. Mining missions and delivery flights can transfer this resource income from deposits to colonies or between colonies. Your Mission: use miners, colonies, and delivery routes to collect resource income from around the Kerbin system and put it in one place so you can build a mega ark ship in space.
  19. Further thoughts on this: I don't know how much facial variation the devs intend to implement, but I seem to recall a throwaway line in an interview about eyeball symmetry possibly varying. I'd love to see that extended to head shape, eye size and position, mouth size and position, etc. As you can see from the sketches, by making kerbal heads variable by a number of parameters and then randomly tweaking them very slightly, we can produce a wide variety of unique faces. Fortunately, humans are really good at noticing subtle differences between faces, so the absolute differences can be too small to affect gameplay in any way (although animation will have to dynamically account for it) while being large enough to be memorable. Here's the theory behind how I varied these sketches: Male kerbal heads are basically cylinders, and female heads are pills. Jeb and Val (Male and Female #6 above) are the prototypical examples. Each head shape can be defined by two circular planes separated by some vertical distance. Increase that distance and you get kerbals like Male 4 and Female 3. Decrease it and you get M9 and F9. Each plane can also vary in radius. If the upper plane is wider than the lower, you get faces like M7 and F7. If the lower plane is wider, you get M8 and F8. Convexity and concavity may be helpful to vary as well; see kerbals M3 and M4 for a comparison. For eyeballs, each has a size, distance from center, and height. To prevent extremes, it may do to keep relative positions small, even as the height of the eyeline can change wildly. Mouths have a size, height, and left/right position. I just used three different markers to vary skin tone, but in the game I'd expect skin tones to have subtle random variations in RGB values, within some small range centered around #BADA55. Hair style can of course vary widely, as we've seen in released screenshots. If I had a say, I'd keep hair color very close to if not always black. I always thought black looked the best against green, while other combinations like blonde or red tend to clash badly. Ultimately I'd like to see a level of variation akin to the Thermians from Galaxy Quest. They're each unique, but derived from a common "template."
  20. Here are some sketches of kerbal faces I did. Kept the hairstyles similar to show the difference face shape makes, and varied the skin tones a bit with the markers I had on hand.
  21. Hard to believe it's been this long... I started playing in the before times, when Kerbin didn't even have a Mun yet! The game has come a long way since then. Congratulations, Squad. KSP is one of the most inspiring games ever made.
  22. I always imagined Jeb as being a bit like Sam Starfall. He founded KSP but doesn't run it. He's an enthusiastic con artist entrepreneur who excels at dazzling investors and convincing them to pour stupendous amounts of cash into his "space program" for "the benefit of Kerbal Kind". Really, he just likes the pretty rockets, the explosions they make, and being a famous astronaut. Bill and the rest of the crew are being dragged along in his wake, desperately trying to legitimize the program and do something constructive. Their occasional successes add to Jeb's credibility and feed the cycle, providing an endless supply of money and expendable recruits, presumably until the global economy collapses.
  23. 9/10 You modded my Pioneer Plaque into the game
  24. Yeah, I edited my post on that thread with a link to my image a few minutes before you posted yours. Here it is...
  • Create New...