IvanSanchez

So, literally years after my mun circumnavigation, I've finally done a Duna one. This is with modded KSP 1.11 in my career game, with a bunch of mods - notably SSPX and most of near-future. There are a few screenshots at https://imgur.com/a/WYWog6i . The trip includes a 200-meter-long interplanetary ship, carrying 6 kerbals, plus a 16-ton rover with a SSPX greenhouse and a 20-ton crew land/ascent ship in a coaxial configuration (with help of some 5m annular saddle trusses). The rover lands by itself, then the crew land on the land/ascent ship, rover goes rendezvous the lander, all 6 crew transfers to the rover. All 6 crew then go on to visit all of Duna's anomalies and most of its biomes, ending up at the ascent ship to get back to the 200-meter mothership in orbit. My SCAN BTDT shows the path taken quite nicely:

Your argument is... unbeatable. You won. ...if the devs would choose to "conveniently ignore" the tether, then none. IMHO there's no real need to simulate the entire tether but rather the parts next to the station and the counterweight. (By "next to" I mean "in the same physics bubble".) Alternatively, the tether could be split in pieces as long as the diameter (or the radius) of the physics bubble, so collisions could be calculated. But this would mean hundreds of "vessels" and orbit calculations. A remaining issue would be subjecting the counterweight to constant acceleration (remember, it's at high orbit, but hovering over both the anchor and the station). An ultra-cheap way of cheating this would be setting the state of the counterweight as "landed" The problem I see with mass drivers (and launch loops) is that they can be potentially bigger than the physics bubble, and can not be "conveniently ignored". Even with the KSP2 improvements to the physics engine (and due to my our very limited knowledge about the technical capabilities of it), I think simulating a mass driver (or mass-driver-like) launch system poses significant (software) engineering challenges. Whereas an elevator can be simulated with an anchor, a station, a counterweight and a conveniently invisible tether that the player cannot interact with. So IMHO elevators can be simulated, mass drivers can not. The hard problem of a moving vessel in contact with the launch infrastructure could be worked around by disabling collisions during the launch maneouver (so in essence the physical vessel "pops" into existence at the end of the driver, with full velocity) - but I think having a structure potentially bigger than a physics bubble can be problematic. And yes, of course I would like to put my kerbals on top of a hypersonic railgun train and accelerate them into orbit at 10G (what KSP player wouldn't?!). I'll be happy if I'm proven wrong on my "mass drivers can not be easily simulated" hypothesis. The same goes with skyhooks - simulating a kilometers-long cable under dynamic acceleration can be a bit of a nightmare. I'm going to disagree here. Elevators would make sense in planets (or moons) with no way of synthesizing fuel in-situ - there would be a need to land fuel tankers on a regular basis, and a launch system which uses only electricity makes sense, even with a limited payload throughput capacity. From the looks of it, KSP2 is gonna have some kind of logistics system in place, and I would expect those "automated milk runs" to have a cost, so I think that developing orbital infrastructure for cheaper milk runs does indeed fit the "essence" of the game (at least, from my point of view). BTW, what's the expected throughput of an elevator? There are some numbers for a hypothetical Earth elevator, but this is 10-times-denser-than-Earth Kerbin we're talking about, and AFAIK there's no numbers for elevators on different moons (yet). Again, we different players have different visions/wishes of what KSP2 will play like. I guess we'll have to wait and see what the final thing looks like.

We're all familiar with the concept of space elevators, right? And since KSP2 will have colonies and orbital shipyards and some kind of milk-run logistics system to send resources from one colony to another, it kinda makes sense to have space elevators. I guess this would need something like: A "ground anchor" colony building: build via KSP2's BAE but only near the equator A "counterweight anchor" part/building, meant to be attached to an asteroid. Or part of a big (i.e. massive) fuel dump station. A "cable spool" part. Buildable/launchable only from colonies with a "ground anchor" building. A four-part mission/contract to: Build the ground anchor Put a counterweight in a specific equatorial orbit (have a vessel of N tons in orbit, with the counterweight anchor part) Launch a vessel with the cable spool part (from the colony with the ground anchor) to the counterweight; rendezvous and dock (in less than half an orbit or so) Maneuver the counterweight exactly into its very specific final orbit. And when the cable is unspooled and tensioned then, boom, a new orbital station appears in stationary orbit just above the colony, as the colony sends up a lonely "elevator stop" module/building (then player opens up BAE at the station and adds more modules/buildings using the colony's resources). And I'm not thinking about a Kerbin elevator, but rather Mün & Minmus elevators. If KSP2 is gonna have inter-planetary logistics and economics, then I want to optimize resource launches from Kerbin's moons. --- I know there'll be a fraction of KSP players that will oppose this, with arguments like "but tensile strength" and "but tidal forces" and "but lagrangian points and escape velocities" and "but navigation hazard". So I'll remind you folks that KSP2 is a game and not a hardcore simulator, and I, for one, prefer unrealistic tensile strengths and ignoring problematic bits as long as the game teaches me something cool about futuristic space travel. So I wish for space elevators in KSP2.

https://spacedock.info/kerbal-space-program/browse/top

I was reading the mashable interview about KSP2 from june 24, and when peering over the screenshot of the VAB (which is similar but not the same as the one in the knowledge base) I noticed this... That's center of thrust, center of mass, center of lift and.... center of radiation hazard?! The fact that that icon has been in all of the (known) VAB screenshots for a while tells me that radioactivity is gonna be a new gameplay mechanic, which implies that there's gonna be radioactive parts (NERVs being the obvious example), and that kerbals might suffer from such radioactivity (arguably when the crewed parts are unshielded from and/or close to the radioactive parts). This does not tell us anything about: explicit rad shield parts; liquid tanks act as rad shielding; magnetosphere radiation belts; solar flares.

How about flag contracts requiring the flag of the agency giving out the contract to be planted, instead of any flag? e.g. if Kerlington gives a flag contract, I should plant a Kerlington flag and not my program's flag. This would, of course, complicate the way that flags are added to inventories. Can inventory parts be variants? And even then, I don't know if it's possible (or easy) for a mod to create one variant per agency registered in the game. And then there'd be the issue of what happens when the player uses the KSC's flagpole to change the program's flag - how would such a mod keep track of the flag flying whenever any craft was launched? Agency-specific flags would more sense than the default contract (why is a company/agency with their own logo and advertisement department paying me to put my flag somewhere?) and should get rid of some of the flag abuse. That is, until munchkin players start loading their crafts with one of each agency flag. Perhaps it would make sense to force players to use the flagpole for flag contracts? (i.e. disallow choosing a part variant but still keep track of it) As in, the goal is not only to plant a flag, but instead is to display the flag at launch, display the flag on the craft, and finally take that default flag added to the now-branded command module and plant it. One could still cheat the system by: landing a base linking one command module of each agency and then dropping getting a flag contract for the corresponding planetary body dropping a kerbal on the base (since flag contracts don't spawn on bodies with crewed bases AFAIK) look for the corresponding command module enter base, fetch flag exit base, plant flag ....but at that point, the amount of work needed to pull that off would not be worth it (IMHO). Or, players would end up with bases resembling billboards, which would be totally OK for me if they want to depend on flag contracts. *enters a daydreaming state* What if there were contracts to land a craft requiring one of those RFP-3 big flags? Or a RFP-F flat flag on 3m size (though I don't know if a contract can check for a specific variant of a part to be present). Illuminated by light strips for good measure. My KSP headcanon now includes agencies footing the bill to build asteroid bases with huge, obnoxious, neon-illuminated, branded billboards.

Sorry folks, but I'm not buying this argument. KSP1 has a roadblock before crewed manual gravity turns, in the form of pilots uncapable of holding prograde. The reward mechanic is in there : the player learns to use prograde/retrograde to orbit/deorbit, the player gets a pilot capable of holding PG/RG. And, mind you, there's KSP before your first orbit. And that phase is "You failed to get to orbit, but you went a little bit higher! Here, have these science points, now go buy some decouplers and bigger engines" I'm gonna offer the opposite perspective: the UI is horribly complex to beginners. There's what, 15? 20? UI elements on an unmodded game, and I remember my first games being overwhelmed by the amount of dials, not knowing what to focus on. Heck, the RCS button shouldn't even be visible until monoprop RCS parts are unlocked. What I mean to say is that hiding UI elements is a tool that may help focus the player and smooth the learning curve. I, for one, do not agree that having all the options available from the beginning provides a pleasant learning experience. That's good for a simulator, but KSP is a game, and I think KSP2 should have game mechanics.

Well, KSP1's learning curve is horribly steep because of that. I know. I might be daydreaming, but: What if the game told you hints about how to prevent the same mistake, but afterwards? Like "It looks like your rocket suffered an unplanned disassembly on ascent. Yadda yadda yadda, joke joke, blah blah blah. Here, the folks in lab coats have designed a Venturi tube, slap one on your rocket and next time throttle down to keep that Q number under 50000." "Mission control saw a fireball where your rocket was supposed to be during descent. Next time carry these thermometers so we can measure the temperature. Some folks are interested to see if there's a relation between heating and the descent trajectory." So I'm talking about transforming the core loop of "design→launch→explodes→design" to something more like "design→launch→explodes→new hint/tool→design". So yes it's about taking tools away, but also about giving the players those tools just after they realize they're gonna need them.

I'll respectfully disagree with that - one doesn't need temperature gauges or barometers to strap some SRBs onto a cockpit, hit spacebar, and start the KSP core gameplay loop of "launch something, launch it, watch it explode, repeat". Then again, I'm no videogame designer, and I cannot fully foresee how such a feature would impact gameplay, balance, engagement, or the learning curve... but I hope it can be positive. I guess this is one of those things where one approach cannot please all the crowds at once.

Wow, that sounds awesome! (to me, at least) Personally, I'd leave that to some other mod like F.I.G. (from @linuxgurugamer's FruitKocktail). Or at the very least, make sure it doesn't conflict with F.I.G. Or make F.I.G. play nice with your mod so it fills one slot with flags, the rest of the empty slots with repair kits. If you're making a mod, the easiest way to deal with this is to just write it in your mod's README, and shift responsibilities to the users. There's nothing wrong with that.

There's one thing in KSP1 that keeps bugging me every time I've started a new career game. As of KSP1, when starting a career/science game, you've got: No thermometers No pressure meters No accelerometers (When using SCANsat) no radar altimeters And yet, the UI has: Overheat indicators and F10 thermal view Atmosphere density indicator (below the altimeter) G-force meter (right of navball) Altimeter OTOH, one of the things that I learned when using KER is that if I want the UI, I must plop a part onto the controllable part of the craft. Which makes sense IMO. So I wish that KSP2 would unlock UI elements as the player progresses, instead of full UI from the beginning. Research thermometers, you get temp gauges. Research inertial gyros, you get prograde/retrograde indicators on the navball. Upgrade the tracking station, you get sea-level altimeter. And so on. A hardcore version of this idea would be to tie UI elements to parts in the craft, KER-style. But this would need some QoL in the form of "always add flight instrument parts to probe cores and pilotable cabins". Ideally this could lead to "know your instrument" tutorial missions, to soften the learning curve of KSP. Get this experimental part, put it in a sounding rocket, and watch its readings. Maybe do something when the reading reaches a threshold. Would this be a chore to seasoned KSP players? Yeah. So make it skippable. But I would expect fans of the caveman challenge would love this. Maybe the "right" way to achieve something like this is to make the KSP2 UI architecture more mod-friendly, so mods could add (or remove!) flight instruments. I wish for the possibility of having KSP2-KER fuse seamlessly with the KSP2 UI.

I disagree: Career mode has contracts/missions that require planting flags in order to be completed. Ditto with Making History's "plant flag" mission node. Planting a flag gives more XP to the crew, compared to just landing & EVAing on the surface Marking visited biomes (for those completionists lime me who like to squeeze science out of every minmus biome) Flags do serve several purposes. Besides, this could be an opportunity to make pilots more useful. I can picture only engineers being able to use repair kits, only sciencists being able to use EVA science kits, and only pilots being able to plant flags.

After messing with the 1.11 update for a while and the science kits and repair kits in the inventory system, I noticed that kerbals still carry one deployable flag (AKA "Extend-o-matic Series A1 Deployable Flag") somewhere in a magic zero-mass pocket. And they can EVA, plant a flag, go into the craft, magically replenish the flag, go EVA again, and potentially plant an infinite number of flags that way. So, I'd like to kindly ask for deployable flags to become inventory items. So, ideally, players would have to remember to put a flag or two in the inventory slots of lander capsules. I think this bit of inventory management would make sense for the gameplay.

I just completed a Kerbin circumnavigation during my career save. Behold this screenshot from BTDT: I made like a hundred screenshots to document the trip. I think some of them are out of order, because uploading so many images to imgur is annoying, so sorry about that. I run KSP modded. Among others, I use ScanSat, Mechjeb, and the Malemute rover parts. You'll find some commentary in the screenshots. So this was nice, and it took like 15 Kerbin-days. After carefully re-reading the rules, I see that I might be disqualified by ferrying the rover. But, you know, technically I left KSC with the rover, and then it just shedded its useless outer skin when it turned into a butterfly. Or the outer parts "just broke" during the trip. Or something.

Just wanted to drop by to say thanks to @hoover2701. You took the silliest KSP add-on and made it even sillier and funnier ! What's not to love?