NathanKell

Photoshop does weird stuff with alpha. Look at the channels individually to see what the texture actually looks like.

It does. The addon rules prohibit sharing/reusing stuff from KSP_Data (vs. GameData).

As for why we didn't leave the LEM in orbit around the moon....we did. Thing is, though, the moon is very harsh on orbits (look up 'masscons'), and it gained a negative periselene quite quickly. To stay in low lunar orbit you need quite an insane quantity of stationkeeping delta V.

Carraux: good catch. For some reason TEATEB was added to the Community Resource Pack with flow. It should not flow. Fixed in dev, and when RoverDude gets around to releasing a new CRP it will be fixed in fact. Meanwhile I'll add an MM patch to RF to fix it there (same as the hsp patches). Ratzap: The settings are the same as they were in Engine Ignitor. They almost certainly need tuning. That said, upper stages include ullage motors for a reason, even if there's only a few seconds delay between staging away the first staging and lighting the second. It probably should be at least a few seconds of stable, though... Also: holy crap that myth just won't die. I think it's the third time this week I've encountered it. Yes, hypergolic pressure-fed stages are still subject to ullage. First, let's consider hypergolic. Why would "the propellants don't need an ignitor" have anything to do with whether or not the pressurant diffuses in the propellant in the tanks? Second, pressure-fed (note: not "pressurized", all tanks are pressurized. Pump-fed engines' tanks to about 2atm, pressure-fed engines' tanks much higher. That's why RF doesn't say "pressurized", it says "Highly pressurized"). Why would the fact that there's more pressurant in a tank change anything about how that pressurant diffuses? Protip: it doesn't. Same ullage issues. The only kinds of engine-tank combos that are not subject to ullage are: Membrane tanks: where there's actually a diaphragm between the propellant and the pressurant. It's heavy, inefficient, costly, and pretty much not used for anything except RCS. Surface tension tanks: where there's a grid near the feed line and the propellant sticks to it because of surface tension. Solids: because they're solid. Redhotita1: That's the stock part, yes?

Data: Oh crap. I was going to fix that and forgot. It's tunable in 1.0x. For people with issues, I need logs.

You need to edit a bunch of Physics.cfg factors if you're playing with a rescale. I suggest using this: https://raw.githubusercontent.com/KSP-RO/RealismOverhaul/master/GameData/RealismOverhaul/RO_Physics.cfg It's for RO (i.e. RSS or 10x) but should work fine for 6.4x too, just make things a bit less hot.

if you specify an origMass in the MODULE, you can then use massMult in each CONFIG and the mass for that CONFIG will be origMass * massMult. A lot of RO engines do that.

Awesome!

That will make interplanetary returns impossible, no?

Remove Hotrockets. RO requires RealPlume.

RP-0 provides career for RSS/RO. It's not ready yet, but now that RO is that's what we're focusing on. There's a workaround for the hang issue. https://github.com/BryceSchroeder/Kopernicus/issues/48

He is. They're more recent than from the locked threads. He's just not on the forums anymore, so Probus is running the OP.

Excellent thinking!

Playing 10x Kerbol (6,000km radius, Earth atmosphere) with miniRO (RO size and efficiencies but just as MM patches to stock parts, no new fuels or engines or whatever). This is a 1/20th-by-mass scale Von Braun Ferry Rocket. The lower two stages are fully recoverable by parachute (4m/s) and even a bit of engine thrust, and have heat shields for the 2.5km/sec and 4km/sec reentries. Final stage, the shuttle, carries two kerbals plus the pilot or (with a 1m cargo bay mod) 0.5t of cargo. It can survive reentry from LKO (7.3km/sec) by having a very low ballistic coefficient (high drag vs. mass) and flying a skip trajectory between 85 and 65km (at 20-40 degrees alpha) until it finally slows below 5km/sec. Takes about 1/3 the planet's circumference to reenter. Initial vac Delta V is ~9800 (of which 200m/s is earmarked for orbital ops).

MajorStorm: If you want to modify the heightmap (what's used in PQS) then yes, you can access it during code. Get the PQSMod_VertexHeightMap PQSMod on the Kerbin PQS and modify the MapSO on it. Since the scaled space textures are loaded as read-only you can't modify them, you can only replace them.

Some mod of yours that uses KSPAPIExtensions is not up to date. In fact, you should be getting a warning on KSP startup about incompatibility...

http://forum.kerbalspaceprogram.com/threads/125397-Historical-Rockets-Probes-and-Stations?p=2062176#post2062176

I think you're confusing whether a part shields what's inside of it, with whether it has a correct drag model for itself and whether it properly occludes when on the stack. The mk3 bays did not have an override until 1.0.3 so that was an issue, and any mod parts that don't have overrides will be wonky, but that doesn't have anything to do with whether or not they shield other parts that are inside them. If fairings use the stock module, or Procedural Fairings's module, then they will work. Otherwise--say, they're old-style NP2 or KW fairings, i.e. multipart without a shielding module) then they will just double your drag. Service bays that use ModuleCargoBay will shield what's inside them. Cargo/service bays that don't have ModuleCargoBay will not. Certainly the stock bays do shield.

Moved to Addon Development, where this is more appropriate. They're inside the Unity assets, and therefore not directly editable. You can, however, replace them by using Kopernicus.

Made a repo for it, offered a compiled version with some examples. Please someone adopt this! I have too many mods...

Install KAC and it'll give you the day/month/year (year 1 is 1951).

Please follow the directions here so we can figure out exactly what's breaking: http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29

Bayerische Flugzeugwerke J.4 Falke (Mar 1937): The Falke (Falcon) can trace its lineage through a long line of Otto hunters dating back to the First World War. When the Otto company was bought out and reorganized as Bayerische Flugzeugwerke, it continued unbroken the tradition of supplying hunters to the Luftstreitkräfte. The requirement, released in late 1933, was for a general-purpose hunter with considerable range: with continuing Anglo-German advances in radar (and the possibility of the Russians using it too), it was becoming clear that the old saw that “the bomber will always get through†might no longer hold, and the Luftstreitkräfte had nothing with the range to escort its bombers into the now deeply-hostile Russia. The Falke was notable for being a “clean sheet†design, not derived from any prior Otto work, although influence was clear. It was designed around a two-stage supercharged inverted-V engine, whose radiator would employ the Meredith effect; the wings used laminar flow airfoils. Besides reducing drag, this would also increase range: considerable fuel could be stored in the thick wings. To take advantage of the powerful engine and low-drag wing, the Falke was also machined to a very high standard, with flush riveting, carefully-applied dope, and the like. In practice the Falke (and the similar Rapier) proved the most aerodynamically-clean piston-engine hunters of the Second World War, with the range of a twin and speed to rival (and beat) the early jets. The first service model (Bruno) reached operational capability in early 1937, and was soon being delivered to the escadrilles of the Spartakus Legion in France; during the Intervention the Bruno and the bubbletop, up-engined Dora models served side-by-side escorting bombers and flying medium cover. By the start of the Second World War the Gustav was just entering service; the final production variant, it featured a considerably lightened structure and a more powerful Daimler-Benz engine, topping out at 480mph. Falke D3 (1938): 7176lb dry, 9061lb loaded, 1720HP, 441mph, 3x 20mm cannon, 2x 13mm MG. Falke D3 "Marlene" of Oblt. Josef Kautsy, in standard Luftstreitkräfte white, near Königsberg, 1938.

None of the drag numbers in the cfg mean anything, unless there's an explicit DRAG_CUBE defined as cargo bays have.* Drag is now based on part shape and size. Look in PartDatabase.cfg for the drag numbers. The first six triplets are for X+, X-, Y+ (forwards for a stack part), Y-, Z+, Z-. In each triplet, the first number is the area, the second is the drag coefficient, the third is depth at the widest point. *Also if there's a ModuleDragMultiplier, as parachutes have, then drag is multiplied by that number when the part is in that state. I suggest you look in this thread for more information on the drag model in KSP 1.x. http://forum.kerbalspaceprogram.com/threads/119108-Overhauls-for-1-0

To save with an alpha channel: File->Save As Choose DDS, check the 'alpha channel' checkbox in the save dialog ('as a copy' will become unchecked, probably) In the DDS options window, choose DXT5. Leave Generate Mipmaps and Flip vertical on. Save. For a normal map, start with a normal purplish-blue normal map, do file->Save As, leave alpha unchecked, in the DDS dialog choose DXT5nm.