NathanKell

@DocUrlaub hey, awesome, glad it's giving you that thrill! RO doesn't support career mode unless you're also using RP-0, so I would expect any number of very bad issues going on there... The name change is intentionally done to the title precisely so that sorting / searching changes. The point is that the part _should_ be marked as apart, because it's going to work very oddly (if it works at all), since it hasn't been patched for RO use. Regarding your specific issue, if you really just want to complete the contract (although see above about career really not working without RP-0!) you can add RSSROConfig = True to the part.

@rgr they have the real stats, so just look up the real engines?

@curtquarquesso it's on my list.

@Padishar blargh you're absolutely right, I totally misread. :]

Uh, not sure what you're trying to do with the second part; the first part is what actually enables surface crossfeed, PartResource doesn't have any fuelCrossFeed property.

Can you post a picture of your craft in the VAB, with MechJeb's Delta V stats window open and it set to show all columns? I really don't think the issue here is TestFlight...

@Ultimate Steve um...I'm unclear on what's going on here. What do you mean by "too fast"? Fast is good! Do you, like, not have an upper stage and/or payload on the rocket?

Don't ever try to use the atmospheric delta V columns. They really aren't helpful. You need to know your liftoff TWR (the SLT column in MechJeb) for the first stage, but everything else should be vac.

You have a serious install issue if your launchpad limit is 140 tonnes. RP-0 limits are 40 tonnes, 800 tonnes, and unlimited. Or are you trying to play career without RP-0? That is not going to work and is very, very much unsupported.

@tomek.piotrowski welcome to the forums! Great to hear you're getting involved in RT, and RT is in progress again!

Let's go through it then: 1. You're iterating over all parts in the vessel. 2. Given a part, you then see if its list of PartModules contains a partmodule named ModuleDeployableSolarPanel (note: this method is not safe, better method is what I proposed*) 3. If the part does have such a module, get it by finding the first module in the part of type ModuleDeployableSolarPanel 4. Finally, call that panel's method. *This is not safe because, as my description above hopefully showed, the code is doing two different things. First it's finding if the part has a module that explicitly is (i.e. its type matches the string) ModuleDeployableSolarPanel. Next, however, you are finding a PartModule that is or is derived from that type. Since presumably you want to handle panels on modules that are derived, not just are, it's better to use the type form rather than the string form. However, it's even better to do a foreach(ModuleDeployableSolarPanel pan in eachPart.FindModulesImplementing<ModuleDeployableSolarPanel>().ToList()) and then pan.Retract() The reason for that is it will do it to all partmodules of (or derived from) that type on the part, not just the first. And the reason for the ToList() is that otherwise it will re-run that Find... method each time the foreach executes (IIRC) rather than only once.

@Oksbad what kind of reentry are you making? Some heat shields only survive low-velocity LEO reentries, not anything more.

or even just foreach(Part p in vessel.Parts) { var panel = p.FindModuleImplementing<ModuleDeployableSolarPanel>(); if(panel != null) panel.Retract(); } that means you only search the modules once per part.

@John FX http://www.braeunig.us/apollo/saturnV.htm

The TAC stuff should still be correct, PartModules haven't changed enough, and that'll still even work in 1.1 although you might need to reference more KSP dlls (KSPUtil and KSPCore, say). Making that menu should be fairly straightforward. You'd make a partmodule (and use ModuleManager to add it to all parts that have the solar panel module). The module would have a KSPEvent (active only in flight?) that loops through all parts on the vessel, and all modules on each part, and if it's a solar panel, calls the deploy method in the panel.

@Matuchkin that is from the 8192s. 6317km radius * 2 * pi / 8192 = 4.88km/pixel.

@Matuchkin Heightmap resolution is about 5km x 5km per pixel at the equator, so islands smaller than that are unlikely to show up. Anything that size or larger should show up, however, and at higher latitudes the resolution improves.

@Shadowmage It worked just fine--quotes / tags edited in later still pop as notifys. (As I just proved by forgetting to tag you at first )

@Shadowmage you ever post that issue?

Yes, it's being updated. regex is doing some work himself, because he's super generous like that

This sounds like you might not be in KSP 1.0.5 with the right mods. It will be fairly near its maximum temperature but should not explode. Also, have you updated any mods recently? There are some issues with CKAN and 1.1 mods going into 1.0.5....

Just don't have the module at all.

As @berkekrkn says, not all tanks can hold all resources. To hold a highly-pressurized resource like hydrazine, you need a highly-pressurized tank. Starting out in career mode, the only tank of that type is Fuselage; later type ServiceModule becomes available as well (it's a bit more expensive but rather more efficient).

To be clear, just because it's hard doesn't mean we're not going to work on it. I don't believe our prior statement of "it's coming" has ever been rescinded, and I certainly would like to see it in (and therefore would probably get drafted ). Also, Jim's planning to rework resource flow for the next update (per dev notes) and that really goes hand in hand--indeed, that those things are so tied together, and tied to the burn indicator, is the main reason I didn't try to fix the burn indicator for 1.1, it'd be wasted effort. Now, on the "harder than it looks" front, let me give a quick example on why it's not merely hard, but also a question of design assumptions rather than just "getting it right." Let's consider hot-staging. Here's a simple staging stack interstage Decoupler upper Engine lower Engine This stack involves firing the upper stage's engine shortly before decoupling. Now, it's interesting to note that MJ and KER handle this case differently. KER says "OK, we'll stage and then burn the lowest stage until it flames out, then stage and burn the next stage until it flames out, then do all that one more time." This results in its sim thinking the upper stage engine burns all its propellant with the lower stage still attached. Mechjeb, by contrast, will always stage if the next stage will not make things worse, so it will assume that decoupler is staged immediately following upper engine ignition. Now, in the case of hotstaging in RO, MechJeb's assumption is correct. However, in other cases where one has a staging setup like this, its assumptions may well prove incorrect. See the issue? :]

More the merrier I guess. Whoops. :] @regex You know it!