Starwaster

That's what I was afraid was going to happen. That's crazy, what were they thinking slashing the density of rocket parts like that when the mod requires that you have at least the tonnage of the built craft in spare parts... plus an additional percentage.....

Correct. The Kerbals have vast numbers of flags in their command pod. VAST NUMBERS. (i.e. unlimited) (stick a fork in this thread, because baby, it's done)

release notes?

Oh, any chance of spherical tanks that don't have the cap on top? So we can have them totally rounded?

FYI, the rescale command isn't linear... or something. Crap, I'm not clear on details and I forget, but you have to use the square root of the desired scale or square the desired scale (huge difference, sorry, I forget!) There's a thread around here somewhere that tells all about it, search for it. To give an example, I wanted to turn one of Tal's hemisphere tanks into an rounded cap for other fuel tanks. It was the medium sized (3.75) originally and to get the cap to fit on a 3.75 tank I had to do THIS: MODEL { model = ModsByTal/Parts/FuelTank/TAL_HalfSphericalTankMedium/model scale = 1.1180339887498948482045868343656, 0.25, 1.1180339887498948482045868343656 } scale = 1 rescaleFactor = 1 Go ahead and give that a try and see what it looks like in-game. Actually, looking at that number now, it doesn't look like the square of 3.75 at all so I don't even know what size I was going for. But it does fit! Something...

omg would a mod please close this

Yeah, it got me too. So, now, instead of feeling bad about yourself you can point and laugh at Starwaster

Test results are: ModularFuels working as expected. IonCross being added to everything with CrewCapacity, but it's also resulting in IonCross being added twice to some items, where it's being added from other config files (such as IonCross itself) Looking at the log it actually appears that my config is being applied first so I'm going to assume here that the conditional is working properly and that the other configs just have no means of knowing that IonCross was already added. Do you know if file name has any bearing on execution order? Or do I need to use the :Final keyword to make mine execute last? Edit: The problem with extra IonCrossCrewSupport modules persists. I even tried keyword :Final, but it doesn't look right. Ordinarily, it would appear as Part[PartName]:Final Looking at the config that I have, I'm not sure that's going to work as I don't know how this is going to end up looking internally by the time your plugin and ModuleManager get done parsing... Here's an example of what I'm using: @PART[*]:HAS[!MODULE[IonModuleCrewSupport],#CrewCapacity[1]]:Final { MODULE { name = IonModuleCrewSupport } RESOURCE { name = Oxygen amount = 100 maxAmount = 100 } RESOURCE { name = CarbonDioxide amount = 0 maxAmount = 10 } }

**** yeah flying rovers! Where's the rest of the video?

I weep for what could have been. kkthxbai

That wasn't me 'starting with'; that was me revisiting. Perhaps you just missed the other times. And you don't need to worry about the other fuel types. That's not an issue; MFT takes care of that. It might even take care of the basemass by itself if it weren't getting set; I'm not certain. Assuming it cannot, isn't is possible to retrieve the basemass value from the tank definition nodes? Set it based on that. Failing that, do what I suggested a few posts ago and cut it to 20% of what you're setting it to now

I was always using the RCS balancer and never noticed it to do what you describe. In the most recent updates (maybe just Sarbian's not sure) I had to turn that off along with all other RCS related settings to correct other docking issues. Maybe I'll try it again now that things are working better in these last few updates.

Suggestion: Treat 0.0 speed limit to literally mean 'no faster than 0 m/s' That would effectively allow the player to hold station outside the docking port Argh not sure why Aurelius quote is there... maybe I meant to reply to him earlier. Maybe I did reply to him? I think maybe I did... yeah I think I told him that you CAN have MJ2 totally partless. That must be it.

Sorry for the delayed response. I tried the patched ModuleManager.dll and I have good news and bad news. Good news is that my IonCross patch worked and I was able to add life support to all parts with crew capacity 1-6. The bad news is that most of my Modular Fuel Tank config files stopped working. (actually all MFT fuel tanks and engines stopped working; they reverted back to stock. Only MFT patches that I had created continued to work) I had to restore the original ModuleManager.dll file to resture MFT to functionality. I don't know what to do with this at this point. When I have time I'll create another KSP folder with no mods except ModuleManager, your extensions and Modular Fuel Tanks installed so I can trouble shoot the problem better. That will eliminate any issues with other plugins and decrease my load times so that I can shut down and restart KSP without 5 minute load times.

See original post, I edited. And, I only mentioned editing the files as an attempt on my end to fix the problem. Summary: It's modular fuel tank specific. MFT does basemass + (additional tank mass based on fuel type per tank). Base mass is only a fractional amount of the final tank mass In the end, for stock fuel types it works out to the same as it would for a stock tank. But you're assessing full tank mass against it up front just for the base mass. It's about 5 times too massive and then it's throwing additional tank mass on top of that. To summarize the summary. Scale back the basemass to 20% (x0.2) and it should be fine. Finally, I'm only trying to help you here. That infinite fuel crack is a little insulting. It was unnecessary.

If you don't want to make this 'better than stock' that's fine I agree that you shouldn't, and nobody's arguing that you should (unless I missed something above). But regarding whether or not volume is deriving from tank mass, you've got both volume and final part mass (dry) linked to the same constant. That it's in two different equations doesn't matter, volume is deriving from mass in a way that can't be altered. If I have a stretchy tank whose dry mass is 5 times a stock tank of identical dimensions and volume, I can't fix that on my side.. Change the mass constant and I slash my tank's volume. And it's not like I'm trying to 'cheat' (hate that word in a sandbox game) here, I'm just trying to get a tank whose mass is in line with existing tankage and that doesn't murder my delta-V and thrust. Edit: The problem is specific to modular fuel tank compatibility implementation. First: Definitely (for MFT at least) explicitly basing volume from mass. if (part.Modules.Contains("ModuleFuelTanks")) { PartModule moduleFuelTanks = part.Modules["ModuleFuelTanks"]; [B]moduleFuelTanks.GetType().GetField("volume").SetValue(moduleFuelTanks, part.mass * 1600);[/B] moduleFuelTanks.GetType().GetField("basemass").SetValue(moduleFuelTanks, part.mass); foreach (PartResource resource in part.Resources) { part.Resources.list.Clear(); } } So that's our base mass before the mass of any other MFT tanks are installed. MF has no way of knowing that its mass calculations have been usurped. If you don't want to change how mass and volume are handled, fine, but at the very least you should scale the basemass down. I think scaling basemass by 0.2 (down to 20%) should cover it. To better illustrate the problem, consider: The way MFT does its mass calculations, you end up with a basemass that's a fairly small fraction of your final mass. Then add additional mass per tank based on the fueltype. (MFT still handles that, so it's just the basemass we need to worry about) For Liquid Fuel and Oxidizer final mass works out to be the same as stock for a default tank. Let's take the big orange tank for instance. Stock tonnage 4 tons. volume 6400 MFT does the mass as 6400 * 0.000125 = 0.8 basemass 6400 * 0.0005 = 3.2 liquidFuel + Oxidizer (both have a multiplier of 0.0005 so I'm just doing them as one lump calculation here) Final tonnage is 4 tons just as in stock. If I take a stretchy and scale it to have exactly 6400 I'll end up with 4 tons basemass (just as it would be in stock) Plus 3.2 tons as above for the LF / OX tanks. 7.2 tons. With a Mainsail engine that gets me a loss of 10% of my delta-V when using a stretchy tank. MFT w/Mainsail 4,386 m/s Stretchy 3,949 m/s

other feedback: Sarbian, speed limit needs to either use the absolute value or prohibit negative number entries

The download needs to be cleaned up. There are about half a dozen dll files in there that don't need to be there and ksp will try to load them.

docking feedback: Wow. huge improvement. I do see some thruster usage that I consider unnecessary but since overall usage is hreatly reduced, it might be within acceptable limits to me. More research needed. I've been wanting a more aggressive docking autopilot for awhile and now it's here. In fact it scared me to watch it in action. Might be best to have it back up a little more and it doesnt have necessarily have to face the dock to move away from it. The circumstances under which I tested it were atypical however. In an actual docking scenario I would try to set the situation up better. the scenario I threw at it involved a slightly unbalanced RCS and I asked it to dock at a port 5 meters further 'up'. procedure was undock, set control from port, target other port, autodock. AP backed away a little Translated 'upwards' with 2 second burst while still backing away. balance issue caused the nose to pitch down MJ stopped thrust and reoriented to the port. slowed craft moved forward and docked. I didnt realize it was a balance issue I was seeing at first because the craft is mostly balanced . It just looked like AP turned the pod to back up into the target port axis. I.E. it seemed deliberate but instead what happened was that as it lost port alignment it stopped RCS action and reoriented to the port. In short, it was a case where unbalanced RCS helped it dock even though it was unintentional. advice to those trying this new docking AP, leave speed limit at 0.1 until you're comfortable with it because it's alot faster using the default valu than it used to be.

the whole mass-volume thing isnt how it should be handled, getting volume from mass isnt the way to go

Will it use less RCS fuel? I've got to the point that I have to turn on unlimited RCS every time I use autodocking and I hate doing that. ModuleManager. Every single one of my capsules and cores is MJ2 equipped and not a single one of their .cfg files edited.

Has anyone had any problem after attaching the 16,000 capacity kethane tanks radially to other tanks and then filling them with kethane? Does anyone know if the ridge on that tank has a collision mesh associated with it? (extending the collision body essentially to cover the ridge)

You're pulling that out of output_log.txt right? All I see in there relating to your plugin and my config is: Config(@PART[*]:HAS[!MODULE[IonModuleCrewSupport],#CrewCapacity[1]]) MyTweaks/ioncross_for_everyone/@PART[*]:HAS[!MODULE[IonModuleCrewSupport],#CrewCapacity[1]] (Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54) Config(@PART[*]:HAS[!MODULE[IonModuleCrewSupport],#CrewCapacity[2]]) MyTweaks/ioncross_for_everyone/@PART[*]:HAS[!MODULE[IonModuleCrewSupport],#CrewCapacity[2]] (Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54) Config(@PART[*]:HAS[!MODULE[IonModuleCrewSupport],#CrewCapacity[3]]) MyTweaks/ioncross_for_everyone/@PART[*]:HAS[!MODULE[IonModuleCrewSupport],#CrewCapacity[3]] (Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54) Config(@PART[*]:HAS[!MODULE[IonModuleCrewSupport],#CrewCapacity[4]]) MyTweaks/ioncross_for_everyone/@PART[*]:HAS[!MODULE[IonModuleCrewSupport],#CrewCapacity[4]] (Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54) Config(@PART[*]:HAS[!MODULE[IonModuleCrewSupport],#CrewCapacity[5]]) MyTweaks/ioncross_for_everyone/@PART[*]:HAS[!MODULE[IonModuleCrewSupport],#CrewCapacity[5]] (Filename: C:/BuildAgent/work/7535de4ca26c26ac/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54) Config(@PART[*]:HAS[!MODULE[IonModuleCrewSupport],#CrewCapacity[6]]) MyTweaks/ioncross_for_everyone/@PART[*]:HAS[!MODULE[IonModuleCrewSupport],#CrewCapacity[6]] I'm using the same conditionals you are.... guess I better go check plugin versions. ModuleManager is the latest though, he hasn't updated it in awhile Edit: It shouldn't matter where in GameData the dll lives; it's clearly loaded. But where did you put yours?

Just to touch on this from my perspective, I don't use the MJ part and have not in quite some time. The MechJebCore module is built into all of my command modules and probe cores. I haven't had any problem (aside from MJ's standard docking flakiness) since I turned off RCS fuel conservation and conservation thresholds....

This doesnt have Pauly Shore inside does it?