kfsone

Disclaimer: I do think KSP2 has to give people a dashboard for their gameplay experience. The KSP1 science tree was a compromise between sandbox and hardcore simulation that was satisfying the way a lethal overdose must be. Typically, skill/research/science trees in games have two very important roles that were entirely absent in KSP1: 1- Theme parking: Do your thing to earn more of your thing. D&D lets you choose where you spend your skill points because if you want to play a rogue, you don't want the game foisting str and wis on you; New World turned off a big chunk of players by downgrading the drop chances of player-appropriate gear to encourage trade; if a player wants to build orbital bases, how did their last science spend force them to take 7 new wing-surfaces? 2- Guide rails: Part of the beauty of KSP1 was abusing parts in constructive ways. Those 7 new wing-surfaces might actually have a decorative purpose for building your orbital, but it's pretty unlikely, and KSP1 exasperated that issue by eventually throwing so much stuff into each science gain that you would never bother to engage with a lot of it (I *still* occasionally discover new stock parts or their roles, after all this time). Making me pay 1500 science for 7 wings I don't want so I can pay 3000 for a landing gear I do want and a bunch of "crap" I don't care about ... feels like dealing with my bank. Total finger-in-the-air: I'd instead have "advancement" nodes with multiple unlock conditions and possibly no science, and which start with a minimal number of parts the way the root of the tree does, to encourage you to try. I mean, there's not much point in getting landing-gears until you have the ability to go somewhere to land: so surely you need to either have tried to land back home or done a fly-by behind another body before you start on landing stuff? (In this particular play configuration)

I've been working on a Mun base for a while now, and it's been a brutal learning experience, that I think I can boil down at this point to: I can't seem to stick things to the ground. I'd built a little mobile crane that could carry new extensions, line them up and dock them, but during landing my 3rd component, the instant the base & crane unpacked, the crane either exploded so hard that pieces of it left the kerbol system within a few minutes, or the crane simply landed on the sun. The base also occasionally had a tendency to fly up and meet me during landing, but not in a good way like you'd want. I removed all the auto-struts and that seemed to help. But now, every time I fly into range of the base or every time I exit timewarp, the base leaps up off the surface or begins making a hard turn. Until I turned on "Pause on unpack vehicle" and "unbreakable joints" this would destroy the base 1 time out of 3. So I did a small experiment and used some of the "anchor to ground" elements from KAS etc, and they seem to have the ability to stay put, but I've put a bunch of effort into this base at this point, and I'd like to know if there is some way that I can affix an existing base to the ground? I tried putting a stamp-o-tron or a K&K ground anchor with a docking port, but my base is big enough now that it can't get close enough to dock. Is there some way to affix an existing base to the surface it is sitting on? A part? A mod? An edit of the SFS file?

I disagree slightly - not stripping away time-sinks, but providing flexibility. Plenty of people just aren't going to give a dingo's kidney about bases, even in KSP2, and plenty of people are going to come to KSP2 just for the base building and are going to be going absolutely stir crazy that they can't just request part delivery and spend all their time putting their base together. (My wife is an MMO-housing addict and she keeps asking me questions about building bases in KSP2; 'Is it multiplayer? Can you fly the parts I need so I can focus on building my colony?') I don't think you can make a 1-size-fits-all general play mode for KSP2, not with rocket building, colony building and interstellar travel - it's too diverse. But if I've found one thing about KSP is that's every time I've come back to it after a few months/year hiatus, I totally get into some one particular thing. This time - for reasons in the OP - I've ended up spending weeks focused entirely on building this one mun base. I imagine - I hope - KSP2 won't just add breadth, but will invest KSP1-learnings to also give some depth to the different focus-channels/time-sinks so that the game is more than just a choice between "rockeet" and "get to the mun->build a base->fly to Alpha Kerbturai->victory" If the entire slog of building your first mun colony has the sole purpose of launching your first interstellar, if building the colony can't also be fun and rewarding in/of itself, then a lot of players might not bother engaging with the work needed to work on the second. Conversely: a lot of players aren't going to bother spending months or weeks building a mun base just to punch a ticket that lets them fly to another star?

This is really where I'm speaking to with the science stuff: we're aligned in thinking about the clicky science being a distraction from "rocketeering", but I think from a purely design perspective that when players are building bases they're going to need an investment stake: rocketeering means you're building bases for resupply, etc, so they've already got their stake and forcing them to prance about placing seismometers or triangulating theodolite measurements is going to kill their enjoyment. Building space-stations/bases, tho, if you're not playing rocketeer, and if you're not - oh god I hope not - wandering around in the base playing some kind of minecraft/space-engineers housing game, then you probably came to KSP2 base building because you wanted to play the SpaceX starship debarkee and there needs to be stuff that encourages you to waddle around with kerbals and feeds back into the other gameplay systems without crippling them for rocketeers.

Again, one of my reasons for the post was that base-building has been clearly indicated to be a big part of KSP2. I would argue that - per my #4 - the "grind" in KSP1 is that you are _either_ building vehicles and traversing space, or you're trying to build a base and the flying/building is an inconvenience to you. Please realize I'm only saying that one is a grind to a person focused on the other, in particular because - even in story mode - KSP1 discourages you from learning from your mistakes, it's too expensive. You can't pull off a Starship in Story Mode unless you're willing to put a larger amount of time into doing funding missions. Instead, you revert your way thru to a starship. And that's because there's just no good tie-in between the fundamentals - building and flying - and the progression system. The amounts of science you get from a bad launch are pitiful, there's no wind-tunnel/test stands to mess with for experiments you can afford not to revert.

You're underscoring a point I hoped I had made in the OP; So far all indications have been that KSP2 has invested significant work into base construction. There will be people who are playing KSP2 for building rockets who'll have _some_ need of bases here and there, but really don't care too much about solving life support issues or "doing" science that doesn't get them their next engine; and there are going to be people who want to build space-housing, and don't care about "doing" science to be able to build 1.875m connecting tubes... Deeper play-styles should be opt-in, so you can decide you want to have to run the full gamut of space-program missions to build your first base on Duna: send a digital watch with a camera and an fm radio to get your first 80x60 black and white image; get enough reward from crashing a few landers that you won't even think of reverting and send your first few probes, send a high-res camera so you can unlock suitable landing stuff like legs or drogues that fit the place you're going to. Given the mission stuff added to KSP1, there's clearly some market for that, KSP1 just didn't have to substance to really sell it beyond the core aspects of "build rockets" of KSP1 itself.

I definitely do not want to suggest that KSP2 should be No Man's Sky But if - as the show and tells have suggested - they want more of a base-building focus in KSP2, there's got to be some justification for having kerbals out in the yard, so to speak. You're never going to make it non-repetitive unless you're _really_ doing science somehow - but you could flesh it out by taking something like surveying that requires you to keep moving equipment around. At the same time - per item #4 - I think you should get a healthy stream of science from actually using parts, which plays back into the focus on flying and building. In KSP1, you build rockets. Building bases is really "end game" grind. They've said that building bases is going to be a major factor in KSP2, but all I can think is: why? To me, building rockets and stations is to building bases what lego mechanics is to having 2 blocks of lego. I'm not everyone and KSP1 has done well, so this just comes back round to the different options for and levels of play - there are definitely folks who'll find bases meaningful if they can move their kerbals around in them, so long as there's also a hook, such as giving them the option to play at IVA level and stand your kerbals at specific research displays to finess where your science/innovation progress goes.

The majority of people out there describe KSP2 as a "quirky rocket simulator": it's "a game about building and flying or crashing rockets". What about landing? "I guess, I never really bothered with that". When you say "Moon landing" to someone, they think about guys bouncing around on the moon playing golf, setting up experiments. You might do that once in KSP1 but that quickly teaches you that there's no value to it. We started to get closer to that kind of aspect towards the end of KSP1s development, but it wasn't really "game play". All the other science experiments were still instantaneous. The only really interesting science project I remember from KSP1 was one where you had to drop seismometers to support triangulation. The next thing people think of is photography (well, "pictures"). The famous reflected-in-visor picture, landing site pictures, etc. People get most excited about pictures of Mars when there's the "landing site" oval on them. In KSP1 that gets wrapped up with biome discovery, and again it's instantaneous. Finally, there's the aspect of discovery and innovation. The KSP1 knowledge trees felt, from the offset, like procurement not discovery. There's a total lack of causality between what I do as a player and what my scientists uncover back home, the research tree was also terribly tuned - sometimes you struggled for weeks to get one absolutely critical node, and other times a single flight unlocked you so many nodes that you miss out on critical additions because you just never got around to trying them. A huge chunk of player retention and playability probably went over many players' heads because of this. Given the success of KSP1 there is clearly a decent sized audience that just wants to see their designs land on other planets, but with KSP2s emphasis on base building, there REALLY needs to be reason to want to have a base. I've recently been trying to force myself to build a mun base in KSP1 and ... it's hard overcoming the obstacles given that once it's built, my next step will be to leave it. My point is that I am going to suggest some feature flag ideas that I think would create a richer, more engaging, deeper experience for people who aren't already hardcore KSP1 devotees following IP loyalty rather than things I think should be mandatory play requirements. 1- Science areas: Instead of a single science currency, a split science research system that tempers different knowledge areas and allows different science instruments the opportunity to serve multiple roles in producing science units. Trivially: Orbital Mechanics, Physics, Chemistry; or you could split it into more complex categories like "materials science", "super conductivity", etc, etc. Thinking point: Taking pictures of different surfaces at different resolutions might contribute to guidance systems and landing systems; Sampling atmospheres might contribute to flight controls and surfaces... 2- Science activities: Even if you reduce it to what an away team might do with their "tricoders" in the most mundane episode, there's purpose and input required. In KSP1 you can click EVA, right-click, left-click "surface sample" and hit b in under 3 seconds. Instead, try to _reward_ the player's success in arriving by _making use_ of their interest in being there. Create run-times for experiments, create interference between experiments, maybe use error bars that diminish with science/skill/research, create non-terminal failure scenarios that tie back into research & discover. E.g: flight instruments that are subject to initially undocumented shielding-related failure that leads into upgrade research, a science instrument that turns out not to work when exposed to sunlight on the Mun leading to housing upgrades, telescopes that lead into cooling upgrades, etc, etc. Choose a smallish lexicon of 'experimentation' actions - try turning it off and on again, try running in sunlight vs dark, try doing it at a different altitude or a different velocity or in a different atmosphere, try moving it 100ft from another instrument, etc. Even if science still worked KSP1 instantaneous style, this would give the instruments infinitely more "hands-on" time value. Thinking point: what can you take away from this instrument to become a carrot for interacting with it more directly a handful of times without making it so annoying I'll never bother? 3- Science mysteries (anomalies): When we send a probe to mars, we are incredibly focused in the instruments placed on it for their operability but more importantly to the area they are going to and the science they will conduct. Some of our recent landers have very high-res cameras not for the photo ops - although that helps with funding - but for things like inspecting how the rover interacts with the soil/terrain or looking at the results of geological/mineral instruments. In KSP1 when you build a probe for Juno you just shove all the available science instruments you can on it and ship it, since the restrictions on instruments tend to be very coarse grained: atmosphere or not, daylight or not. You don't have to worry about temperatures, radiation, non-boolean levels of light, magnetic field, etc. And there's no overlap for you to lean in to. Thinking point: can we _excite/reward_ the player for losing signal with the first probe to arrive at Juno due to previously undetected conditions that introduce additional mechanics/gameplay? Thinking point: instrument specialization vs mass -- a probe with 100 generic instruments producing as much/less science than the same probe with a good combo of 3 more specialized instruments (see also science areas). 4- Risk: In KSP1 "story" mode, flying and crashing becomes not-an-option, and there's no soft middle-ground for testing things you build in story mode making it very easy to get bankrupted with no real way to recover, unless you're willing to keep fast forwarding until you get a small enough mission you can fly with enough payback to get you flying again - although that can take actual real time days (or not flying, just fast forwarding, checking missions, saving & reloading). Secondly, there's no payback from flying and crashing in KSP1. When Jeb slams into the ground because the wings came off, there is only what you learn directly about the flight, which is no help if you won't have the money to fly again without reloading the game. This leads to people _not_ enjoying the most fun part of ksp simply because it's stick followed by stick, so as soon as those wings come off, esc -> revert. I think reputation was never fully realized in KSP1, it should be a sort of backup currency that can be leveraged to produce money at the cost of having to do "photo op" missions. Get kerbals to test-fly some shonky variant of a new engine for someone; get some 3d pictures of Duna to showcase Kony's new K-Ray KvK Player (hmm, these pictures are great, but we really need them to be more blue than red, the K-Ray player has a risk of fire if more than 90% of the pixels are red instead of blue...) Thinking point: failure sure be rewarding enough that most of the time players will risk failure-with-a-cookie vs failsafe-without-a-cookie, but sometimes there needs to be a choice/alternative: I shouldn't be unable to move on to duna because I have not yet returned people from the surface of eve.

"5... 4... 3... 2... 1... ... ... Oh, the batteries went flat on the pad" Would it be possible for a mod to make the launch holders/clamps/gantries have infinite power to share with the vehicle?

Our Guru, who art on Linux, gameful be thy design... The urge to suggest variations on the times is strong, but knee jerk Can I ask what sort of scope one has for variation? I mean, would it be possible to build on this a way to have tiers of the different experiments such as a dumb level 1 thermometer that needs 5s to take a reading (if it takes a day to read a thermometer, I'm never going to the drs office when I have indigestion again)? Can the amount of science a particular "study" gives be controlled, eg a device gives 5% if you get a minmum 5s sampling, but needs 60s+ to reward10%, 5 minutes to get 20, 1 day for 100%. { t<5 :- 0%; 5<=t<60 :- 5%; 60<=t<300 :- 10%; ... } (In gameplay terms: you can get flyby measurements, aerobraking measurements, and study measurements) When most people think of the apollo landings their first mental image is either amstrong+flag or an astronaut in mid-stride carrying some complex looking piece of equipment: the latter was them deploying science experiments. I think a lot of kerbal "player"s were expecting to land on planets and do ... something. Instead of land on planets, place a flag and think "next time I won't bother getting off the ladder". The single most interesting science experiment in kerbal to date was the seismology one, which varied results based on how many probes you dropped, so you actually felt like you were even remotely involved in the science. It would be awesome to have more science options that require you to actually spend time on the surface >doing<: "take 5 x 5 minute readings, 100m apart" with a +/-1m window. Surveying ... coordinating two kerbals to make measurements... ZOMG. Thanks so much for this mod!

I realize someone is going to say "try tilting the vehicle" but that doesn't tell me which way is *forward* I tested this beast on Kerbal and empty, as it is, it was able to move around slowly but sufficient for ground-based docking. On Minmus, no such joy. The only thing it can or will do is slide sideways or in the opposite direction to which I actually want to go. At first I thought it was on a slope, so I let it roll for a while until the way I wanted to go was downhill. Then it would only go uphill, and only sideways. I figure I have configured the wheels wrong, but then I realized - I don't know which way is forward. Or, even if forward is a direction this vehicle understands. It has a probe-style (up/down oriented) controller. But I'm also not sure which way is "forward" for a given wheel. I thought I had set the motors/steering up correctly on them, but now not so sure. I installed MechJeb and tried to use the rover-autopilot but it either accelerated away from the target or it simply sat there making angel-wings with the wheels. In particular, is a wheels sense of "forward" independent of it being rotated/mirrored to be placed? Is it affected by being removed from symmetry?

Awesome on 1 and 2; above awesome on 3. I wrote my own save-file editor donkey years ago and I added rigid/autostrut options to this weekend to see if I could fix this, but I totally overlooked #3 - brilliant. None - but while I was checking, I have a lander parked next to it and I noticed the landers now have a "tether to ground" option. Maybe I should add some so I can use that Clamp-o-tron jr. Thinking about it, one of the last changes I'd made was adding EVA mounting KAS TJ-2 so that I could land a shuttle reasonably close and then extend that out instead of trying to dock (which is funny, because in order to do so I had to land a little rover and dock that) Ah, a LOT of it is eva assembled. If re-mounting them can fix it, that leans in to my theory that there's some bad data accumulating in saved files and causing buggy behavior in the game proper, which was why I ended up investigating "what if I try changing different properties between saves" Awesome answer, lots to chew over.

At the time, it was pretty heavy - all the fuel tanks were full and all the ore tanks were full. But maybe there's some kind of simplification algorithm that spreads the weight out over the bounding box of the base, and since it's L-shaped the massively reduces the weight/m2. That said - I figured it out and was able to fix it. I happened to have 40 QA/CI machines idling, so I ran a lot of different combination tests and found one specific pattern that fixed it and allowed me to recover, but it has to be done in a single game session: - modify the save: set all the parts to "rigidAttachment False", - load the save, now explodes like a scene from Gravity too, wait 90s, - re-modify the same save: set all the parts to "autostrut Off", sas modules to "wheelAuthority 1" (%1), - load, as above but now looks like one of the secondary-collision scenes, wait 90s, - re-modify the same save: set all the parts to "rigidAttachment True", - load, back to the original flip & smash, wait 90s, - re-modify the same save; set all the parts to "autostrut Grandparent", - load -> fixed - save, quit ksp, restart - load -> still fixed when I say "load" I don't mean quit the game, I mean: the equivalent of hit-escape and select 'load' -> 'quicksave'. Able to recover the same save game now twice by repeating those steps (the timing is totally approximate, just wait until the big chunks have settled). Possibly there's an invalid value in the save that induces some buggy behavior that doesn't get cleared out properly between reloads, but - again - this is what happened to me way back in the day when I built my first modless minmus base in my first game

Might be you're taking "ambient sound" literally, but in the wrong direction. Neither Norrath nor Kerbin are real. Maybe someone did just go to a zoo and record 30s of sound, but that's unlikely. At the very least, they had to do some amount of digital editing to create a loop that wouldn't glitch. You'd need a non-trivial amount of time, effort, money and experience to get a game-worthy loop of sounds from a zoo. To get one you could use without editing/mixing? You'd need to be hot excrements in terms of finding the right window of time (no kid screaming a foot from your mic), accoustics (aka your recording sounds like 30s of someone taking a wiz, was that the lion?), and balance (the sound of nothing because all the animals were asleep). Chances are that the ambience loops in Freeport and Space Center were manually edited by mixing and balancing and tweaking various other PD sounds. But I'm glad I'm not the only person who was half expecting the sea-zone/dock bar music to kick in at any second

I've just spent the last few days building-up a mining base on minmus so that I could ferry ore or fuel up to an orbiting transit station. After taking a short break, I load the game back up and ... it seems like I saved just as a small black hole passed my station; switching to the base is absolutely 100% concretely guaranteed to fling it up a few dozen meters above minmus's surface in a severe spin that slam big chunks of it into the ground at 100s/m/s, trashing it. Is there a trick, setting, or mod I can use to salvage this and pin it back to the ground or something? Is there a trick, setting, or mod I can use to stop this happening in the first place? It's happened to me with/without mods, and at the moment I have a fair number of mods installed. I don't know if maybe the original problem was fixed at some point and now my modlist is making it break again? Save game: https://www.kfs.org/oliver/ksp/quicksave.sfs (the base is "Lander X" on Minmus). I've tried backing out all the mods that aren't actively used for parts in the base - but, again, this happened to me without mods too. I've tried switching to the other lander, I've tried turning changing sas settings as soon as I get in, I've tried landing another vehicle nearby. As soon as the base loads, BOOM, off it goes. --- edit: mod list when it happened this time: [x] Science! Continued (xScienceContinued 6.0.0.9) Astrogator (Astrogator v0.10.3) B9 Part Switch (B9PartSwitch v2.20.0) Breaking Ground (BreakingGround-DLC 1.7.1) ClickThrough Blocker (ClickThroughBlocker 1:0.1.10.17) Community Category Kit (CommunityCategoryKit v5.2.0.0) Community Resource Pack (CommunityResourcePack 1.4.2) Community Tech Tree (CommunityTechTree 1:3.4.4) Contract Configurator (ContractConfigurator 1.30.5) Contract Pack: Field Research (ContractConfigurator-FieldResearch 1.2.2) Deployable Engines Plugin (DeployableEngines 1.3.1) Distant Object Enhancement /L (DistantObject v2.1.1.7) Distant Object Enhancement /L default config (DistantObject-default v2.1.1.7) Dynamic Battery Storage (DynamicBatteryStorage 2:2.2.5.0) Editor Extensions Redux (EditorExtensionsRedux 3.4.3.5) Engine Lighting Relit (EngineLightRelit 1.6.3.2) EVA Refueling (EVARefueling 0.1) Firespitter Core (FirespitterCore v7.17) Harmony 2 (Harmony2 2.0.4.0) Hide Empty Tech Tree Nodes (HideEmptyTechNodes 1.3.0) Kerbal Attachment System (KAS 1.10) Kerbal Dust Experiment (KDEX v2.0.2) Kerbal Engineer Redux (KerbalEngineerRedux 1.1.9.0) KSP Community Fixes (KSPCommunityFixes 1.12.1) LoadingTipsPlus (LoadingTipsPlus V1.9) Making History (MakingHistory-DLC 1.12.1) Malemute Rover (MalemuteRover 1.4.0) MechJeb 2 (MechJeb2 2.14.1.0) MechJeb and Engineer for all! (MechJebForAll 1.3.0.7) Mission Controller 2 (MissionController2 2:3.2.0.0) Module Manager (ModuleManager 4.2.1) Near Future Electrical (NearFutureElectrical 1.2.3) Near Future Electrical Core (NearFutureElectrical-Core 1.2.3) Near Future IVA Props (NearFutureProps 1:0.7.1) Near Future Launch Vehicles (NearFutureLaunchVehicles 2.2.0) Near Future Propulsion (NearFuturePropulsion 1.3.5) Near Future Solar (NearFutureSolar 1.3.2) Near Future Solar Core (NearFutureSolar-Core 1.3.2) Near Future Spacecraft (NearFutureSpacecraft 1.4.3) Part Wizard Continued (PartWizardContinued 1.3.9) Patch Manager (PatchManager 0.0.17.3) PlanetShine (PlanetShine 0.2.6.6) PlanetShine - Default configuration (PlanetShine-Config-Default 0.2.6.6) Procedural Fairings (ProceduralFairings 1:v6.2) Procedural Parts (ProceduralParts v2.3.0) PWB Fuel Balancer Restored (PWBFuelBalancerRestored 0.2.1.7) RCS Build Aid (RCSBuildAid v1.0.6) ReStock (ReStock 1.4.3) ReStock+ (ReStockPlus 1.4.3) Rocket Sound Enhancement (RocketSoundEnhancement 0.7.2) Rocket Sound Enhancement - Default (RocketSoundEnhancement-Config-Default 1.0.2) SCANsat (SCANsat v20.4) ScienceAlert ReAlerted (ScienceAlert 1.9.10) SimpleFuelSwitch (SimpleFuelSwitch 1.4.1) Smart Parts (SmartParts 1.9.16.2) SpaceTux Library (SpaceTuxLibrary 0.0.8.4) StageRecovery (StageRecovery 1.9.5.4) The Janitor's Closet (JanitorsCloset 0.3.7.8) Toolbar (Toolbar 1:1.8.0.7) Toolbar Controller (ToolbarController 1:0.1.9.6) Trajectories (Trajectories v2.4.3) Transfer Window Planner - Fork (TransferWindowPlannerFork v1.9.0.1) USI Tools (USITools 1.4.0) Utility Weight (UtilityWeight 2.0.0) Waterfall Core (Waterfall 0.8.1) Waypoint Manager (WaypointManager 2.8.3.3) Zero MiniAVC (ZeroMiniAVC 1:1.1.2.4)

I just stumbled onto this mod and it gave me a mission to do weather research on the mun. Is there any kind of late-stage guide to this mod that would help me figure out what that mission actually entails?

ED burned me out so hard I didn't even realize I'd (basically) abandoned Trade Dangerous until I jokingly typed "pip install tradedangerous" and it did because the guys who picked it up did a kick-ass job.

Advanced transfer planner is going into an infinite loop trying to create a node from duna -> kerbin for me, all of a sudden. Full log and video to follow: And it just keeps repeating those lines. log: https://www.kfs.org/oliver/ksp/mechjeb-player.log.zip (I turned on flush writes) video: https://www.kfs.org/oliver/ksp/mechjeb-infiniteloop.wmv

I think it'll also be hugely helpful for teaching the players the game and ease the obvious appeal of doing everything in a serial, utterly risk-averse style.

<fx: stock-exchange bell ringing>

TL:DR; A meta-data field for grouping flights/vehicles/etc, as well as for giving the game a way to know what you think you're trying to do. KSP1: You pick up a mission to plant a flag on minmus and another to do some science. You start building a craft, put a scientist on the crew, launch, open map, select target (incase you come back to a save later), try to launch but don't quite make it. Recover/revert. Tweak craft. Launch. Open map, select target, ... launch ... select target ... launch ... select target ... orbit! Wait, why is there no scientist? Oh, I changed a part and it filled the slot with an engineer? This would be a trivial piece of UI with a lot of modder potential. For main gameplay it just needs to know a project name ("Kerpollo", "Kermini", etc), perhaps a primary body and/or some kind of mission type (flight, science, construction, etc) that can help check one or more specific type of crew are aboard when you fly. Modders might extend this to let you choose specific goals/missions to complete or whatever, let you add project patches... But somewhere in the UI you'd have a way of saying "hey, this is the Project I'm working on" and the game could do things like set your target based on the current project. Help you group vehicles/launches together (on the map, only show me Project Kemini vehicles, e.g).

I can't begin to figure out the cause - no amount of autostrutting or rigid attachment seems to help (*1); but it made me wonder if there isn't a mod that lets you make fairings transparent/hidden/invisible(*2) so you can see what's going on during a launch for scenarios like this that? (*1 even using editor-extensions "all rigid" etc) (*2 the same satellite launches fine without a fairing until everything goes horribly wrong when speed picks up enough)

I ended up here looking for the same solution, I'd launched a probe with 3 OKEB-45 Nautilus panels, and apparently two of them came off during warp while flying an unrelated vehicle elsewhere. I sent an engineer up to recover them and try to reattach them but they were marked "BROKEN", so I had to fix them first. When I fixed them and attached them to my repair vehicle, they immediately broke again. And when I tried to attach them to the original vehicle, they immediately broke again. So I used SFSEd to edit the save from before I recovered the first panel and changed the PART -> MODULE -> deployState to RETRACTED but I also noticed they were marked as "rigidAttachment". Changing them to "rigidAttachment false" fixed the problem with them breaking on reattach; and if you don't want to have to repair them first: try "RETRACTED" instead of "EXTENDED".

I've seen the same issue but only ever with the inflatable docking port and only with *specific* inflatable docking ports, and for now I'm thinking mea-culpa: one time I think I set "control from here" before opening the airlock, and the other times the problem went away when I used a different port on the same vessel, so I think opening the airlock throws off the rcs thrusters.

Could use some clarification of "Launch to Rendezvous": I can usually get MJ to rendezvous with a well-placed module in a mostly-circular orbit from e.g KSC with 1-2 practice launches, but as the orbits get more complex, I suspect I'm using the tool wrong. In particular, the TARG button confuses me: when it's greyed out, the alt/inclination are hidden, but it still seems to use the values in them. When it's green, which elsewhere seems to mean "this is in effect" it shows those values and still uses them as overrides. This is my SOP after the vehicle is eased onto the pad, open ascent guidance, open map, right-click target -> set as target, close map, click 'launch to rendezvous', click 'engage autopilot', open 'utility', enable autostage, wait for vehicle to disengage autopilot, revert to launch (end of practice launch), repeat My questions are: - What DOES the target ("TARG") button do? (just show/hide fields?) - Are there magic values for alt/inclination to tell mj "you figure it out"? - Does manually changing the "launch to rendezvous" angle prevent learning?