NathanKell

@Unit327 yep! :] https://github.com/NathanKell/RealSolarSystem/wiki/PQSCity-and-PQSMod_MapDecalTangent

@tomasrep welcome to the forums! Please follow the instructions here: Also, please ensure you have the latest KSP build. Open BuildID.txt in your KSP folder and make sure the build number is 1028 or above. If not, redownload KSP.

@Phineas Freak no, sorry, the original was correct and yours is wrong... %MODULE[foo] {} will lead to modifying the MODULE of name foo if it exists, or creating MODULE { name = foo } and then letting you modify it. %MODULE {} will create a MODULE node if *none* exists, or it will modify the _first_ MODULE that exists. Very bad. EDIT: Ninja'd by @Sigma88

@Lack awesome! Let me get you a picture of my current hackjob Currently we've made it from a copy of the .625m jet you've had for ages, not sure if that's the one you mean.

@Einkleinermensch the background processing mod maybe? Update KSP. You missed the patch to 1.0.5. Redownload KSP from wherever you downloaded it, and ensure that the build in BuildID.txt is 1028 or above.

PhysX integration probably can't handle forces that high with the timestep it has. Try using Time Control or something to play at 1/4 speed?

Fairly simple, just have a 0 flow multiplier at 0 mach in the velCurve and then increasing >0 at mach 0.3 or so.

Sure!

There isn't much stock UI info available to help you do that, you'd need some info mods to help. Not even sure MJ can predict it. It's not a simple equation anyway--it's the interaction of two curves (one based off static density and one based off mach) to know what flow level your engine's running at, and another curve (on the intake) based off mach to know how much air it's generating, let alone all the linear stuff (velocity and density based for intakes, and base flow * throttle based for the engine).

Looks great! Looking forward to when I have time to watch this.

This will be going on hiatus a bit due to experimentals and my playing a US game from the start again.

That's still showing you're not on Build 1028 or above. Check the BuildID.txt file in your KSP folder, and make sure the Build number in it is 1028 or above.

I need the player.log - that you posted just cuts out halfway through.

Yep! I see, for example, two RL60s in that config cache. Neither appear hidden; they are both in the correct category (Engine) and both come available at hydrolox TL7 (in career).

@Visaman you need to update KSP. Redownload it from wherever you downloaded it, it's out of date.

That's why you zip it and upload it to a hosting site.

FAR is totally sane about this stuff, it'll use whatever you throw at it. However, the drag cube system in stock KSP can accept only one PartModule that changes the part's model before it throws up its hands and says "proceduural drag cube for you!" -- which is slower and not tunable and has a few bugs we spotted in 1.1 testing. Heck, I don't even know if that model switcher even tells the drag cube system that the model is changing! Oh, and did I mention that even with FAR installed, the stock drag cube system is used for thermodynamics / thermo occlusion? FAR changes the final areas, but it doesn't mess with occlusion and taper coefficients.

This is a generic patcher. It generically patches all parts. It's not in the business of creating new parts. This is a balance tuner, not a part mod.

And you get to make a nice pretty tankbutt under that skirt! (...wait...)

Nope, it's not at all like that, sorry. 1. The vessel has its set of parts. These are all organized in a list, in the order they appear in the .craft or .sfs file. 2. Each frame, each of those parts is updated, and any modules on those parts run their updates. That's it. Now, it happens that during the intake module's update, it checks its speed and angle of attack and the density of the air it's in and computes how much air it intakes. That air is added to the part's resource counter (and if that's full, other parts' resource counters). And it happens that during the update of each module that uses air that it requests air from the vessel. That air is then consumed. If there's enough air available to match the request, the full output occurs; if there's less, less output occurs, and if the result is under the threshold it flames out / deactivates. Now, remember that engines' thrust is a function of air density and speed as well. So the higher you are, the less air they will request. And the faster you are, the more air they'll request (broadly; turbofans actually choke around Mach 1). So usually (a) the intakes and engines keep in sync, and (b) the engine will flame out saying 'air combustion failed' (i.e. air density too low to sustain combustion) long before the intakes stop supplying sufficient air. However, if you don't have enough intakes, engines will flame out from "intake air deprived", and _that_ will happen asymmetrically. Remember the list above: everyone goes in order. So if you're generating half the air your engines need, and you have two engines, the first engine will consume it all and the second engine will have none left to consume. So one engine will run fine and one will be flamed out.

@NecroBones hate to poke, but S-IC-8's design, AFAIK, saved stage height by mounting all 8 engines around the rim so the bottom dome of the lower tank could extend down in the center. i.e. 8\_/8 where the 8s are the engines.

@chrisl all that is intended. 1. Without that change, you could double your research rate (in sci/day) by researching two nodes, triple it by researching three, etc. That's nuts. You get a research rate, it shouldn't depend on how many nodes you can queue up. The research rate already allows one to be at 1980 levels of technology by 1963 (on hard mode at that) or so; I really don't think it should be sped up further. 2. No, that's correct. Milestones give much higher advances (and higher rewards) than repeatables. Compare first crewed orbital with the repeatable orbitals. 3. No, the early repeatable is much, much easier to complete--in line with early "just get there and come back" orbital missions. The generic one is much more complex and better for later missions.

@panourgue RSS _requires_ Kopernicus. Has since KSP 1.0 came out, RSS is just configs + textures for the Kopernicus plugin. Plus a tiny bit of plugin itself. The change is that those configs are no longer in one massive file.

Yes, since the shroud toggling sets a persistent field you can just apply the disabled version to the original cfg. Look for what changed in that MODULE's section of the .craft file before and after toggling to see what change to make.

Well crud. Thanks @OhioBob that's a major packaging fail on my part. Upped 10.6.2. * Fix packaging error (RSSKopernicus.cfg file was still included; it should not be.)