AVaughan

That is stock behaviour. It's called show activation toggles. If you don't see something like that, then open settings and check you have advanced tweakables turned on.

I think that Mandatory RCS does most of this. (I've not tried it myself, so that opinion is based on the forum OP). https://forum.kerbalspaceprogram.com/index.php?/topic/154658-141-mandatoryrcs-15-part-pack-11-reaction-wheels-nerf-sas-rotation-persistence/

Personally for such a light load, I'd replace the Mainsail with a Skipper. That is lighter and will fix the TWR. I also suggested fins earlier, since I want my rockets to be aerodynamically stable.

@Trekkie148 It's a bit hard to be sure without a screenshot, but it sounds like your design is aerodynamically unstable. In other words flipping out of control is to be expected. You normally fix that with some fins near the base of the rocket, to move the centre of lift backwards. Check the centre of lift and the centre of mass display in the VAB. For a rocket to be stable, the centre of lift needs to be behind the centre of mass (ie like a dart or an arrow with the mass concentrated forward, and feathers aft). Note that this needs to apply during flight, not just at launch time. For a rocket with a heavy mainsail, and no upper stage, your centre of mass is probably moving backwards during the flight as the mass of fuel decreases. Going too fast in the atmosphere is also likely to lead to extra drag, which might have the effect of moving the centre of lift forward. (A Mailsail sounds overpowered for the rest of your rocket, so unless you are throttling down, you are probably going too fast in the lower atmosphere). All of this is reflects reals physics and is not a bug.

There is also a pointer to it in big bold print at the top of the OP. But maybe it's time to retire this thread and let jrbudda start a new thread, where he can manage the OP.

Obviously everyone will have a different opinion. Personally for a mod like that I would want: Compatibility with procedural tanks and fairings, FAR, KIS/KAS, real chutes (or FAR's real chutes lite implementation, but with more available chutes sizes than stock KSP), KCT, scansat, life support mods. I'm guessing most of that will 'just work', although tank size unlocks might need tweaking in the tech tree. Maybe also want to tweak some of the science part sizes. Surface attachable engines for all (or almost all) engines. (So that engine clustering without thrust plates/adapters is viable. With procedural tanks and fairings, this means booster diameter/design becomes a player decision, rather than being dictated by the available tanks/engines. Optionally an unmanned before manned approach (An optional mod changing tech tree and maybe available missions would be fine). Optionally a real fuels lite/real engine lite approach. Split engines into 6 or so fuel types. Solid fuel, RP-1 + Lox, Liquid hydrogen + Lox, hypergolic, ion, nuclear with hydrogen/methane/ammonia. Optionally maybe add methane + Lox late in the tech tree. (Maybe just consider KSP's fuel + oxidiser to be RP-1 + Lox and monoprop to be hypergolic. That allows an automatic minimum level of compatibility with engines added by mods without compatibility patches). Engines with different performance characteristics (isp curve, twr, max burn time, restart capabilities, engine vectoring, throttability, fuel density, fuel boil-off) add to potentially interesting design time choices and trade offs. Personally I don't need ullage requirements or test flight type random failures (far too often I simply revert or reload if test flight kills an engine during launch, but limited relights and a deterministic max burn time adds potentially interesting design time constraints). Similarly I don't need RP-0's highly pressurised tanks. I think that it is better if KER/mechjeb will show zero dV if the wrong fuel/tank type is selected for a stage. That is preferable to getting suborbital over the Mun and discovering that your landing engine won't start because the fuel tank isn't highly pressurised. Similarly make any insulated tanks visually distinct from non-insulated tanks, so that provided players grab the right tank type in the VAB, they don't suddenly discover that half their fuel has boiled off just because they didn't toggle insulation in the VAB. Maybe only allow insulated tanks to be used for fuels subjected to boil-off. Possibly have a tech tree unlock for upgraded insulation for reduced boil-off for longer missions, again meaning that once you have it unlocked in the tech tree, you don't need to toggle it on individual tanks to get the benefit. If you have the different fuel types from the above, then ISRU should be adjusted so that not all fuels can be refined on every planet/biome. Again more design time considerations that affect the choice of fuel/engine. Some players will want reaction wheels nerfed (some players will even want them removed). I'm fine with nerfs, as long as MechJeb/Stock SAS can hold an alignment before/during a burn. (Assuming a symmetrically balanced spacecraft). Relying on RCS to hold attitude for all maneuvers seems to lead to oscillations and too much wasted monoprop. Leaving reaction wheels torque untouched when you rescale mass and length should already be a significant nerf. A lite version of persistent rotation (only need the bit of persistent rotation where rotation isn't stopped by timewarping or switching scenes). Some players will want Remotetech integration. Personally I'd be fine without it (stock's comnet is enough for an RO-lite. I always find remotetech's flight computer to be too limiting and awkward to actually use. Plus I'm still annoyed by the times it just cannot reliably point a vessel without reaction wheels towards a reaction node. Far too often it just oscillates around the node, wasting rcs. I still remember the time it burnt through a vessels entire 1200 m/s of dV trying to execute a 400m/s Lunar capture burn, and was still on an escape trajectory. These days I would just manually align and spin up whilst have a connection, then just have remotetech's computer burn for the appropriate number of seconds for any burn that is required without a connection). If you want a Remotetech lite implementation then ditch the com delay, allow antennas to be deployed/pointed without a connection. (So that missions aren't toast if you are late deploying your antenna, and for easier handling of antennas for landers on bodies with an atmosphere). Possibly allow the player to manually execute full throttle engine and rcs burns without a connection, but require a connection for manipulating maneuver nodes and science transmission. Might also need landing legs in either more sizes or a larger range of sizes than stock. (The tiny legs are potentially still the right size for small unmanned landers, even without being rescaled. The large ones are potentially too small for a large lander, especially a single stage to orbit ISRU refinery/tanker, even if they are rescaled by the same amount as capsules/tank etc). Might be solved by just using different scaling factors for each of the stock legs, and/or adding a couple of copies stock landing legs with different scale factors. One thing I haven't talked about (but which is probably implicit is some of the points above is the scale factor. If we want to go realistic, but with round numbers, then a Mercury capsule was roughly 2m in diameter, Gemini was 3m, Apollo was 4m, Orion is 5m. So from that view point using tank and engine sizes in multiples of 1m seems reasonable. But even 1m seems large for probe cores. (Google says Sputnik 1 was 58cm). So I'd be tempted not to rescale probe cores and some of the tiny probe class engines by the same factor as some of the large engines. Maybe even leave some of the probe cores at stock scales. If we are talking tanks sizes without using procedural parts or tweakscale, then I think I'd probably want a 0.5m (or 0.625m) size 0, then a 1m, 1.5m, 2m, 2.5m, 3m, 4m, 5m size progression of tanks/fairings/heatshields/adaptors to give the player adequate choices and smoother transitions form one size to another. There are also plenty of stock parts where the size and mass just don't make sense. (Rockomax multihub 1.5 tons !! Also why isn't this a 2.5m part. It's only real use is in space stations, where most stock modules are 2.5m). When rescaling it would be nice to fix some of these for a more reasonable size and mass, rather than just use a blanket rule to rescale everything by the same amount. I realise this isn't quite what you are asking for, (and adding all those lite implementations of existing mods is probably too much work, unless you can convince the corresponding RO versions to accept patches to add an optional lite mode) but it's my thoughts on something that is a lightweight alternative to RO. There is also Sufficiently Realistic Progression Zero by @NotTheRealRMS that might provide some ideas/an opportunity for collaboration. https://forum.kerbalspaceprogram.com/index.php?/topic/154041-wip131-sufficiently-realistic-progression-zero/ .

I consider that expected. (Expected in the ksp case, not expected in the real world). I seriously doubt ksp is modelling a planet with its mass distributed throughout its volume. It's almost certainly simply modeling the planet's mass as a point source at the planet's centre. That approximation will work fine for anything on or near the surface, or in space. However deep underground, acceleration due to gravity will increase, since you are now getting closer to that point mass.

TBH, I'm more concerned with the landing on Earth. If something goes wrong with the transition from re-entry to vertical landing, then it's potentially going to be fatal for any crew members. Ejection might be feasibly, for some of the flight envelope, but making the control/crew cabin detachable, with integrated launch abort thrusters and parachutes for landing can get you both launch escape functionality, and similar landing escape functionality. (Again only intended for use on Earth, I agree that it isn't going to help at Mars, and I'm not talking about a capsule big enough for 100 people, just 12 or so crew, and only on the first few manned BFRs). BFR has a huge payload capacity to and from Mars. Using afew of tons of that payload capacity for a detachable crew capsule, in the case of a problem during earth ascent/landing might be worthwhile. One thing we learnt (or at least should have learnt) from Columbia and Challenger, is that vehicle and mission designers should consider the possibility of an unanticipated and potentially catastrophic failure, and as much as is feasible design the vehicle/mission so that the crew still has the best chance of survival as is feasible. (Yeah, you could transfer crew in LEO after the ascent. If you get things right, aero-capturing into Earth orbit and transfering crew in Earth orbit might also be possible at mission end, but if you anything goes wrong during that aero-capture, then what's the plan B ?).

Personally, I'd be surprised if the first manned BFR Mars mission carries a crew of 100. I'd expect more like 12-20 per BFR for the first mission. Possible even lower, especially if they decide to add a detachable capsule (think something similar to a re-entry capsule, with integrated abort thrusters) as a LES/landing escape system. I know that's not in the announced plans, but having some sort of abort capability if something goes catastrophically wrong during launch or landing seems to sensible, at least for the first few manned missions.

If you ignore the mass requirement, then you could use algae to reprocess CO2 (and maybe other wastes), then use the algae as a food source. (Or use it to feed fish/crustaceans or some other animals). However that is likely to be fairly heavy. But might be viable on Mars itself as part of the colonisation efforts.

If I want to use rcs for translation (eg for docking), then I normally set the rcs to translation modes only, and use the command modules reaction wheel + SAS to control attitude. Doing that I normally don't need rcs to be properly balanced.

Notice the term "Smart reuse". I fail to see how recovering only 2/3rds of the booster's cost (the added complexity of dropping the engine probably also adds significant extra costs to each booster, and possibly even new launch failure modes) qualifies as "smart reuse". This ULA scheme looks like a poor second cousin to SpaceX current program of Falcon 9 booster landing and re-use. And there a fair chance that it won't be operational before SpaceX is launching BFR, (which should be full reuse of both first and second stages). At that point SpaceX is probably about to retire the Falcon 9, (which is already flying as a superior example of reuse), leaving ULA still trailing by one and a half generations. If you are going to do a reusable booster, then landing the booster seems superior and smarter in every way.

My RO/RP-1 install uses about 4GB in windows task manager. But I have a fairly bare bones RP-1 install, with almost no part mods beyond the requirements, and low res RSS textures, and no graphics mods. Load time for me is about 5 mins on an old i7-860 with 12 GB ram. (Windows is on a 256 GB SSD, but games and the pagefile are on an HD). So I think a similar install should load on an 8Gb machine, but you should probably close as many other programs as possible first.

No point in building a booster capable of 24 hr turn around if the launch pads need 1 week between launches.

@Speedbird52 If you have the Steam version of ksp then you can access 1.3.1 from the betas tab. (Right click on KSP in steam, select properties then betas tab then select 1.3.1 from the drop down box). There is also probably a way to download old version from the ksp store or from GOG, but I don't have those versions.

Stratzenblitz75 did a 3 kerbal, 3 parts mission to Gilly earlier this year, without the litho-staging or eva landing tactics Hazardish used.

Well Elon said block 5 was designed for 24 hr turnaround (presumably based on a RTLS timeline). He also said the first booster would be pulled apart for a thorough inspection to validate the design, so hopefully there will be a faster turnaround for future boosters.

The outer boosters produce thrust that needs to be transferred to the central booster. That means that for a light weight core booster design that is already designed and is approaching its maximum materials design limits, you need to redesign the central booster, so that it is capable of supporting those higher loads. Not impossible, but a lot of work. You also need to consider the aerodynamics of the core plus boosters, especially near max Q and separation. (Also how the strap on booster will transfer that thrust to the central core). None of this is a problem if you are designing the rocket from scratch and know that it will use strap on boosters, and design the rocket accordingly. But it is a lot more work than designing a newer version of the existing rocket using improved higher thrust versions of the existing engines. Plus the new 3 core version will have new potential failure modes, and increased risk of failure on every launch.

Assuming the GOG version is the same as the steam version you can just copy the entire folder to another directory, and get a duplicate installation that way. (Start menu/desktop shortcuts will still point to the original directory, and the new version won't have registry entries, which may make it harder to apply updates, but you can just update update the original, create a new copy of that, then move the mods + savegame into the new copy).

Are you guys using the Steam version, or the ksp store version? Where is ksp installed? Under Program Files, or somewhere else? And are you running the launcher or one of the ksp executables? (I'm using the Steam version, installed under d:/games, and launching ksp_64.exe, and it never asks me for elevated permissions. But the launcher might need elevated permissions to update ksp, especially if it is installed under Program Files).

Well when they were used (on the space shuttle ISS missions), the astronauts who used them were untethered. The SAFER backpacks currently in use on the ISS, are considered emergency use only, and are only intended to be used if an astronaut somehow became untethered and started drifting away from the ISS.

It also happens to me, and I saw it in stock in 1.3. (It also happens in my modded 1.4.3 career, but I haven't played enough stock 1.4.x to know whether it still happens in stock).

@MR_STYLZ I haven't played with RO/RP-0 for a few months, (and it's been over a year since I played with the 1.2.2 version) but from memory many of the early engines need a highly pressurised fuel tank, and you might need to change the tank type. If you right click on the engine it should tell you whether that is the issue. (I forget whether you can do that in the VAB in 1.2.2, or only once it is on the launch pad). For RP-0 tutorials I recommend Nathan Kell's 1.2.2 RP-0 tutorial series.

I'm pretty sure you can change that in the configuration screen. I play with exceeding the habitation limit turns kerbals into tourists, and it is very common for the kerbin re-entry capsule to be the root part of my designs. With USI LS that means that as soon as I decouple it from the rest of the return craft, suddenly all my kerbals have exceeded the habitation limit of that capsule, and turn into tourists. So I always make sure that the return capsule has a probe core attached, so that I still have control for atmospheric entry.

Pure speculation, but is this a craft with a high thrust to weight ratio at launch, and some long burning SRBs? If so then I'd guess that the gravity turn's default guess isn't pitching over aggressively enough, and by the time the SRBs burn out, the craft is already heading out of the atmosphere without having pitched over enough. If so lower your launch thrust to weight ratio. (I like around 1.3-1.4. Often gravity turn only needs around 20 m/s to circularise my rockets).