BudgetHedgehog

If you're modding, ModuleRCSFX includes support for such things.

From memory, multi-directional bipropellant RCS is not something KSP supports.

No worries, glad I could help. Certainly not a waste of a thread, you had a support question and tbh, it's a pretty niche bug that not many people are likely to know about. I only encountered it once where my skycrane would be flung off the launchpad like a catapult.. funny, but annoying. Is there a specific reason you're recovering those parts? Because you can take science out of experiments and store them in the pod, that'd cut down a big amount of height, probably enough for you to not need the winglets. And thanks, I made the right hand side, katateochi made the left Oh, and don't forget to mark this thread as Solved - go to edit your OP and there should be an option to change the flair. Might need to go advanced.

TweakableEverything 1.11 had a problem with the OX-STAT unhinging reality, maybe you should update that (the latest is 1.11.5). But without an output log from you, no-one can know for definite. Also, 1.0 physicsless parts transfer their drag and mass to their parent part. They are physicsless still, but physicslessness is handled differently in 1.0. So, no. EDIT: I see you're using FAR - in that case, drag is applied to the solar panel as the voxels see it, but the mass is transferred to its parent. No, this isn't fixable and no, this isn't the cause of your problem. Also, why does your pod have winglets?

KW Rocketry ships with a ModuleAnimateEmissive or something plugin for the engines - would it be worth investigating that? No need to include it as a hard dependency, just use it if it's there (with a NEEDS on the patch). Thanks for the update as well

From memory, that's actually intended behaviour - you set action groups for a part and then if you move the part, you must also update the action groups for it. It's stupid and very weird, but it's working as intended. If you're not against modding, Claw's StockBugFixModules includes a fix for this.

I'm a little confused as to enabling StockPlus - if I understand the OP instructions correct, I need to globally enable StockPlus (via StockPlusController) as well as individually enabling discrete modules with True as well? If StockPlusController is missing or set to false, no StockPlus modules are enabled at all, regardless of individual setting?

What's the number I have to change to make the default speed slower?

I'm still not entirely convinced that those oceans aren't photoshopped in from real life..

And you didn't post THAT output log because....?

OnGUI transcript (full) Mu: "We're eliminating all uses of OnGUI from the code, which is.. if you've profiled the game, it's a huge black pit of performance.. umm.. that is going to be a huge boon, I think" Maxmaps: "How do you expect like in the case of modders, do you think they're going to have to redo a lot of work or..?" Mu: "Well, most modders use OnGUI anyway so they should be fine.. umm, for those who interact with the standard UI, it should be pretty similar because most of the stuff is just being rebuilt, but it's still called the same thing. Umm, we have namespaced it all off, so you'll definitely have to recompile, but that makes the game easier to program for anyway.. umm, but they'll also be able to use our pop-up prefab windows easier which is basically like OnGUI but done in unity, so max performance with uh, actually minimal code changes, it was designed to replace OnGUI code so it almost works exactly the same." Maxmaps: "Awesome!" Mu: "And also, they'll have better access to all of the things and should be able to change them easier, it's a lot easier to code and script than EzGUI was and certainly SSUI which was, is the third thing.. so yeah, it's positive, modders will have to put a few minutes in here and there but it should be fine" Maxmaps: "It won't be a massive amount of work that will tank your systems, but in the end, it will be worth it, I think" Mu: "It's gonna be worth it, both for us and players and modders because it's such a pain to maintain the interface"

Hello everybody, and here's the summary for Squadcast 2015-05-30. Sorry for spelling mistakes etc. I try and clarify what is an actual quote from Max (if it's wrapped in "quotation marks", it's the best transcript of an official Squad member you'll find on the web), and what is a summary from myself as I'm aware I switch between the two with 0 notice. When I say 'Squad', I mean 'the relevant people who are currently developing the game'. As always, this is just a volunteer transcript of an off the cuff vlog of a non-native english speaker - some details may change or be entirely incorrect. Squadcast Summary for 2015-05-30 - Watch it here! Mu joins in this week! He's from Manchester and has a silver car 3 weeks ago, Squad were working on 1.0.1 and 1.0.2, the next week, they were jumping out of planes in Mexico. Max got a hairline fracture on his coccyx. PSA: right now, physicsless parts aren't truely physicsless anymore. They transfer drag and mass (i.e. all physical properties) to their parent. This week, Max and Mu talked mainly about Unity 5 and the 1.0.3 hotfix. With Unity 5, every single UI will be replaced as the current system uses like 3 different UI systems which bloats the game. With them all being replaced with 1, it'll hopefully optimise things, reduce scene change loading tines a bit etc. Overall, it should run slicker and get a bit of a visual revamp. Modders will have better access to things and able to do more stuff (some stuff about OnGUI that I don't understand (Squad are removing all uses of it, but modders are still able to use it), best to watch it for yourself if you're a modder (or not) and want to know more. Skip to 6 minutes or read my transcript here). Wheel colliders in U5.. they're not fun and are a pain unless you use them specifically for cars. For spaceships with 12 wheels at odd places, it works perfectly up to 5m/s or so then wobbles to death. So they fixed it - as mentioned in the last Devnotes, they're using a custom version of something from the Asset Store (written specifically for KSP by the author) that should handle things a lot better. Also, brace yourself - multithreaded physics incoming 1.0.3 news! Mu's been putting hours into it, he noticed even before 1.0 that balancing heating for command pods and cockpits is mutually exclusive, so they're introducing a new heating system called Skin Heating - basically, rather than seeing a part as a part, you see it as things surrounded by a shell of metal that heats up and cools down quicker - this basically makes things easier to balance overall. Same system as in Deadly Re-Entry actually - Squad talked to those devs and got permission to use some of their ideas. All their own code, but some of DREs ideas. 1.0.3 will not be released this week due to this new heating system needing balance, Squad wants to make it right first time. 1.0.1 and 1.0.2 were about 6 hours apart, Squad wants to avoid that again. Re-entries will be "better", should exit and re-enter more stabley. Rockets will be more stable, aero will change a bit so "just wing it". More engine tunings, fairings have been fixed ("for the changes to the heating system" - NathanKell), Mk3 parts drag fixed, temperature gauge memory leak fixed (huge thanks to sarbian for helping with this).. big changelog, but not coming this week and probably not the next either. Regarding the editor aerodynamic stability overlay, it's still pencilled in, but it's one of those things that the more you add to it, the more you CAN add to it, which is a dangerous position to be in. Still, it's in the devs minds. Big news: Once U5 is done, Mu will take a more serious role regarding development: he'll take the wheel for 1.1+. Multiplayer development is getting seriously done, so HarvesteR is going to concentrate more on that, while Mu will take care of KSP core in general. Few new.. "procedures" regarding design, input and feedback. Other stuff that you already know or don't care about happened, Jeb died again and Max is still terrible at KSP. ________________________________________________ And that's pretty much it from me. Ta-ra, procrastinators!

The Cupola isn't shiny This is in the log when I attach it: "[Log]: [TR.TRReflection] Failed to replace any shader on "cupola" with its reflective counterpart" With this in the TR config: @PART[cupola]:NEEDS[TextureReplacer] { %MODULE[TRReflection] { colour = 0.3 0.3 0.3 interval = 2 meshes = Shine } Everything else shiny works fine though. - - - Updated - - - Why would you expect them to work? They can and probably do point to different reflective meshes, hence the conflict. As to without WindowShine, I've only noticed the cupola not reflect. The Mk2 lander can is not configured to.

Christ, that's looking amazing.. doesn't even look like KSP any more, it's amazing to think that this is possible. In answer to your question, I like the previous version (picture Proot posted).

From the OP:

No, existing vessels are fine

No, exactly the same height, it just looks bigger. EDIT: Also, with HotRockets, the Mainsail effects clip into the nozzle.

At the risk of going off topic, FOR is for a mod author to distribute their own patches for their own parts. :FOR[ModName] = I am ModName and these are my patches while :AFTER[ModName] = execute this patch AFTER ModName executes its patches. More documentation is in the ModuleManager thread - some is confusing, but all is straightforward. You could be right about it only concerning KCT - I only mentioned StageRecovery as the problem occurred upon recovery. Who knows.. and as I said, that bit isn't entirely needed anyway - it loads fine for users without KCT and they could all benefit from proper sorting.

Incredibly detailed work, thank you!

@PART[KW*engine*]:AFTER[KWRocketry]:NEEDS[KerbalConstructionTime|StageRecovery] { @category = Engine } @PART[KW*tank*]:AFTER[KWRocketry]:NEEDS[KerbalConstructionTime|StageRecovery] { @category = FuelTank } This might be better then - the patch is run only if KCT or Stage Recovery is installed (though honestly, it doesn't really matter to the end user if it is or not, because as noted, the parts get sorted fine anyway) and after KWRocketry - Final is not recommended as it can conflict with other patches applying a different change to the same bit that are also running on Final. NEEDS[KWRocketry] is kind of redundant as it's applying the change to KWR parts which obviously only exist if KWR is installed.. You'll want to use NEEDS when you want to change a part if ANOTHER mod is installed. You don't distribute a patch for your mod that changes your parts only if your mod is installed, it makes no sense.

Use the engines other attachment node. There's two on top - one includes the tankbutt, one does't. They're pretty close together on some engines, so just keep trying.

@LeoJadeFox - after deleting KerbinSide and if you still have problems, could you post a screenshot of your Gamedata folder? You might have another pack of buildings that affect the KSC (like KSC++ from Lack).

Just in case other people were unaware, there is also this 64bit discussion thread in the Tutorials forum.

Installing them manually:

Correct, it doesn't work like it used to. Instead, now you have to place the part first, then mouse over it and press V.