Starwaster

RC sets part mass according to chute mass. Sounds like it's caught in some kind of loop

And x / 2 / 1000 is functionally identical to x / 2000 Gotcha, thx for clarifying that I thought it might be buried somewhere in there but wasn't sure

parts packs are what kill you, not plugins. if you still have the old version just replace the paradocks with older versions.

********public float DragCalculation(float area, float Cd) ********{ ************return atmDensity * sqrSpeed * Cd * area / 2000; ********} ???

chris, I was poking around in the code and looking at the drag formula and at drag studies in various documents online (NASA, military, etc) they all use half of the atmospheric density value. Is there a reason formusing the full value?

Never!!!! they cant take the sky from us! in fact, it's still there from what I can tell.... maybe the shading got altered or the shell isnt scaling high enough

kkthx for the replies. figured something like that and I figured you probably knew but wanted to make sure.

MFS doesnt seem to be working under 0.23. tanks / engines only using their stock resources. Anyone else tried it? will look at the log file to see what the problem is, just havent had the chance yet. gm537: That's how H2 behaves in real life. It's a very light low density fuel that provides better thrust and delta-V per kilogram. If you're intent on only comparing a given volume of H2 against an equivalent volume of a denser fuel then you should expect the result you got. If you dont want to use larger tanks of H2 then it can't be helped. Edit: but yes, update to latest version and use realistic mass option.

atmosphere isnt displaying properly in 0.23..... havent actually tried 0.23 stock though. lol. so I dont know yet if there's stock atmo changes the rest of you are aware of that I should already know about. (very busy day, just had time to glance at it and not much more)

Yeah that's the way it seems to read... Resource name is jet a string, no list that I could see... What did you do exactly razorcane? Just set resourceName twice once for each fuel?

I saw a launch tower topple over after I released it last night. KJR was NOT installed on that particular KSP installation. Actually I'm not quite sure which one I was playing. I have a lot for testing. I think the mod list was: Achievements, MechJeb, KWR, KSPX (both parts only), ModularFuels, Stretchy Tanks, Procedural Fairings, RSS, SDHI, Real Chutes, Clouds / Texture Compression. The only one of those I would even remotely suspect is Real Solar System... maybe the launch towers can't grab onto the ground properly because of some scaling issue. OR it could be a stock issue.... not discounting that. KJR was not installed however.

wow I hope that's wrong because if it's right that screws over RSS.... minimum orbital altitude is just a bit under 150-ish Need more info or clarification... do you mean it flips? does it happen during your gravity turn? if so you might be starting too late.

Check the part's cfg file for a line that says rescaleFactor and change the value from 1 to 2

I thought it was already in.... or are we talking simultaneous? or.....?

I think you're right. I think they also respect full containers. I dont know if missing inputs is an issue for them because I think it only takes one input... I think. at its most basic it needs ModuleEngineConfigs added. Look at engines.cfg to see what that looks like. One of the configurations should match what that engine already uses, preferably as its default. OR: you should replace the resources used in ModuleEngines to match the default in ModuleEngineConfigs. First entry is the micro engine which does just that to change LiquidFuels+Oxidizer to MMH+N2O4

Ack! You win. I dunno what you win but you win. No! No more dart boards in the inflato-hab! Jeb's breaking the bank on duct tape alone...

Sounds worth checking out for sure.

Stupid_Chris, any chance of making 0.2.1 available? The orientation-to-ground is much more prevalent in RSS and even if it's only graphical (though sometimes it seems like it's not....) it's most disconcerting

Why would we?

None that I know of. The generator can be manually turned on and off but that's it. I was poking around at the module definition and there's a parameter there that I've never seen used, resourceThreshold. I have no idea what it does, it's not documented and not used in any stock parts that I've ever looked at and it had zero effect when I tried setting it to various values. What I think could work is making a plugin that implements a new part module that uses and overrides ModuleGenerator. It could activate/deactivate whenever its output resource needs refilling (and possibly when one of its input resources is empty). Have to think about it some more.....

I have not yet had a chance to test this myself. As I alluded to above, this is a configuration that will add a ModuleGenerator to all RCS parts that already use MonoPropellant. (this on the off chance that someone is using some modded RCS part that uses a different singular resource so this doesn't screw up their stuff) It also adds a small buffer resource of MonoPropellant. The generator will suck in MMH & N2O4 and produce MonoPropellant. The buffer isn't strictly necessary... I think.... but there's a nagging feeling that I should put one there so I did. Probably this means you don't even have to add separate monoprop tanks so if you have engines that use MMH/N2O4 then you can dedicate all tanks to those resources. The generator is set to turn MMH / N2O4 into MonoPropellant at the same rates that rocket engines would consume them. So you shouldn't get an imbalance in those two resources. But if for any reason you run out of any one of those resources, AFAIK the generator will continue to suck in the other resource without producing MonoPropellant. Again, untested (I'll test it myself when I get a chance today) but this should work. Extreme beta edition, try it at your own risk. (requires ModuleManager 1.5+ or MM 1.3 + Sarbian Extensions) save as real_RCS.cfg anywhere in your GameFolder hierarchy. Edit: Ok, just tested my own crazy creation and it works. Except that it gulps down that fuel far faster than it needs to..... Just a few test maneuvers totally drained my tanks. I don't think it's a mass conversion rate because I don't think ModuleGenerator cares about mass ratios at all.... just resource units worth. But it occurs to me that while the tank drains in fractions, the generator is going to always convert at the rates I told it to even if it means that some is wasted.... So I revised the code to do it in fractions, and dammit, am I the ONLY one that when typing code on the forums keeps pressing ctrl+S to save???? Please tell me I'm not alone Edit #2: Oh CRAP. Total damned failure. I should have known this. I did know this once but it's been so long since I messed with ModuleGenerator that I totally freakin forgot that ModuleGenerator drains all INPUT_RESOURCE with absolutely no regards as to whether or not: There's a need for the OUTPUT_RESOURCE There's ROOM for the OUTPUT_RESOURCE Which really really sucks because aside from that small detail? It was totally freakin working. Totally man. Back to the drawing board. (but not today, too much to do on my own KSP project that I started on recently)

I'm not sure how you feel about using things like Kerbal Joint Reinforcement in your creations but I bet that could hold your ball together! (resisting urge to pluralize ball...)

I thought of a few ways that RCS can be made to use MMH/NTO or anything else you might want it to. Came to me when I wasn't even thinking about it. Actually there's a few ways probably. Basic method is using ModuleGenerstor to convert NTO/MMH into MonoPropellant. Everything else is variations on that scheme. Very basic is using a MM config to add a small MonoPropellant reservoir to anything with an RCS module that uses the MonoPropellant resource. Add a ModuleGenerator that turns MMH/NTO into MonoPropellant. More complex would be a checkbox in the MFS GUI that will add the generator to to any tank you added MonoPropellant to

I thought there was another change I made in there.... but I just realized while reading your message that the file I put in my drop box isn't the latest file. I'll fix that in just a sec... The config node typo ensures that the RSS powerCurve gets put in the module and not in the part itself. (I probably should have seen that happening before but it's hard to read everything in the debug screen) BUT. There is another change and that's to the powerCurve keys in the RSS settings file. When you were walking over the parts and replacing the powerCurve in solar panel module it's not loading the keys in properly. The original fix I put out worked ok by converting the first set of parameters to exp notation. I don't know why that wasn't enough when RSS loaded the keys in itself. I had to convert the second set of parameters too and that apparently fixed it. floatCurve.Load() seems to have problems that the config manager does not.... oh and it doesn't like comments in the powerCurve keys either so I got rid of those. Edit: Ok, just double checked and the only other change I made was some now-unnecessary debugging stuff. It's not important. Just fixed the typos, converted all key values into exponential notation and removed the comments. And also put back in the 3rd and 4th parameters since I had no idea at that point what was going on and didn't know if those values missing were maybe causing this somehow. So, summary on the settings file is that powerCurve.Load() doesn't like comments and for some reason was misinterpreting keys/values if they weren't all in exp notation (if the range key was too high?)

You're not fooling anyone, you know. We all know a Dyson sphere when we see one.