BudgetHedgehog

It's not so much a mod supporting stock aero, it's more about stock aero supporting a mod - now the drag and lift model isn't stupid and works (almost) like it should, it'll now affect B9 parts in the way they should be affected. You'll still want FAR for a more realistic experience, but stock aero should support it just fine.

Done! Hope it helps

Gimme gimme gimme

I could be wrong, but I thought KSP used the orientation of the attached part to figure out its position relative to the CoM, as well as its absolute position. See below - the inner surfaces are attached behind the CoM and the attachment surface is aligned behind the CoM. The outer surfaces are also attached behind the CoM, but their alignment draws a straight line in front of the CoM, confusing KSP. You probably see all flaps deflecting wrong because all are attached at the same angle. Also, as I mentioned beforehand, those control surfaces should NOT be used for pitch like, at all. Only flaps/spoilers and possibly roll. Pitch should only be controlled with the elevators on the tail (in this case).

So then we have the question of how to send a craft to Moho and back while ensuring the heatshield doesn't evaporate before we return?

That shouldn't be a problem with MM >2.3.1 (way back in KSP 0.24). Unless something's broke since then?

What you (presumably) meant to write: @PART[*]:HAS[#CrewCapacity[>0],!INTERNAL[[COLOR="#FF0000"]*[/COLOR]]]:Final { INTERNAL { name = Placeholder } [COLOR="#FF0000"]}[/COLOR] What was in the cfg: @PART[*]:HAS[#CrewCapacity[>0],!INTERNAL[]]:FINAL { INTERNAL { name = Placeholder }

You're missing a }.

Cheers for doing this, been a real headache at work recently. All looks like good stuff, excited to see the new shaders and steering modules.

I don't know the answer to the first question, but < and > operators have been around since MM 2.5.13.

In case you needed actual pictures: 737 in front, 777 behind.

Why not try @PART[*]:HAS[#CrewCapacity[>0],!INTERNAL[*]]:Final { INTERNAL { name = Placeholder } } This translates to "for any part that has a crew capacity of over 0 and no currently existing INTERNAL, add the Placeholder INTERNAL". Just an aside, but what were you aiming to achieve with this? @PART[*]:HAS[@INTERNAL[Placeholder],@INTERNAL[*]]:FINAL { !INTERNAL:HAS[#name[Placeholder]] {} } "for any parts that have Placeholder INTERNAL, or any INTERNAL, remove the INTERNAL named Placeholder"? Because that's what I think it says... Just.. yeah, if you want to add Placeholder IVA to parts that don't have it but need it, check if the part has any crew capacity and no currently existing internal then add it.. EDIT: I could be wrong, but as of KSP 1.0.4, no parts have the Placeholder INTERNAL so checking for this is unnecessary. (EDIT 2, a quick Notepad ++ search for 'Placeholder' in the Squad folder confirms this - no parts have this INTERNAL). EDIT 3, if KIS needs an INTERNAL to work correctly, why would you want to remove Placeholder INTERNAL anyway? That's guaranteed to break KIS which is almost entirely the opposite outcome desired.

Those shouldn't be used for pitching anyway - it's been a while since I played stock, but doesn't that allow disabling for the different vectors (pitch, yaw, and roll)? Because you should disabling pitch for all but the elevators, disabling roll for all but the ailerons, and disabling yaw for all but the rudders. But, I've never had a problem with inverted surfaces anyway - if they're behind the CoM and you pitch up, they deflect air up. Pitch down, they deflect air down. If they're in front of the CoM and you pitch up, they should deflect air down (pushing the nose up rather than the tail down) and vice versa.

You know what I don't like? When I freely admit to being a KSP Win64 user (having used the Unfixer tool) and being forever tainted as 'annoying' or 'irrelevant'. Since switching to Win64 (because, with the amount of mods I want to use, OpenGL is sorely needed but breaks TextureReplacer reflections - Win64 doesn't have that problem. I have like 8GB RAM and a meh CPU on this laptop anyway, reflections are literally the only benefit I gain from Win64), I have not once reported a bug to ferram4 at all or any other modder without first verifying on x86. I know Win64 is unstable, the fact I had to hack it means I'm dabbling in things that ought not be dabbled into. But it makes me sad that the actions of other idiots tars me with the same brush. I recently had a bug with InterstellarFlightSwitch - first thing I did? Switch to x86 (even though none of the mods involved are specifically against Win64) and minimal mods for testing. 5thHorseman, you say I have that choice of number 1, of not reporting bugs when using Win64, but the reality is that I don't. Because if I report a bug and have admitted in the past that I use Win64 KSP, I'm assumed to also be a moron that doesn't actually check things. So I have to say 'yes I use Win64 KSP normally, but this was on x86 because I'm not stupid' and even then, I can sense the judgement. Just makes me sad, is all. Half the time, I don't bother posting something because I'm worried it'll just be ignored as another 'stupid Win64 nonsense 'bug' report'. Ah well. What does it really matter, in the grand scheme of things.. I stay quiet, bugs will still get reported by other users and fixed, I get locked out of one of my favourite mods, I lose interest in a video game and end up sad that the chuffing asset loader was stupid enough to kick off this whole thing :/

No, because I installed ModuleAnimateEmissive that came with the download.

It's fine, take your time. It seems Squad are in no rush to fix these bugs either so you're safe *ducks*

Bug report It seems IFS is activating engines with built in fuel tanks in the editor. I originally thought this was a KER problem but it was just reporting what was happening. My original bug report: The problem, as discovered by Padishar: I know this is a problem with IFS because removing it solved the issue and testing on a purely stock + StockPartRevamp resulted in no log errors (adding KER back in but not IFS results in no bug either).

Well that's very odd. Many thanks for the help and pointers, much appreciated

1, why would that be a good thing and how would you calculate it? 2, no, unless they encounter an atmospheric pressure of above 0.1 atm or the ground while on rails, they'll exist until you terminate them. 3, how would that be any different than adding a command pod/probe core to it via the Claw? Unless I'm misunderstanding what you're asking still.

Hope this helps. I built the rocket again fully, then hit the Verbose Log button.

1. I noticed that issue - it's fixed in the dev build 2. not a FAR issue, small parts overheat quickly (stock bug).

Huh, weird... That ARM LFB Twin Boar doesn't appear to be affected, it seems like it's just that engine.. what's more interesting is that it's just in that configuration - if I swap the engines around (Swivel on top, Beagle on bottom), everything is calculated normally. Well, I'm stumped then - if there was some problem with IFS, the Twin Boar would be affected. If the engine config was weird, it'd be broken no matter where it was placed. I don't even know where to continue with this then :| (EDIT: Now I think of it, Near Future has an engine with LFO included, I wonder if that has the same problem..)

Why do we even have these any more.. Nobody uses them (nor should they be), they're unnecessary clutter and worst of all, if you delete them, KSP just recreates them when you launch the game. Get those unnecessary folders out!

So I've found a little but annoying bug that only occurs in quite specific circumstances. Ingredients: KER 1.0.17.0, Interstellar Fuel Switch 1.14, any engine that also contains fuel (I use the Beagle from Stock Part Revamp) and a config that allows that fuel tank to be switched. Recipe: Build a simple rocket that consists of any pod, any fuel tank, the aforementioned engine, a decoupler, some more fuel tanks and any other normal engine. The problem is that KER doesn't calculate any ÃŽâ€v or TWR etc info for the rocket. Here's a picture that should help illustrate it: You can (faintly) see the bottom two tanks and Swivel engine, (clearly) see the engine info, the Fuel Switch info and KER not accounting for this. The log gets spammed with NullReferenceException: Object reference not set to an instance of an object at ModuleEngines.CalculateThrust () [0x00000] in <filename unknown>:0 at ModuleEngines.ThrustUpdate () [0x00000] in <filename unknown>:0 at ModuleEngines.FixedUpdate () [0x00000] in <filename unknown>:0 (Filename: Line: -1) NullReferenceException: Object reference not set to an instance of an object at StackIconInfoBox.Update () [0x00000] in <filename unknown>:0 (full log here) Removing InterstellarFuelSwitch does fix this issue, but then again, so would removing the modded engine or KER.. So, it's a little bug and one that I don't necessarily expect a fix for (though I'd like it), but it effectively renders that engine useless (which is annoying as it comes before the Terrier in the tech tree).

I wish it was something that simple Also, that bug was fixed.