Starwaster

Sure it is Up to 2km anyway. With a custom plugin. (that doesn't exist)

Try it with Real Solar System Mod installed and let us know how it works there. http://forum.kerbalspaceprogram.com/threads/55145-0-22-WIP-Alpha-Real-Solar-System-v5-2

In case you missed it, any chance of a larger inflatable hab but with end caps the same size? Per http://forum.kerbalspaceprogram.com/threads/57662-WIP-Inflatable-Hab-Module?p=814497&viewfull=1#post814497

Is it possible to resize the canopy?

Yeah that's better than it was. It did still go through a lot but I did accidentally leave it set at 5m/s limit. which caused a collision and a second docking attempt. the main thing is that I didn't see constant firing/counterfiring over and over which always makes me want to scuff my feet on the carpet and then touch MechJeb's core.

Obviously

What if both dll's are loaded?

No you can always scale.

Great, but the point isn't whether or not it's iterating over every vehicle in one update as efficiently as it could be. The point is that you don't have to handle every vehicle in one update at all. And with people running into performance issues you should think about throttling things down. Not everyone has a six core or even a quad core. It wouldn't hurt the mod to slow things down even if it meant that a given vehicle only got updated every five seconds.

Can you confirm please that that works for you?

Are you doing every vehicle on every update? An alternative would be to only do one vehicle per update. Each update advance to the next vehicle. Besides spreading the list out over multiple updates you could even do a vehicle every X update. ( where X = 1 out of the number of updates that occur over some TBD period of time)

It should be ok, yeah.

If I'm understanding Ferram correctly and if my math is correct, you could increase it to 110336 (meters). That's about the point that it would reach the other limit Ferram was talking about. (it's when either condition is reached that it stops calculating)

Glad to hear it. What that file is doing in there btw is deleting up to two powerCurves in every part that uses the solar panel module. Then re-inserts the one that RSS uses. The cause of the problem btw is that there end up being two powerCurves in the solar panels. One was supposed to be deleted by the RSS mod (in code) but apparently isn't.... the other is inserted by RSS to replace the first. I'm not sure if the solar panel code is using the wrong one or maybe actually merging them (not literally, probably using both for lookups) So what I did there, it's basically a brute force approach because I'm not 100% sure which node would get deleted. on the RSS forum, it seems it doesn't work for everyone so this version deletes up to two nodes and then inserts another one with the values it needs to work in RSS. Also, unlike the earlier version I did, it doesn't check to see if the panel is producing ElectricCharge on the chance that there's panels using a differently named resource (interstellar mod maybe? I dunno, users of that mod apparently were getting different results from my fix attempts)

Is this during launch? And do you have FAR? If so it sounds like a problem with your ascent profile or rocket design. Or is this after you reach and stabilize orbit? If the latter does it just continue to spin randomly or does it have a particular orientation it tries to reach?

Looks nice. Fits in well with stock parts in style. Centrifuge part looks way too small to accommodate Kerbals though. On the subject of the bigelow type, would you consider doing a larger version? The center section should be the size it is now with the inflatable portion expanding to something like 50%-100% larger than it is now. With an increase in length to keep the same dimensions it has now. In fact ideally the hub (docking port?) and inflatable could be separate models so you could have different sized habs by combining the same two parts in different scales.

No, he said to replace what was IN the stock file. Not to use it in place of RSS power curve. It's no wonder at all that you wouldn't get very much power. Look at the numbers in the power curve. The first one is distance. The second is a multiplier for ElectricalCharge produced. What you just did means you're using stock values while playing RSS. That means that in Kerbin orbit you're only getting the amount of sunlight you'd get if you were over stock Jool. btw, actually editing part.cfg files isn't a real great idea. May I instead suggest the following. Below are the contents for two cfg files. ONLY USE ONE.. Make a cfg file and copy/paste one of the following sets of code into it and save that file. It can go anywhere in GameData folder The first one assumes you are using the latest unmodified RealSolarSystemSettings.cfg Not just the latest version, the latest one. If the first key in powerCurve says something like key = 0E0 238 then you have the latest. If it only says key = 0 238 then re-download. Edit: In fact, the way I wrote out #2 it should actually work regardless of whether your RealSolarSystemSettings.cfg has had its powerCurve deleted. I also tried to bulletproof it a little more than my original version. Also the original only looked for solar panels that actually output ElectricCharge. These versions don't care about that. In fact just go with code #2 for now. RSS.Solar.Fix.1.cfg @PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]]:Final { @MODULE[ModuleDeployableSolarPanel] { !powerCurve{} } } If powerCurve is deleted from RealSolarSystemSettings.cfg use this: RSS.Solar.Fix.2.cfg @PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]]:Final { @MODULE[ModuleDeployableSolarPanel] { !powerCurve{} !powerCurve{} powerCurve { key = 0E0 223.8 0 0//0 -0.5 key = 5.79091E10 6.6736 0 0//-0.5 -0.5 key = 1.08208E11 1.9113 0 0//-0.5 -0.5 key = 1.49598261E11 1.0 0 0//-0.1 -0.1 key = 2.279391E11 0.431 0 0//-.03 -.03 key = 7.785472E11 0.037 0 0//-.01 -.001 key = 5.874E12 0 0 0//-0.001 0 } } }

I don't see anything wrong with what you have so far, but art and style are the main reasons I would become interested in another station pack. There's not a whole lot else present here to express an opinion on.

Having some trouble understanding why you would have to start your landing burn that high. Atmosphere is thicker so terminal velocity is lower. Landing even on thruster only should be easy. Unless you're using FAR in which case, as discussed recently, MJ would have no idea what your drag is. Of course I also know nothing about your ship, its mass or what the TWR is for a poodle and 2 909s as I don't know what other mods were used for this. (example, RSS + MFS could spell trouble for a thruster only landing) I'm not saying there's not trouble with landings btw, just thinking this is a case where stock vs non-stock needs to be separated out. On that subject, I noticed last night that landing (mostly stock, just MJ + KWR) using thrusters and parachute on Kerbin, that MJ2 was firing its thruster too early and constantly while descending on parachute. It shouldn't have fired at all until the final 8 seconds of descent. On parachute it was coming down about 15 m/s and the thruster wouldn't stop firing even when I set the landing speed above 15 m/s.

Just successfully completed two rendezvous and one docking. No real problems except for the usual attempts by MJ to spray as much of my RCS propellent into space in the shortest amount of time possible. At least it's better these days at finishing the docking maneuver.

I've noticed even just adding a dev .dll kills your custom window setups... Edit: not necessarily all the time and maybe not all of them but I've had some go missing and havent had a chance to try to figure out why...

The best you can do really is burn just hard enough to get into Kerbol's SOI and use the intercept option where you get to specify when the burn is done and when the actual intercept occurs. that will get you a decent fast transfer if you have the DV.

Yes, and may I be so bold as to recommend using one of the early Pentium models to handle your math coprocessing needs? Guaranteed to make all your rocketry calculations more memorable.

You'll need to edit your save file. The problem is that that the container has had its required tech changed after you unlocked it. (I dont think Ioncross does that...?) Remove all instances of any item that has multiple tech entries. You'll find these entries in SCENARIO. There will be several groups of Tech with id = <tech_name>, each containing part = <some part> Delete any lines that say part = where the part name is duplicated in more than one tech group. Dont just delete one unless you KNOW which group it belongs in. Delete ALL. Save. If you edited your quicksave, dont forget to load the game. You'll need to unlock one more time since you deleted their unlock nodes. unless you knew which one belonged and didnt delete it but if you were wrong the problem came back so you should have deleted them all anyway.

Well, flip them before they burn. Grease the pan so that they don't stick. Oh, you want to stop them from being made. Ok serious face on. What other mods do you have? Do you have RSS? If so, is it latest version?