OHara

Nice. (The EP-12 isn't from Squad's Making History but from the Missing History part-pack mentioned up-thread.) So, you're telling me, that if I use M.H., for a mere 45 funds I get a part weighing just 10kg with 2600 K max. temperature to protect the science equipment on ascent, and decouple it when I'm done. Whereas without M.H., I would need to spend 300 funds on a decoupler and 240 funds on the cheapest heat-tolerant part I can find, for a total of 540 funds and 40 kg. I'm sold.

I counter-offered with my own 2 cents: take the decoupler out of the Engine Plate and let people add their own beneath it. I've been building various rockets with this @PART[EnginePlate*] { -MODULE[ModuleDecouple] {} // remove the decoupler functionality %category = Engine} and like everything much better. The Engine Plate mounts engines as the name implies, fits its current cost and mass, and takes decouplers beneath in the same way as engines do. That makes Staging and Engineer's report and delta-V work normally again. Relative to the old way of clustering, we save several Structural Cubes and the Fairing, so I don't mind an explicit Decoupler. The thing that took some thought was a Saturn-V-style interstage fairing that ejects a few minutes after stage-separation. I used the Engine Plate for the cluster, disabled the shroud, attached an inverted decoupler to its bottom node and offset the decoupler to to be flush with the plate. Then a tube, then a decoupler, then the lower stage. There is already an in-game option for this on the Engine Plate's right-click menu: "Decoupler: Disable Staging"

I like the Engine Plates, too. You know, you haven't been missing anything. If you use the Engine Plate to cluster engines and give them a common shroud, and put a decoupler on its bottom node as you would for a single engine, it seems you get all the benefits that people have mentioned here, and avoid all the troubles.

You don't get much drag from the engines inside an Engine Plate; it is difficult to notice. The extra drag that is wrongly included in KSPs simplified model is the trailing-end drag from the engine bell. The Making History parts do not fit well into the framework of KSP. There are enough frustrations with the new parts, that I would not recommend a new player use the M.H. parts. Since the parts with these problems come from Squad, also the developer of the core game, I fear they make the framework of the core game look bad. Thinking of it as a parts-mod, though, where players would realize the mod-author hasn't though of integration into every aspect of the game, M.H. parts are fine.

Based on bug-tracker 19026, s/blatantly/accidentally/ Generally, I don't think we (the players interacting in a community) should be using Making History parts for anything other than recreations or playing missions.

You might be the only one wanting it from the VAB, but directly above your post is a wish to have the debug-menu method much less tedious, by extending set-orbit to allow orbits that intersect the ground, and a set-landed option. (A set-orbit without the altitude restriction, plus hack-gravity, would be almost enough.) I once used the Making History Missions system to place craft for testing, but found it much too tedious. Using the debug menu to place craft on other bodies would keep the things you do for simulation and testing clearly separate from what you do in the 'real missions'.

Now I see how you were left with a shroud. You could just use the engine plate as intended, above a single engine, and it still decouples any thing below along with the shroud. Carrying the extra 0.013 tonnes shouldn't bother you much. Having the VAB Engineer's Report and (sometimes) the delta-V telling you wrong things might bother you more. But I don't think you want to win an economy challenge by using M.H. parts.

[ I have used the plates with no shrouds remaining. You need not connect anything to the rear node of the engines, so the engines never get shrouds. The outer shroud at the diameter of the plate decouples when you stage the plate.] (Arrows on that plate indicating 'this side separates' like those on the decouplers, would help people understand them.) I can imagine that the original goal of the engine plate was to mount several engines under a single shroud, let a decoupler mount to the bottom node of the plate and make a detaching shroud like the one on an engine, but that shroud having the diameter of the plate. Then, the question came up "will these always be used with a decoupler beneath? Yes? Then let's integrate the decoupler" I understand you to mean 'better' in the sense of maybe OP. Through version 1.4.x, the plates all cost the same 300 funds and weighed 0.075 tonnes. (The wiki still has the old values.) That was reported as a bug and fixed in 1.5; now the costs differ, but are so low they are essentially all the same at zero. I think we should treat Making History as a temporary-use mode of KSP for historical recreations and trying the few good Missions that players have made. Long-term use of M.H. complicates the VAB and career mode and challenges.

That is not true. I just tried it. Below the speed of sound the cap + Hammer-SRB has twice the drag of the Thud, as one would expect from the similar forward shapes and the SRB having twice the cross-sectional area. Above the speed of sound, the Thud has a little, 20%, more drag than the cap+SRB. (This might be an effect of the attempt in version 1.2 to make pointy things have less supersonic drag; the round cap has Cd=0.32 and the Thud has Cd=0.36, and KSP exaggerates that difference.)

The folks who made the 'Acapella' for the Making History stock mission also failed to figure out the decoupler feature of the engine plates, and put a redundant decoupler below the fairing of the engine plate. They look like interstage fairings, but don't shield contents from heat or drag. They cost about 1/10 as much as the similarly sized decouplers. The equivalent combination of stock decoupler and fairing, has about 20× the cost and 20× the weight of the engine plate.

Consistently displaying units, where they are established, would help a lot. That would show players which numbers in the in-game part-descriptions can be combined with other quantities, and which are just a relative measure in some nonconvertible scale. Showing Isp with the units of seconds helps KSP players, that fraction who might know or be learning rocket science, know which version of the rocket equation to use. Reaction wheel torque is consistently in kN-m; showing the units would reveal just how strong they are. It would be simpler to measure fuel in tonnes; capacity in tonnes is already shown in-game for the fuel-tanks. The fuel tanks look big enough to hold about 4-litres per 'unit' of their labelled capacity. (Maybe the units are old-Kerbin imperial gallons, but it wouldn't matter if fuels were figured in tonnes.) Wing area looks like 4 m² per 'relative wing area', and the numbers in the aerodynamics debug menu are close to consistent with that conversion. If we used m² the advice to new space-plane builders could be simply "start with 1m²/tonne and experiment from there". Electric charge, though, cannot be converted consistently. Electric charge (which really should be called electrical stored energy) seems to be about ~1kJ/EC based on the solar-panel sizes and electronics demands, ~10 kJ/EC if you look at mass of batteries, ~100kJ/EC if you look at powered wheels, and ~1000 kJ/EC if you do the math for electric engines. Here, using a nonsense unit like EC would warn players not to convert to any other physical quantity.

I have a 1.5.1 install that is also missing ../Missions/MissionScoreInfo.cfg, presumably because I never played any missions. That install also has the warning, but I have no reason to believe I got a bad download.

There is a User-Interface bug that fits this description exactly. https://bugs.kerbalspaceprogram.com/issues/20753 If that is your problem, save your craft, exit the VAB and enter again, and then always click on the Δv button rather than hover over it.

The aerodynamic protection of cargo bays is more sophisticated (introductory post here https://forum.kerbalspaceprogram.com/index.php?/developerarticles.html/on-cargo-bays-and-part-occlusion-r156/) than what most posts in this forum assume. If a badly-written mod puts things inside the airframe that should be outside, you can let RCS thrust anyway: @PART[*]:HAS[@MODULE[ModuleRCSFX]] { @MODULE[ModuleRCSFX] { %shieldedCanThrust = True }} (The buggy mod that made me learn this was Making History, with the shroud toggle on the SM-25 service module.)

Bugs https://bugs.kerbalspaceprogram.com/issues/19376 and https://bugs.kerbalspaceprogram.com/issues/18126

I see the same effect, when using full-screen, when I switch to another program while waiting for the scene-change. I don't have any help for you, though. For me, windowed mode, less than full-screen, also reduces the GPU load.

1) The new Terrier has variants, one of which is 'bare' with no shroud. However, the 'bare' variant still takes up the space for its shroud. In applications like landers where things undock or dock near the engine, we need to allow this extra space. (Each lander at right damages the rover upon undocking.) Only the Terrier has this invisible collider; the Spark for example rolls around on the ground in ways consistent with the visible shape of the variant you choose. (The new Poodle is also missing a collider for its truss.) I posted bug 20930. I can see no Module-Manager patch or easy workaround (so I'm using Spark engines). Please comment if I'm missing an easy solution. 2) The new Terrier variants (like most of the Making History engines, the Engine Plates, and Structural Tubes) cause extra drag when they are inserted into a stack. Foxster already mentioned this for Making History engines (forum link) but now it affects stock engines Terrier and Spark. The 'shroud' version, behaves nearly as well as the old version. Or, we can just Advanced Search to get the old version. Or, copy the old Terrier's drag definition into the new Terrier (Module-Manager patch in the forum link above). In former KSP versions, there were individual 'drag cube' drag configurations for shrouded vs bare engines, telling KSP aerodynamics that the shrouds filled the space between tanks in a stack. I am suggesting Squad restore that distinction, in bug-report 20683.

Mods are not recommended with version 1.6, or at least no mods that depend on Module Manager or change PartDatabase.cfg.

@KSPJoe, the SAS function is like an autopilot. Usually you do not change trim while autopilot is in control. Players are also frustrated that normal control inputs do not interact smoothly with SAS; and there is discussion about what players want in this thread Squad has a bug-tracker (where you have to register yourself on first use) and there is an item about this there 16117

[edit: removed, wrong thread]

I've been trying your suggestion with a module manager patch to change the five relevant parts: @PART[mk2Fuselage*] { !mirrorRefAxis = delete %node_attach = 1.25,0.0,0.0, 0.0,0.0,1.0, 1 } I used a different initial orientation so that we need just one 'q' keystroke to bring the tanks in the usual orientation. We should not recommend this hack with orientations, though, as a solution. It makes the physics asymmetric by putting the surface-attach joint in the wrong place on one of the tanks. The same problem is present in the stock game with the Mk2 Crew Cabins. The orientation numbers in node_attach do something strange; they are not rotation angles like the wiki says; if I treat them as vector components then KSP usually orients the child so that its parent part is along that vector, but there are exceptions. For some cases of those orientation numbers, and in mirror symmetry, the mirror image of the part just placed is rotated 180° about its center, putting its joint to the parent part on the wrong side. This makes the craft flex in an asymmetric way, with the port cabin flexing about its inboard joint and the starboard cabin flexing strangely about its outboard joint. Experimentally, the rotation tool is drawn at the point where the physics engine seems to place the joint, so those mark the joints in the image at right. If you make a plane with wings mounted to surface-attached Mk2 crew cabins it won't fly straight. Almost all surface-attachable parts in KSP have a plane of symmetry through their attachment points. Excluding trivial asymmetry like text labels on batteries, the exceptions are Mk2 crew cabins and the fixed landing gear. The crew cabin has hatch on top, and surface-attachment point on the right. In order to place two with mirror symmetry we would need a left- and a right-handed version. mirrorRefAxis seems to be an attempt to mirror the textures of fixed landing gear and Mk2 tanks, so that they look like they have left- and right-hand versions. The problem is that mirrorRefAxis unnecessarily mirrors in-line attached parts, and mirrors parts based on their orientation in the VAB, rather than by their role in a mirrored pair. The desired solution would be to limit the effect of mirrorRefAxis to only surface-attached placed in mirror symmetry, and to only one of the two mirror-symmetry-placed parts.

The mods that existed during version 1.3.1 probably still have the matching versions of their releases available where their source code is published, most often github. Then finding the right release is a matter of looking through the release notes for the first one compiled for 1.4.0, then backing up one, or just the last version before March 2018. The *.version files inside the release remove any doubt. For questions, I would expect mod authors will not be able to remember when various fixes and improvements were made. So you will do more reading through forum threads and release notes, but be likely getting the correct answers more quickly. A lot of people delay upgrades, so your situation is not unusual. If you have a new question, where the version might matter, you should probably use past tense: "how did you, in version 1.3.1, ..."

Raptor9 already reported this one, 19079 back in version 1.4.3. At least, when I try your craft (flies very nicely, by the way) the z-fighting behaves exactly as described in the posted bug report. Same in version 1.6.1 as in 1.5.1. For me, moving down the runway is not the key to starting the shimmer, but rather moving into the 2.2-km range of another craft so that it is loaded into the physics simulation. F5/F9 removes the z-fighting until you leave and re-enter the 2.2-km zone. Maybe you have a targetting flag at far end the end of the runway? I had to move my captured-asteroid decoration from the runway out to near the monolith because of this issue.

That works for me, thanks for sharing it here, but then when we surface attach the tanks in mirror symmetry to a central stack, they start off in a funny orientation, just like the crew-cabins do. I can imagine someone saying "only the hard-core players will notice the textures on the tanks, but everyone making a 'cool-looking' SSTO will try mk2 tanks alongside a central stack and get confused". I'm not saying I agree, but I can imagine it.

No, and I would have noticed that by now. My only guess is that a mod has not gotten a needed update, or maybe the modder doesn't yet know the need. Similar things happened with HyperEdit a few versions ago. Maybe ask over on whichever Tech Support subforum fits the best.