Starwaster

Request: some sort of speed limiter, optional or otherwise. Probably shouldn't be possible to open a chute at Mach 20. At least not without ripping the chute part off. Curiosity couldn't pop its chute until it dropped to Mach 2. Or Maybe link it to dynamic pressure instead since that's where the damage would be?

sounds familiar but I'm not sure ai remember what I did to fix it when it happened to me... some things to look at try adjusting Td? maybe too much torque so disable either SAS or OKTO torque... was there RCS? if so disable smart RCS. toggle capslock...

I totally missed seeing that!

Just moving modulemanager might be enough. I'm away from my main machine or I'd be trying to replicate your problem. If moving modulemanager doesn't fix it then find your output_log.txt in the KSP_data folder. If you have a Dropbox then put it there and send me the link. Or maybe you can copy paste the contents to paste bin. (Except I'm not sure if there's a limit on pastebin)

I'm not necessarily looking for errors or warnings so much as I'm wanting to trace what happens when MM starts up and begins applying config nodes. The file itself is more informative than the console especially just a screenshot that amounts to just a snippet. Regarding modulemanager it goes in the top level of gamedata folder. There should be no copies anywhere else in any sub folders.

Not yet, I got absorbed in another project that I'm working on for KSP. I'll take a look at it when I get back from my holiday trip. What version of ModuleManager do you have right now and what else have you got installed? Also please put your your output_log.txt up somewhere and provide a link somewhere. (and no, there's not a whole lot this requires. MM 1.5 or MM 1.3 + SarbExtensions) and of course the science configs in gameData or its subfolders

same, it was cool

I was looking into it but I ran out of time because I'm going out of town for a few days. You'd think if they did anything significant that there would be error somewhere; either in the GUI we put in or when it initializes or something....

The stock port configuration files are missing entries for breakingTorque & breakingForce, as are many other stock parts. If you've ever had a ship/station spontaneously come apart or have pieces just fall off when it was under no apparent stress (floating in orbit) that's why. Starwaster's obligatory breakingForce fix follows: (requires ModuleManager 1.5.x) @PART[*]:HAS[~breakingForce[]] { breakingForce = 200 } @PART[*]:HAS[~breakingTorque[]] { breakingTorque = 200 }

I'll be nice and hold my tongue

sounds like you forgot to install the new ST. pre. its in his post where he posted the latest MFT pre Nathan, another bug. cannot completely empty any MF tank. It has to have at least 1 unit of fuel. If I set it to 0 it reverts to whatever the positive value it held before I tried setting it to 0

I think this is a pretty busy time of year for a single day of testing.

Oops forgot about needing an operator in front.... but does % work with 1.5? Because that's the latest official. Anything after that is a dev version.

Looks ok except for whether or not there's an actual resource named Water. If that's getting defined somewhere else then you should be ok. Also, as I said, I'm not familiar with Interstellar since I don't use it so I'll assume the node names are correct Also, the thing with LSS causing VAB icon problems is definitely not a ModuleManager issue. I'd take it up with asmi in the LSS thread.

That doesn't sound like ModuleManager. Sounds more like a problem with the aforementioned life support module. Which LS mod is it? Also, show the code you're using to add it. The same way as you would any other config node, which is all PART is. It's just a config node that refers to a part. resources would be RESOURCE_DEFINITION, and you might want to consider changing THAT for LqdWater as well.... or otherwise make sure that Water is a valid resource. I'm not familiar with Interstellar's configs so I can't really say anything specific about those./

Syntactically correct but you mention changing one resource to another and I don't see that happening in your sample code. If the part named FNLiquidWaterTank actually has a RESOURCE named water then yes it will work as you have it above.. If however that part actually has a resource named LqdWater then you want this where your resource code is @RESOURCE[LqdWater] { name = Water amount = 4065 maxAmount = 4065 }

That's why you have to follow every banking maneuver with banking on the opposite side to offset by the amount you banked the first time. That's how the shuttle did it right?

Updated OP to clarify ModuleManager requirements and remove mention of MM 1.3 or MMSarbianExtensions. It will still work with those older files for now but if you install 1.5 you should definitely remove older MM / Extensions.

If you have ModuleManager 1.5.x you don't need MM 1.3 OR MMSarbianExt.dll because MM 1.5 has all that built into it already. Basically Sarbian rolled MM 1.3 + his Extensions into the new ModuleManager. If you dig deeper into the MM 1.5 thread there's even more recent versions but I'd stick with 1.5 for now... I think anything more recent than 1.5 is still beta for now. (though I've been using 1.5.5 without any problems and eventually it'll get rolled over into official release I expect) So bottom line is, remove all versions of ModuleManager older than 1.5 (which belongs in GameData folder) and remove MMExtensions

But what causes it? It doesn't do that in stock, does it? Is it cosmetic only or can it cause genuine problems? If it has to be that way to avoid engine problems then let's stick a blanket MM statement in somewhere, (not :Final) @PART[*]:HAS[@MODULE[ModuleEngine],@RESOURCE[@ElectricCharge]] { @RESOURCE[ElectricCharge] { %isTweakable = false %hideFlow = true } } That should do it if I understood the problem correctly.

I'm already using RSS with 0.23. Aside from atmospheric rendering issues, it already works. LOL! I thought it would slip by unnoticed actually. Glad you caught it.

Haven't had much chance to do any testing today, been massively busy getting ready to go out of town on the 23rd. Someone asked what RO I was using, but on my 0.23 install I don't have it installed, just the engines.cfg from the previous (3.3) official release of MF. But I also see that Nathan reports he thinks he fixed the issues in RO so it might be moot anyway.

When you see that happen next, immediately close the game (so as to avoid further logging) and go get your output_log.txt file and put it in a Dropbox location or other file service so that asmi can get it.

After AP has done its job it won't affect anything until your next launch since there is no terminal velocity in space. If it disables itself every time you reach space that means having to turn it back on every time you launch.

Look two posts above your post. At least read the last page before asking something like that.