NathanKell

Ah, if you just want every planet and moon to have, say, 28 degrees of axial tilt, that's easy. Start with a clean RealSolarSystem.cfg file, and add a node for each body. In each body's node, add an Orbit node, and inside that set inclination to (28 + whatever it was originally). However, you will also have to match LANs such that they're in the same plane, or things will get funky. The delta V map will then be wrong because Kerbin equatorial orbit (what you launch into from KSC) will no longer be in the plane of the ecliptic, so you'll have to launch into that latter plane (at higher cost) in order to do transfers at stated cost. Also the transfers to moons might be off.

Kitspace: Advanced Jet Engines has some jets, which reuse the B9 Aerospace jet model. As for airplane parts, most of ChrisPBacon's work is per-craft, not "plane part packs"--other than B9, and Taverio's Plane Parts, and Firespitter...oh, and there's RetroFuture too, IIRC. That's about it for plane part packs. GigaG: Fixed in Git. FASA updated, we updated RO to track, but we haven't released the new RO yet, sorry.

As it turns out, in real life at least solid rockets are not so very much cheaper than their liquid compatriots, especially since the massive costs of a liquid engine are in its development more than in production, and in real life fuel tanks are dirt cheap once you've set up the tooling. Creating and shaping solid fuel? Not so cheap. A solid stage would probably be about at most 50-70% savings over a liquid stage, and that's not getting into the decrease in efficiency (which is much starker in real life: In KSP, solids have real life stats, but liquid engines and liquid tanks are far heavier than real life--like up to 8x heavier!).

To this: Because the texture itself will not exist.* You can compile the MapSO to texture2D, then export that, though. *I dearly hope it won't. That would be the utmost of stupidity / profligacy, to keep two uncompressed copies of the heightmap lying around...

You mean you want thrust to increase or decreased based on atmospheric pressure? That will take a mod. Or do you mean you want thrust to change with velocity? That one, KSP already has, as Chris points out.

I have to agree with Renegade here (sorry Red): IMO, based on what Squad has said, FAR is closer to what 1.0's aero will be like than 0.90soup is. In my estimation, it will probably be a mix of FAR, NEAR, and stock; I find it vanishingly unlikely that aspect ratio or sweep will make it in (although that would be awesome) so the lift you get for swept wings "spaceplane" wings will be higher than NEAR or FAR gives you, but you *will* get Mach Effects (those have been confirmed)--and reentry heat is a Mach Effect. Anyway, on the to meat of the topic. capi3101, you are in luck, because as Keptin's post says, Keptin wrote that post for FAR as well, and about half the stuff talked about in that post only applies to FAR, not stock: streamlining, aspect ratio, sweep, dihedral/anhedral, etc. Basically, you have to read that post with new eyes, and no longer discard all the information that's not relevant to stock KSP, no longer have to say to yourself "yeah, I know that's how it works in real life, but this is KSP"--with FAR, aerodynamics will behave much more like real life, and all those special factors Keptin talks about and then dismisses are modeled in FAR. In FAR, drag and mass are 100% uncoupled: as long as you are producing more thrust than you are experiencing drag, you will accelerate. TWR does not matter for top speed at all. The only way mass matters is that the heavier you are the more lift you need, and thus the higher angle of attack (angle above the velocity vector) you will have to fly at to generate that lift (and the higher your AoA the more lift you get, but also more drag). However, that's only relevant for the same aircraft empty or full, not between different aircraft; a heavier aircraft with the same engine may well be much faster if it suffers less drag. For that reason, and because wing shape as well as amount matters, there are no general rules regarding how much engine or how much wing to add-especially because you might need less wing area if it's long and narrow and unswept (high AR, low sweep = lotsa lift but low top speed) whereas a delta-winged spaceplane might need more wing area and get less lift out of it!

Thread moved--support is for problems you're having with the game, not things you want to do. You can use KittopiaTech, available in the Addon Dev forum--that's probably your best/easiest bet. RSS will also do it, but it's not as user-friendly.

Freethinker: to make a pull request, you fork the repository, make the changes you want, and then click the "pull requests" and "make new pull request" button and follow the prompts. If all you're changing is a single file, it's even easier: find the file you want to change in the repository, click edit, give it a name, and click commit; GitHub will automatically start the process of making a pull request, asking you a few more questions. However, as Northstar has pointed out, clearly the development schedules are not coinciding. I would suggest you release the config as an addon that itself depends on RealFuels; then you won't be tied to my release schedule at all. To that end I'll remove any bits of RF that still interact with KSPI.

Oh, Rothank, sorry, missed your other question. It's just made with procedural parts and procedural fairings, though I do use ferram's Saturn-Nova textures for proc parts and proc fairings. I borrowed my technique from him as well, making big drum-shaped proc tanks for the main part of the stage, then smooth conic domes above and below to represent the "inner tank". That got a whole lot easier with .90 and the offset tool (that career was in .25).

What norm is that? Dry mass scales pretty linearly with volume, for pressure vessels.

GigaG, the list of mods RP-0 currently supports (or has WIP support for) is in the OP. baldamundo: Welcome to the forums! RO (and RP-0 as adjunct) change a ton of stuff. I suggest you check out the Realism Overhaul Wiki, in particular the False KSP Lessons page and the "Your first rocket" tutorial. That should give you a better overview. As for RP-0, career is rather different. You have to fly sounding rockets, you can't collect science from Earth's surface / water / KSC, engines are very expensive (but tanks are cheap), and the tech tree has had some reorganization and re-costing. Also we highly recommend Kerbal Construction Time, and if you invest all your early points in VAB build rate, it will take you the quite-historical six years (1951-1957) to go from sounding rockets to orbital rockets (don't worry, you can timewarp). Rothank: They certainly are going to be supported! The old "fuel systems" node is going to be renamed "Staged Combustion" and that's where the NK-15 (predecessor to the NK-33) will go, for example. However, Raidernick's Soviet Probes and Rockets mod is in the process of being supported, so you will shortly have a "Soviet" path available. It involves flying sounding rockets until you get enough science for the second rocket node, then buying the R-7. Acemcbean: Thanks for the kind words!

xrayfishx, I imagine the pretilt settings would work. Tweak the epoch as desired (RSS now starts in 1951, not 1950, e.g.) Errol: nope, not quite. As cantab and Starwaster point out, KSP does not support axial tilt directly. Intead, axial tilt is precisely equal to inclination. In order to give Earth axial tilt, we inclined Earth's orbit 28 degrees. If you want only Kerbin to have axial tilt, then it will be (tilt degrees) out of plane with every other planet (unless you incline them all too, in which case they get axial tilt too). Further, if you want the Mun to be inclined relative to Kerbin's equator, it will have (inclination) degrees of axial tilt itself. That means that the delta V map will be totally wrong, since Kerbin will no longer be anywhere near in the same plane as the other planets. Sparker: That's KSP itself fading in a normal map. Nothing RSS changes. BTW, note: anyone shipping an RSS dll with your config (thyriel, say) please make sure you have the latest dll. Probus just spent a rather impressive amount of time today tracking down a bug, only to find that the RSS dll wasn't up to date.

Uh...nosecones don't shield things in FAR. isShielded states whether an object is inside a fairing or shroud, not "behind a nosecone."

Known issue with ATM in 32bit OS. Check the ATM thread for help.

1. The only exceptions to the "is it in GameData" rule are: (a) if it's under a PluginData folder, the GameDatabase loader ignores it. That means the plugin has to load it manually, and you can't use MM to change it. (TACLS is an example) ( even if a cfg is in GameData and not under a PluginData folder, a plugin may directly load the CFG, rather than load it through GameDatabase. Thus while you can change the values with MM it doesn't matter, because the plugin loads the file fresh from the drive every time it wants it. Fine Print (for 0.25) was an example of this; Arsonide kindly corrected this for .90. As to has/wildcard, there's a bug in .10 that Sarbian fixed for the next version that prevents it working. Eventually you will be able to do NODE[name],IDX:HAS[foo] But only in that order with the ,* or ,idx before the :HAS.

First you have to tell us what you mean by "thrust curve". :]

To get the heightmap, you need to read out the data from the MapSO that's a member of the PQSMod_VertexHeightMap object. That's just an uncompressed array of the heightmap image.

Tankbuster32, very nice!

Fuel tanks are pressure vessels so the cube-square law does not apply. I would expect the NASA parts to have their dry mass decreased and the Mk3s' increased.

I'm really rather confused by the hostility. As I said here I've been very busy recently, and I do apologize for the delay. Sounds like the best solution, if you're actively developing the interop, is to remove RF's outdated patching itself and then you're not in the least beholden to me for updates (not that you are anyway, this has an open license).

Dunno about best, but minimum (unless it's <130km) and maximum ranges certainly shouldn't change; the ability of the instrument to see a given area of land won't change just because the planet got bigger.

Yeah, the way Unity GC appears to work, *most* of the leaks get unleaked on scene change. That doesn't help if you leak enough to go over limit, but if you (say) regularly remember to exit and reenter the VAB it'll help.

Also science. All science text is keyed to body name.

Unless you have installed a planet pack, or use Texture Replacer, ATM will not touch planets. It only deals with textures in GameData, not KSP_Data.

On the Rapier--at high mach, it's getting air rammed into it for free. In closed cycle, it has to pump the air (as LOX) in. That's why.