Starwaster

They're not supposed to fill the screen, try the latest beta. That should fix it. @Taniwha: Thanks for the feedback. I was using Apollo as a guideline for deployment. You can tweak deployment settings in the VAB. (or maybe even in flight.... however (un)realistic that is)

It wouldn't matter even if you used an older version of MM as long as none of its configs use syntax unsupported by the older version. The plugin itself is not MM aware. In fact you could use any version of MM as long as it runs in KSP 0.25

Well... since he's using the tank for an engine AND RCS, he gets two buttons. What I do there is put a tank of 'buffer' resource in exactly the amount I want to give for RCS, then auto assign the resources for the main engine, then remove the buffer tank then auto assign the RCS. (it gets even easier if your RCS and main motor use the same propellants )

What needs to happen is that a new transform has to be added with its Y axis pointing out of the docking port. That's its control transform. In the docking port module's config, it has to have controlTransformName = <the name of the transform> added Preferably that should be added to the model itself but it is possible to hack it in via the part's config using MODEL nodes. I've done that before to add in proper control references to Porkjet's FLAT habs.

Saw RSS being talked about on a web page... for a moment I thought it was an article about Real Solar System....

The errors in the KSPI_RF.cfg are probably not related to your other errors. I did note those earlier in Northstars error log and they are probably some kind of syntactical error in the config. Edit: And you should post your output_log.txt file. (player.log if mac or linux)

Dropped it in and it is working just fine. I'd set the heatConductivity, heatDissipation and heatGain the way I set it up in the other radiators. It'll have better behavior. Especially it prevents the radiator from trying to transfer heat back into the tank.

Correction: MJ works fine in RSS. MJ works freakin fantastic in RSS with porkchop plotting support!!! Porkchops are tasty and packed with protein...

It's there on the OP. It's for fields rather than for nodes so you don't use {} with it. If a part or a node has a field (variable, property, whatever you think of it as) named x which is set to y then doing :HAS[#x[y]] tests as true. You'll notice that undercoveryankee's example is :HAS[@MODULE[ModuleCommand]:HAS[#minimumCrew[0]]] ; That :HAS[#minimumCrew[0]] directly after @MODULE[ModuleCommand] so it's checking to see if the MODULE named ModuleCommand has a field named minimumCrew which is set to 0

Yes it was bugged, that was one of the things I fixed. The action group items have always worked though. Is your strake on a pre-8.2 craft? The changes aren't retroactive. The UI would likely be turned off on the part's radiator config node in the save file. Attachment doesn't matter with regards to the UI showing up or not. (and with regards to actual cooling I believe I made it optional whether it was even configured in the pump config node with it defaulting to the parent part as in the older code) Edit: Have you gone to the R&D building in your career game and checked to see if the part needs unlocking?

Now that you're updated, look again. It's always been there, but until now only the action group items were dependable. But it's always had on/off controls, with the default being off. I see no other reason why it would not be working for you. I don't just pull this stuff out of my buttocks you know.

Ok, so testing with the ADEPT shield shows that FAR does properly recognize that it has animated. cd increases and decreases as the shield is deployed or retracted. Reference area though... increases for the retracted state and decreases for the deployed state. I thought reference area was supposed to be the cross section perpendicular to the velocity vector so that doesn't make sense to me. I guess FAR is measuring it along the long axis without regard to orientation? I dunno, but whatever, it looks to me like it's working the way it should. Not sure it matters but I replaced the references to the advanced animator with the stock generic animator on my install for the ADEPT. I don't think it does...

There's an animator dependency. You need to download and install http://forum.kerbalspaceprogram.com/threads/73283-0-23-x-AdvancedAnimator-ModuleAnimateGeneric-upgraded-v1-1-1-2-04-14?highlight=moduleanimator

Round 1 of testing. What I did was apply a patch to remove certain parts of the inflatable shield's modules if FAR was installed. Those modules are the ones that change drag based on the state of animation. What I'm seeing is that cd, BC and reference area don't always correspond with what I expect to see. Reference area seems to increase like it should but cd increases when the shield is deflated rather than when it's deflated, which doesn't make sense. Terminal velocity and BC don't change at all. Net result is that there's no apparent change in drag. I suspect that it's more an issue with the shield's animation, which as I've alluded to in the past has issues that confuse modules trying to read its state. DRE seems to read it ok but maybe I need to re-evaluate that too. I've also indicated in the past that people might want to use the ADEPT deployable shield would be a better choice than DRE's own inflatable. You can get it here: http://forum.kerbalspaceprogram.com/threads/98178-NASA-Adaptable-Deployable-Entry-Placement-Technology-(ADEPT)-by-OLDD-(26-04-14). I don't have a patch for it yet though. (the patch that strips it of its drag altering modules when animating) If you want to test the patch that I made for DRE's inflatable, here it is: Edit your DeadlyReentry.cfg file and paste this at the bottom: @PART[6.25_Heatshield]:NEEDS[FerramAerospaceResearch] { !MODULE[ModuleAnimation2Value]:HAS[#valueName[minimum_drag]]{} !MODULE[ModuleAnimation2Value]:HAS[#valueName[maximum_drag]]{} !MODULE[ModuleAnimation2Value]:HAS[#valueName[angularDrag]]{} } EDIT: Here, I just whipped up one for the ADEPT shield (which really is a high quality product BTW. Not sure if I remembered to link to it in the OP..... if I haven't I soon will) I'm going to test this myself in a bit but I have to go do a thing. @PART[NASAaeroShield_A]:NEEDS[FerramAerospaceResearch] { !MODULE[ModuleAnimation2Value]:HAS[#valueName[minimum_drag]]{} !MODULE[ModuleAnimation2Value]:HAS[#valueName[maximum_drag]]{} !MODULE[ModuleAnimation2Value]:HAS[#valueName[angularDrag]]{} } @PART[NASAaeroShield_B]:NEEDS[FerramAerospaceResearch] { !MODULE[ModuleAnimation2Value]:HAS[#valueName[minimum_drag]]{} !MODULE[ModuleAnimation2Value]:HAS[#valueName[maximum_drag]]{} !MODULE[ModuleAnimation2Value]:HAS[#valueName[angularDrag]]{} }

maybe. Maybe not. Testing something now to change the inflatables behavior when FAR is installed but I suspect that FAR ISNT seeing the changed geometry when the shield inflates. Which afaik, it's supposed to. If it doesn't then there's nothing I can do.

@Tochas grab the latest beta. That problem is fixed. @Maxwell it's probably setting fields that FAR depends on being blanked. I'll address it when I'm really awake.

Northstar try grabbing the pump module config from the zzz radiator. I was using that just last night so I know it's working... Uh you know it has to be turned on right?

Ensure that you do not have any other config files that might be adding MJ2 functionality to your command pods. Jacke's config file won't try to add to parts that already have MechJebCore.

If possible, try to keep those parts away from the fairing wall. AFAIK, FAR uses a bounding box to determine what is inside the fairing. So it's possible for things to lie outside of the walls of the box. Not sure if the size of the box is based on the fairing or the fairing base.....

Crap and I just thought of some other heat pump code hacking that I wanted to do today. (it occurs to me that it would be nice to have the heat pump handle built-in animations so that zzz's deployable radiator doesn't have to have animation and heat pump activation in two modules and two action group items) (oh well.... 8.3 then) (edit: actually, don't mean to imply that the zzz radiator uses the animation module because it uses the solar panel module to handle its animation so it can track to point away from the sun)

Looks ok as far as syntax, but your inflato2 is missing a { I replaced it in my quotation of your code.

Notepad++ is a good way to check for that. Do a search for { and click the count button. Then search for } and click the count button. If they don't match, problem

Sounds like you don't have the plugin installed. Both the config file AND the plugin from the post that I linked to need to be installed. They can't have Kerbals in them until inflated at all. Or... what are you trying to do exactly, inflate them IN the VAB and assign Kerbals??? Is that a life support mod? You should ask the mod's developer to provide support for the inflatables. Unless you want to write a config to do that. Or switch to Ioncross which supports the inflatable habs out of the box.

You should get rid of the older fix. It was just a workaround of execrable quality. Just use the most recent patch file and delete anything older that I did. You should be able to move Kerbals into them by any means that Kerbals could ordinarily be transferred into a crew ready part. i.e, mods that transfer Kerbals, EVA Kerbals trying to enter hatch or stock crew transfer system. Please note that the inflatable will not highlight when using the stock crew transfer mechanism. Probably because it's checking the prefab instead of the part itself to see if it's crew capable for highlighting purposes. It will however still allow the transfer.

These should do it https://www.dropbox.com/s/4ig4cuv5s5xo7c7/RealFuels.8.2.zip?dl=1 Still in the process of testing the compilation but everything looks ok so far.