NathanKell

Same in real life. What's causing the heating is the impact of the molecules of the atmosphere on your craft. For obvious reasons that scales by density

1. Sadly right now there's no actual turboprop support in AJE; they're treated as piston engines. 2. The mixture control is more designed for WWII-era engines (as were most of the piston engine changes I made, to account for turbochargers, superchargers, ram air, etc).

I will check this stuff when I have a sec. Mixture controls, err, the mixture. Piston engines can use varying air-fuel ratios, from lean (less fuel per given mass of air) to rich (vice versa). Mixture in AJE defaults to "auto rich" - the point at which maximal horsepower is obtained. A leaner mixture will offer increased efficiency at the cost of higher heating, and can generally only be done at altitude without risking detonation (fuel exploding prematurely); a richer mixture will provide lower efficiency (and slightly reduced power) but better cooling.

Awesome! Regarding the "view changes / rocket floats upward" issue: this is an issue that people have found on stock x64 installs, and with any collection of mods. RO itself (or RealChutes or...) does not seem particularly to blame, but the issue is exacerbated by having a (number of) mods installed, pretty much no matter which.

KerbMav: yes, honestly, the *last* thing we need is people compiling unofficial versions of mods for new KSPs versions. This thread is about reducing the support workload of modders, not increasing it. ferram4: I think that, while it's possible those things might happen, it's less likely than you fear, especially since (a) informally this help is happening already and ( it's not leading to what you fear. If anything, formalizing it will hopefully avoid the situation described above where *wrong* advice is given by third parties (I've seen this too...oy. So much bad advice becomes conventional wisdom.)

Thanks! :] Well, my fix is really just a hack around the issue, and ferram pointed out there's still a bug with SRB nozzle placement. So expect another release before too long. Also, release updated with fixed version file. It was fixed in git, but I forgot to include it in the zip. Sorry.

Then you're having trouble loading the PNG. If you're using Photoshop, get SuperPNG and set it to load the extra channel as the alpha channel, not as layer transparency. Also, you might be loading the normal map, not the diffuse map.

RedAV8R: which version of KW are you running? They just released a few updates. I've been seeing some weird stuff too.

On the Mass tab, you can choose what resources count when determining DCoM. The only incompatibility with RF is that "RCS Delta V" assumes MonoPropellant is the propellant, which is already false for stock, so you needn't be using RF to have it not work.

Sounds like maybe I need to update for the latest KW. Although the big one *should* be 8-10m in diameter. That's pretty big.

Apologies. .24 and the Kerbin Cup and a job have taken up most of my time. This isn't dead, quite. mecki: what do you mean by "the engine models of the Saturn V"? Specific parts, please.

Yes. The bug remains unfixed. Still.

andrehsu: I will fix that, then. The Engineer: by opening the cfg and changing them, or writing an MM patch. What changes do you want to make?

No, the issue is that the feature runs *without prompting*, reapplying patches. Or that is how I understood things, which is why I am still packaging 2.2.0.

Aside from technicalfool's objection, which I think is quite valid, I strongly support this idea. Example: Starwaster has been invaluable in basically doing this for me on a number of threads (most importantly Deadly Reentry) and it has made my life a *ton* easier.

I have the great pleasure to report that, as far as I know, PP is now fixed.

And yet in that general information I told you exactly what's wrong, and how to fix it: don't use rescaleFactor of value not-1.0 if you're using MODEL nodes. Instead, use scale in the node, and manually fix the attach nodes.

Correct. Now, if HotRockets shipped in a folder named HotRockets (rather than MP_Nazari along with other mods) you could do that already: MM does support NEEDS[] checking for folders in GameData. The ways MM adds a mod name to its list of installed mods is: 1. Assembly of that name (like RealFuels.dll) 2. FOR[] of that name (like RealismOverhaul) 3. Folder of that name in GameData. Note that which way a mod name gets added does have effects on patch application order, but that's not relevant to this case thankfully. You can try it out right now with NEEDS[MP_Nazari] btw

All this would require is adding :FOR[HotRockets] ( so @PART[foo]:FOR[HotRockets] ) to your MM patches. Then HotRockets will be visible to MM as a mod.

What do you mean by every single thing? Try a completely clean KSP install. Download it fresh from the store, extract it somewhere. Follow the steps in the OP to download and install RSS. Then download and install the 2048 texture pack. Then try to launch KSP. If it still fails, follow the issue report steps: 1. Describe the problem 2. Reproduction steps. 3. Cause the problem. Quit KSP (if it hasn't crashed). Upload your entire output log (NOT ksp.log) to dropbox or something. Windows: KSP_win\KSP_Data\output_log.txt OR KSP_win64\KSP_x64_DATA\output_log.txt (depending on which used) Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log ( Files>~/Library/Logs>Unity>Player.log ) Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log

I would also like to (sadly) point out that, recently, there was a thread. A thread that began by pointing to an example of a modder being driven away from GTA modding, due to abusive non-constructive criticism, and asking that we all make sure such a thing did not occur here. By the end of the thread--which had to be locked--people were seriously arguing that abusive criticism was actually a good thing and that modders should embrace it; the other very common position was that "jerks gonna be jerks" so there really isn't anything to be done. So, I think understandably, modders are quite chary about anything that would 1. Lower the bar for users, bringing in more of the instant gratification (and anger at lack thereof) crowd. 2. Add more points of failure--for which, as ferram says, we will be blamed. Consider how many threads have been about "mod x crashes my x64!" despite the fact that x64 is a buggy mess (and we were explicitly told it was a buggy mess) and that every time we have pointed out that no, it is not the mod's problem. 3. On top of all that, add more work for modders (curating metadata) or making us rely on third parties--which, however well-intentioned, may make mistakes (leading us to 2) or have a Bad Case of the RLs and need to leave the scene, either forcing us to maintain the now-defunct project or (back to 2!) have us blamed when users run out-of-date mods. And in case I haven't depressed you enough, let's add 4. 4. KSP 0.24 was the first release of KSP where the CompatabilityChecker was an active presence. CompatabilityChecker is a tool many of us include in our mods; it will throw up a warning if the mod is used on a version of KSP for which it was not designed. Let's examine how users reacted. The number 1 response: "How do I disable this?" #2: "But the mod works fine!"--but just because KSP is able to load, and nothing obvious is catastrophically broken, does not mean that the mod (a) actually works, or ( doesn't break under the surface in such a way as to break *other* mods, even though it itself works more or less ok. The worst part of this, of course, is that all the mods that *don't* implement CompatibilityChecker--still the majority, sadly--are therefore assumed to work fine. So the ones that *do* actually bother to warn of potential incompatibilities are then blamed for the problems that result. So now that I have written a quite depressing post, I want to add something constructive. You're asking "What can I actually do?" Well, here's a concrete set of steps that will actually lower our support burden. 1. If you see someone post a problem, and they don't follow the (following) rukes, tell them to: 1. Describe the problem 2. Reproduction steps (using the minimal number of mods, preferably only the mod you claim has the bug) 3. Cause the problem. Quit KSP (if it hasn't crashed). Upload your entire output log (NOT ksp.log) to dropbox or something. Windows: KSP_win\KSP_Data\output_log.txt OR KSP_win64\KSP_x64_DATA\output_log.txt (depending on which used) Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log ( Files>~/Library/Logs>Unity>Player.log ) Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log Doing that alone will probably cut by 30% the number of support-related posts modders have to make. Users almost never follow those steps; we have to spend time asking them to do so, then explaining that yes we really mean it, and no we can't offer help without it, and only then can we finally actually get to diagnosing the problem. 2. Once you get comfortable reading these logs (and seeing how modders read them to find problems), start offering support yourself. If you see that what's actually breaking in the log is, say, RCS Build Aid, rather than FAR, point that out. If you see that a mod is installed wrong (you can sometimes tell this from the log), point that out.

Mathijs: you built the latest release using the latest (1.7.0) KAE? If you don't get the same behavior, *please* post what you built. Folks, my sincere apologies. Been working away at this; so has taniwha, and I even enlisted regex's help. We're still utterly mystified, because it'd be one thing if *nothing* worked, but the cones *do* work. Voidryder: thanks! The infuriating thing, though, is that in *this* sole case...nothing weird gets put in the log. That's why it's so hard to fix.

A lot of KSP's code directly reads rotation as a linear angle (in degrees!) rather than an orientation. So no, axial tilt very, very probably is impossible short of code changes.

Lexx Thai: taniwha and I have been try to fix PP since the day this was released. I'm sorry I didn't test PP more thoroughly before release, but it *does* work fine with saved craft, which was the extent of my testing. Bomoo: I don't see how it makes it harder--with a finer step, it makes it *easier* in some ways, since you can more precisely set how much of each you want. Just set one of the values to what you want, and set the other value to the correct ratio. Presto.

And that would be because Kerbin is 1/3 the size of the Moon. Not exactly FAR's fault.