undercoveryankee

I scaled them to 4x4 (exactly one DXT block) and got two clean loads. You could probably add an ATM config that sets compress=false for those particular images, but it's probably easier just to make the size a multiple of 4.

NuFAR players may find that the boost protective cover has better area rule performance than a bare capsule. That sharp transition from cone to cylinder is expensive.

Any config pack that depended on the old RSS plugin will need to be ported to Kopernicus (and KSCSwitcher if it was using that feature of RSS). There's been some work done on Kopernicus-powered 6.4x configs, but nothing has made it to full release yet.

If it's 2x2 placeholder PNGs that are causing ATM to choke, that makes sense. ATM is configured to convert any non-DDS textures it encounters to DDS in the cache. The DXT encoding schemes are based on 16-pixel blocks, so you would get an error if you try to convert an image that's too small to end on a block boundary. My guess as to what's happening: When ATM encounters an image that isn't in the cache that fails to convert to DDS, it fails in a way that leaves the original uncompressed texture loaded (so the game starts the first time), but writes garbage entries to the cache. Then on the next startup when it's loading from cache, it encounters those garbage entries, fails to load them, and isn't set up to go back and try to load the original file. It worked on older KSP versions either because the older versions of ATM were managing to load something sensible or because the older versions of Squad's part compiler didn't hang the entire startup sequence if a texture that gets overridden with something else anyway was missing.

Squad decides which version to put on "previous" each time they update. I haven't looked because I had a local copy of 0.90, but from the trouble that people are going to to get copies of the 1.0.0 aero tunings, I think Steam "previous" is still 0.90.

From the OP:

The theory (higher drag early in the descent can lead to lower peak heating) worked in principle for SpaceShipOne with the feathering wings. Remember that Earth's orbital speed is about five times faster than Kerbin's. From a suborbital trajectory with similar speed to a Kerbin re-entry, there might be a window of conditions where it would be possible to use an early drogue. It's just that from Earth orbit, you wouldn't have slowed down enough to be in that window until it was too late. - - - Updated - - - Heat shields are the right shape to exploit some glitches that OldFAR had that could cause insanely low drag. (I've heard that some versions of FAR would fall for a heat shield clipped into a command pod bottom node to bottom node, and I personally found a collider issue that would cause a 6S service compartment to shield a Mk1-2 heat shield attached directly under it). That's probably what happened to most of the people who got wild rides. Found a FAR issue that they wouldn't have found without the thin flat parts that we gave them.

I had the same thing happen. HGR loaded once successfully, then every subsequent time froze somewhere on the Leek. I was in a hurry to test something that didn't involve HGR, so I just uninstalled HGR without looking at more than the last 20 lines of the log. What I saw was part of an exception trace that looked like it had something to do with texture loading. I don't have RPM installed, but I do have Active Texture Management (5-0 Aggressive). Perhaps there's one texture on the Leek or its interior that's triggering a bug in ATM's caching of compressed textures. That cache is the only thing I can think of that would have changed between the one successful load and the repeatable hang afterward.

On kcs123's plane, the big tail surfaces begin right where the fuselage starts tapering. So the area is flowing smoothly from the fuselage into the tail.

That's the stoichiometric ratio, but real engines run hydrogen-rich (something like 1 kg H2 to every 4 kg O2) because the lighter atoms are better at turning heat into Isp.

There's already a definition for LqdAmmonia in the CRP. It's just a matter of someone having time to write the patches. If you add Vall, Laythe, and Eeloo as ammonia harvesting locations, ammonia would be a natural choice for outer solar system exploration. According to KSPI, ammonia delivers about 5/8 of the Isp of hydrogen at the same temperature, which brings engines in the 800-second NERVA bracket down to about 500 seconds. With the weight of a reactor, that doesn't leave much advantage over hydrolox unless you're modeling boil-off.

Accept anything you think you'll be able to build a rocket for. Most contracts give you a few months or a year to complete them after you accept them. You won't have room to accept everything that's generated that you like during the early stages of limited Mission Control capacity, but my advice is to try not to stress over that. There will always eventually be more good contracts where those came from.

Isp is momentum transferred per mass of propellant, so the numbers don't change with the density of the propellant. Change the propellant name, and the rest is automatic. I can post the MM config that I use when I get home from work.

For me it was USI Life Support.

If your resource represents a real-life material, research real-life containers for that material. If you know the mass of a stage that contains your resource and other resources that have already been statted, you can adjust the numbers for your resource so the final mass of that stage is in the ballpark. If the resource you're adding is fictional or you can't find suitable published information, you can at least assign a plausible figure by looking at existing resources that are stored at similar temperatures and pressures and have similar densities. Within a general temperature/pressure/density range, more dangerous materials will tend to have heavier tanks (because the tanks get built to a higher safety margin and because some of them limit the selection of tank and pipe materials they can come in contact with).

Ferram was never able to find a model for ground effect that delivered acceptable performance and accuracy in classic FAR. The voxel model might open up some new lines of investigation once nuFAR is solid for normal flight.

With FAR and pre-1.0 engines, I basically ignored the atmospheric number and looked for about 3500 vacuum. Stock aero in 1.0.0 was coming in a little lower; 1.0.1 makes it closer to 4000. If you watch the Isp of an engine during a launch, you'll see that it gets pretty close to the vacuum end of the curve during what still feels like the early parts of the launch. So the vacuum figure is still more representative than the sea level figure. With practice, you'll be able to settle on a rule-of-thumb vacuum delta-v that works in each aerodynamic tuning (1.0.0, FAR, 1.0.1+) as long as you choose engines with relatively flat Isp curves for your liftoff stages. (For instance, the LV-T30 Reliant has better sea-level performance than the T45 Swivel, even though the Swivel passes the Reliant in vacuum Isp). If for some reason you have to light a dedicated vacuum engine like a Rhino or Terrier at sea level, you'll probably be using SRBs alongside it to get a decent sea-level TWR. With practice, you'll develop a sense of how much to add to your normal rule of thumb for those oddball configurations. 500 m/s extra will probably cover most cases with a sane initial TWR.

Transfer Window Planner takes into account the eccentricity and inclination of the orbits. The functionality in KAC is based on an older calculator that used approximations that are exact only for coplanar circular orbits. The KAC dates will put you in the window for a feasible Hohmann transfer, but with no guarantees about the plane change that might come with it. Windows found by Transfer Window Planner may choose an off-Hohmann transfer to depart or arrive on an ascending or descending node if the reduced plane change cost gives a more efficient overall trajectory.

There's a discussion one one of RoverDude's threads. The CKAN maintainers have marked the current version of Firespitter (which throws a harmless compatibility warning) as not for 1.0 because the warning was generating too much support chatter. That causes everything that uses Firespitter to stop showing up.

Here's a patch that targets every engine that uses LF without Oxidizer or IntakeAir, including the 3.75m NTR from the Taurus HCV. Will probably work for Atomic Age when I get those installed. @PART[*]:HAS[@MODULE[ModuleEngine*]:HAS[@PROPELLANT[LiquidFuel],!PROPELLANT[Oxidizer],!PROPELLANT[IntakeAir]]] { @MODULE[ModuleEngine*] { @PROPELLANT[LiquidFuel] { @name = LqdHydrogen } } }

Yes to the fuel-tank patch affecting third-party tanks. It matches every installed part that contains LFO and doesn't already have an FSfuelSwitch. Advantage of these engines is 1) Isp, and 2) filling in some gaps in the stock lineup. The KS-68 Mars fits nicely between the stock Rhino and Mammoth.

I'd say most people who care about boiloff will be using RealFuels.

We write modded trees with no parts listed in the nodes so there's room for other people's ModuleManager patches to run after ours and move individual parts around. For instance, TAC Life Support moved the small solar panels one tier earlier in the old tree to compensate for the additional ElectricCharge consumption it adds. If you loaded the Interstellar tree with all of the stock parts assigned to their stock nodes, you would override the change that TAC was trying to make. I admit that if you're trying to assign every stock part to a node by name, a ModuleManager patch is a little more verbose than listing part names in a tree config. But ModuleManager gives you enough ways to address a group of parts together that you'll probably still come out ahead. Want to assign all of the contents of a stock node to one of your modded nodes? Do it in one patch of "@PART[*]:HAS[#techRequired[experimentalRocketry]]"! Let's see a GUI find a way to address "all engines that burn LiquidFuel but not Oxidizer or IntakeAir" in one list.

If you want to make sure that the CRP definition wins if it ever changes, ModuleManager can do that. Write your fallback definition as "RESOURCE:FOR[MyMod]:NEEDS[!CommunityResourcePack]".

This should rewrite any node_stack_bottom that has a 1 in that fifth position. I even made the regex a little more flexible in handling likely alternative ways to write the same coordinates. I can't guarantee that it won't match and rewrite other things as well, but consider it a starting point for testing. @PART[*] { @node_stack_bottom ^= (.*,){4} ?1(.0+) *, *(.*):$1 -1.0, $4: }