Starwaster

I have only one thing to say to that. ARRRRRGHHHHHHH Edit: Actually..... I panicked for the wrong reasons. There IS a problem but it's not the module I'm using, the problem is the experimentID. It should at minimum be set to surfaceSample which limits where you can perform that particular set of research. Even better would be a new set of messages appropriate to mechanical probes. I'll fix that.

Only the people who asked for these changes get to provide input? This affects all of us. You're cutting out the rest of the community who then basically get this rammed down their throats. Just because a few people aked for this doesn't mean it has to be done. The changes under debate address a non-issue. One DLL, one location. If there's a choice required to overwrite or not then, look at the dates. and honestly there are not (by now) so many versions floating around that we have a version issue to begin with. MM works and aside from updates to address future KSP updates breaking MM. It does one thing and should do it well. The only other addition I can see being ok are your wildcard extensions. But aside from that, it's not like it has to have tons and tons of features. It's ok if ModuleManager never ever again gets another update!!! Just so long as it continues to do what it currently does with future versions of KSP. ModuleManager should mirror the way that KSP itself functions with regards to a ConfigNode. KSP loads them and processes them no matter where in Gamedata they are. ModuleManager should do the same. It shouldn't matter where in in the Gamefolder they are any more than any other cfg file. They're already there when ModuleManager loads. So execute them. See above. If you're already envisioning adding so many features that something can break then you're falling victim to classic feature bloat already. That's not a good sign. Nope.

I checked and I do have the latest. What's more, looking at I do see LiquidH2 tank mass... And basemass. Since I have a set of WIP configs I checked there but I'm not touching LH2 tank mass. So I'm not sure yet where the missing mass went

use the latest development build of MJ. It does take into account atmo thrust. (says SLT) IF you are using MFSC

Hydrogen specific tanks still have no mass at all. I always assumed the rationale to be that they were already massive enough to account for the necessary mass of a hydrogen tank. When cryo tank mass was decreased with the rest it introduced a discrepancy in hydrogen tank mass that's not been addressed.

Sorry I'm only just now replying to this. If Mercury needs 48600EC then that's 48 of those 1K batts. And change. 12 if 4K That's not an attractive number unless you're upgrading batt capacity. On another note, with the tank mass further decreased in recent versions using the ultra realism option, the big orange tank configured for LH2 only has a dry mass of 31 kiloGRAMS.

kethane... maybe?

omg DO WANT. I'd have bases on the Mun and Duna if it weren't for my advance bases mysteriously vanishing or disassembling when I switched to them one too many times.

Is it? Back when I was active in the Crysis modding community I always felt mildly annoyed of people asked me for permission to use something I'd openly stated was permissible for anyone to use as they willed. I always wondered if that was just me so I just silently bite my tongue and say sure have at it.

See the part that alarmed me was that I thought we were talking about the Soyuz itself not the launcher carrying all that HTP. In the boosters, as was speculated it's for the turbopumps. And some of it is for orbital maneuvers and re-entry. (just not 9 tons worth) And yes, they can go EVA, open up the spigot, remove their gauntlet and treat their paper cuts....

9 tons??? HTP is denser than water isn't it? If we're talking metric tons that's ~9 cubic meters. How sure is that 9t figure?

Is it possible your craft are just overpowered in that stage? What's the TWR and have you tried throttle limiting in Utilities?

Wildcard matching all the way down would definitely be cool!

Well fortunately for you, I'm like a Rottweiler or a Pitbull when it comes to bugs, even if they aren't my own. Sarbian's initial instincts were correct, he would have been right to say it wouldn't work. I had another look at the code and wildcard matching only happens once for the initial node (@PART[*]) (which is just intended behavior, not a bug ) Technically it could be done for each of the conditions that appears after, but that might be detrimental to start-up times. Or it might not make much difference at all; wildcard matching does use Regex (ha ha) which is pretty fast.

Has it? I just gave those conditionals a try just as I showed you but they don't seem to be working after all. I think Sarbian's praise might have been premature. Though it really seems like it should work... just in case I tried reversing the order but no dice. Have you gotten it to work?

I don't think the actual order matters... not when you have them separated by commas like that, it only cares that all conditions are true. There is another way where instead of separated they use nested :HAS[] constructs so that you can check if specific nodes contain other nodes or properties. One thing you can't do though is target individual nodes in the the PART node. Like if there are multiple ModuleAnimationGeneric modules, you can't target a specific one. That's as much a limitation of ModuleManager itself, or maybe even stock KSP.

Hmmmm. Try this: @PART[*]:HAS[!RESOURCE[ElectricCharge],@RESOURCE[*]] { // Your stuff here. } No spaces at all in the first line, exactly as I have it. Unless the no-space thing also got fixed in Sarbian's update this morning...? in any case you should grab that update.

I know someone already posted a modified config for the Science module but here's another one that has working antenna and equipment bay. (equipment bay shuts anytime you keep / transmit data but that's stock behavior). I also removed the toggles for the various sensors in the interest of keeping the menu clutter down but you can still log data with them for Science!!!â„¢ This one requires module manager; it's just a patch file not a full part file. You can put it anywhere in the Gamedata folder or its subfolders. For career mode I set it to Field Science with an entry cost (ignored right now) somewhat higher than the Hitchhiker pod zzz_science.cfg dropbox link

So what's your point? Seriously, so what??? He wants to ask Squad for an unlock button that will take five minutes to code and compile and you're going to argue against it? Are you going to have trouble sleeping at nights if he gets the button? I don't get it... what's your real objection? Edit: And people, deriding his idea as stupid is one step away from being an ad hominem attack. If you disagree, fine, present reasons why or otherwise contribute meaningfully. I also don't buy that this is a mod only issue because it would be valid anytime Squad releases new parts not present in already researched areas OR if Squad makes future changes requiring one to to unlock anything in the tree after researching it.

This isn't a banning per se but I was kicked from a multiplayer co-op game in Left 4 Dead 2 for asking "who are those guys on the bridge?" because I hadn't played L4D1. (the map was The Passing)

It's not totally hopeless. Use ModuleGenerator to provide the power drain. MODULE { name = ModuleGenerator isAlwaysActive = true/false activateGUIName = <text> shutdownGUIName = <text> INPUT_RESOURCE { name = <resource name> rate = 1.9 } OUTPUT_RESOURCE { name = <resource name> rate = <numerical value> } } Entirety of its possible parameters provided. What you want should be fairly simple... Module { name = ModuleGenerator isAlwaysActive = true INPUT_RESOURCE { name = ElectricCharge rate = 1.9 } } That should do it...

power consumption works for those modules because there's programming in c# that reads those properties from the module and requests the resource via the API. If SCANSat is a PartModule you're developing via C# you should look at other plugin source to see how they're doing it. For example the radiator code in the most recent versions of ModularFuels. Go take a look at how it implements reading properties from a module requests resources from the craft I thought there was a #3 but i just woke up and have no coffee so I forget...

One day I am totally going to make one of those.

Aside from the part about deciding how much ElectricCharge to output, that's not very hard to implement at all. BTW did anyone notice that the R&D center makes an actual reference to a specific electrical unit of measurement? Under Advanced Electrics it says that they're fairly certain nobody will ever need more than 64kw. It's hard to know for sure if they're referring to the 400 EC battery or the 6 panel solar arrays. But if you divide the battery's 400 EC capacity by 64 you get.... 6.25.

Cycle through all transmitter parts and change the requiredResource to a non-existent resource. When you want to make comms available again, go through them all and reset them to ElectricCharge