NathanKell

Graphics don't make a game. That said, it's very possible to make KSP shine: But, well, it *does* take quite a lot of coding and texture magic to do so.

Sure, I can do that next plane I build.

Open output_log.txt (or player.log, on Mac/Linux). Start from the bottom up, and see if anything about memory or malloc is mentioned.

If you change scale *inside* the model node, you need to multiply the scale *outside* the model node by newScale / oldScale. Leave rescaleFactor alone though. If you just change scale inside the MODEL node, your mesh will change size but your nodes will stay in their old positions.

Awesome! But please, please don't hardcode that stuff. Get it from the celestial bodies and orbital parameters. If it's hardcoded, it'll fail if anything gets modified (either in an update, or by RSS or Kopernicus or anything else).

Interstellar demands you put precoolers before SABREs/RAPIERs or they overheat and die. Try without Interstellar and see if the problem persists.

Really weird--I exported all the RSS textures in Photoshop using that plugin. I'll take a look tomorrow.

Sorry, been really busy recently with some other projects. This isn't dead, I will get to it soon...

Anecdote time! Sarbian visited New York this fall, and we took a trip to the USS Intrepid museum. It has the Approach and Landing Test shuttle Enterprise, and we walked through that pavilion. We met a group of folks talking about KSP, and we couldn't not introduce ourselves. Internet fame: apparently two of them now have their selfies with us as facebook profile pics. :]

Q: What's stopping them? A: Time. What would reduce loading time is converting *.mbm to *.dds, though, and that doesn't actually take coding time really (the DDSLoader is perhaps the simplest, shortest plugin ever written); Load-On-Demand will actually slow loading time, because the textures have to be read and then low-rez placeholders made from them (one load step) and then each time a texture is actually needed at high rez it has to be loaded again.

Um, since you're including DDSLoader, why not include the textures as DDS? As it stands, KSP will load them as PNG (and that loader has bugs), taking up memory, and *then* RSS will load them, doubling the memory. Suggestion: 1. Export as dds (I can do that for you if you want) 2. Change the lines from SSColor = GameData/64k/Textures/Kerbin_64k.png SSBump = GameData/64k/Textures/Kerbin_64k_NRM.png to SSColor = 64k/Textures/Kerbin_64k SSBump = 64k/Textures/Kerbin_64k_NRM

Whoops, forgot to update OP. Fixed. Also, anyone have any questions so far?

Hughes H-29 Thunderchief (Feb 1937): Decently impressed by the performance of the Thunderbird, the USAF contracted Hughes for a successor during the mid 1930s. The Thunderchief, as it was named, looked like a big brother to the Thunderbird, though it was greatly modified during the design and prototype phase in the light of lessons from the French Civil War. The final product was much larger than the H-25, almost three thousand pounds heavier dry (and with a much higher loaded weight), and armed and armored to survive modern combat. In addition, given the use to which the républicains put the Thunderbird, and the hyper-powered air superiority hunters then in development, the USAF instructed Hughes to focus more on ground attack, creating perhaps the first dedicated hunter-bomber in the process. The H-29 that finally emerged, reaching operational capability in early 1937, was as close as the USAF had yet come to a "flying panzer." The large radial engine--the largest and most powerful yet flown, developing 1850HP in prototypes and 2000HP in service--gave the Thunderchief the ability to dash at high speed despite its heavy weight and keep flying even with some cylinders shot out, and the cockpit, fuel tanks, and other important areas featured considerable armoring. The armament was also a first for the USAF: all cannon (even the favored .50cal machine guns having been shown to lack punch against armored enemies in the air and on the ground in France). The final product could hold its own in the air, though lacking in speed and not as nimble as competitors such as the Hawk (or forthcoming Rapier), and what it could not outrun, outturn, or avoid it could certainly outlast. The Thunderchief acquitted itself well during the Intervention, and even in the more dangerous environment of the Second World War the Thunderchief proved up to the challenge, regularly bringing its pilots safely home when other aircraft would have faltered. H-29B (late 1937): 8972lb dry, 12125lb loaded, 2200HP, 434mph, 4x 20mm cannon. H-29B of 32nd Hunter Group, Sinclair AFB, California, November 1937.

FASA changes frequently; RO isn't yet up to date with the latest changes in release (though I believe all is fixed in git). chrisl: I launched an Atlas-Agena (using SLV-3 Atlas) and found that, yes, you do need to loft rather high early on to avoid steering losses later, so maybe hit 1200m/s when 45 degrees. My guess on GEO payload (with a third stage for GTO->GEO kick) is about 150kg.

http://forum.kerbalspaceprogram.com/threads/49598-o-21-x-Space-Shuttle-Solid-Rocket-Booster-1-1-Replica

Yeah, I really oughtn't be one to cast stones about missing words, done it too much myself. Sorry. Alas that would screw the tangents. I *think* you can just multiply all the tangents by 70/130 and it should come out ok, but don't quote me.

Downside is it's not pruning-aware. MM has no way of knowing if a given engine is installed, only if the Part Pack is. So if you install FASA but delete the Apollo folder, the MM patch will still try to use those (deleted) models for the RL10, and no engine will appear ingame.

Normally, fuel tanks can contain, say, 440 units of Oxidizer and 360 units of fuel. With this, they can contain 800 units; you tell the game how to divide that between Ox, LF, MonoProp, Xenon, etc.

1. MM can't patch cfg files in PluginData since they're never loaded by the game. 2. Even if it's not in PluginData, it being in that form implies that Kethane loads it directly from disk, rather than checking GameDatabase, so MM patches wouldn't make a difference (same problem with FinePrint, before .90)

Cryzrndm: please read *all* the post before responding. :] livefree75: The table will be in the RealSolarSystem.cfg file--find the Kerbin {} node, and inside it find the pressureCurve. However, some pretty complex mathing by eggrobin was used to make that curve, to match the real atmosphere's behavior.

1. rescaleFactor is still bugged: if a part.cfg has a MODEL node and a rescaleFactor that isn't 1.0, it will grow or shrink under certain circumstances. 2. Tweakscale has some similar issues.

Modeling the craft as a single body leads to much better aerodynamics, but you need a way of getting (and then simplifying) the mesh of the whole craft as a convex hull--and then you need to be able to do it so fast there isn't a "lurch" when you decouple a stage.

Well, just in case, make sure the PQSCity and MapDecalTangent settings for KSC in LaunchSites.cfg are exactly the same as those PQSCity and MapDecalTangent settings in RealSolarSystem.cfg.

That is somewhat dangerous, because it means craft files can't be shared. BasharMilesTeg, however, had IMO a far more brilliant idea: don't use *any* existing engine parts--hide them all, and create all our own. So you'd have the part RO-F1-Engine, which takes the FASA model if available, else has a fallback. Then craft are perfectly shareable, and the part list doesn't have duplicate engines. In essence we decouple the model from the final part, so no matter what part packs you have, you have the same RO-supported parts, they just might look different.

Van Disaster: yeah, 5.5 m^2 vs 7.4 m^2 frontal area. Huh.