blowfish

Those values are the amount of base mass and cost the part should have (per volume) in addition to what the tank adds. But they were mostly just there for for my own reference (and I never bothered to remove them). And they're very approximate values based on stock anyway. But still @Nertea I think your configs might be making the tanks lighter than they should be, since you're using the provided tank types but then subtracting the base part mass. I'm not going to say that you can't include the structural mass in tank types, but you should probably make your own set of tank definitions if you want to do things that way.

CKAN doesn't look at the EXE. It looks at the readme, and at some point in the future may look at the build id.

Just wanted to note a stock issue that seems to be affecting SSTU disproportionately so that no one reports it as SSTU by mistake: Viewing a highlighted part through a transparent mesh (i.e. fairing) may cause the part to become invisible (the part behind the fairing, for as long as it is highlighted). SSTU is heavily affected because so many things have transparent mesh fairings. Bug report here.

Uhh, @Shadowmage, perhaps you forgot to push the changes in 0.4.31-pre2 to Github?

To be honest I have no clue what could be causing this. I have heard that there might be issues with Hyperedit right now, so that might be part of it. E: If you think this is worth investigating you could see if the same thing happens with un-rescaled parts or with stock parts.

Okay, that's odd. Are you just changing rescaleFactor? And for what parts?

Rescaling, as in tweakscale? (1) Tweakscale is not supported with any of the switchable parts (for the moment) and (2) This sounds like a Tweakscale issue.

It's possible the bundled version of B9PartSwitch is for the the wrong prerelease build (nature of things changing so often). I will verify that the latest version works with the latest prerelease build when I get home.

There should not be any duplicate parts. The core pack contains two variants of the new Mk2 styled cockpit, one with an intake and one without. The legacy pack contains one in the old style (this one has a 1.25m node at the front).

@Youen The Isp is higher under 2/3 throttle because it's modeled as an afterburning turbojet with some funky parameters. Is it accurate? No. Have I come up with a reasonable alternative model? I've tried, but alas also no. I might add a parameter in to unify the throttles at some point though.

It works fine with multiple engine modules (assuming they're using different plumes), the problem is that now it's one engine module. I did find a workaround though, and also added an issue in RealPlume's repository (will see where that goes)

It's a different module with different syntax. They can't both be used on the same part, but having both in the same install isn't a problem.

Just a note for everyone, it looks like the way RealPlume is structured doesn't play well with having more than one plume on the same engine, so the engines with separate verniers are incompatible with RealPlume at the moment. This means the RD-107/8, RD-0110, and RS-68. I'm going to log an issue in RealPlume's repository and see where it goes. @GoldForest this is (part of) your issue with the RS-68.

All the fixed wings have been in the legacy pack for quite a while now. It can be downloaded from the same location as the main pack. Not sure what "wingtips" you're talking about. Note that the procedural wings are a separate mod with a separate thread.

Alt+F11 should open up a window titled "Module Manager" (plus some version information) with 3 buttons. Does it not?

Alt+F11 from the main menu or space center -> "Reload Database" or "Quick Reload Database" (the only difference I'm aware of is that quick reload doesn't re-render drag cubes).

No idea really. I think it might add them to determine the ship's size (for runway/launchpad limitations), but I'm not really sure. I just saw that this was one of the interfaces that changed. Yup. These advanced features really only matter if the mass changes on staging, which in this case it doesn't. Should be safe to ignore ModifierStagingSituation and return ModifierChangeWhen.FIXED for these.

These interfaces (used by many mods to set mass and cost) underwent some major changes in build 1209 (quite possibly what caused so many mods to stop working). This is the result of this thread in the issue tracker. The basic idea is that it allows mods which do delta-v or other flight simulations to know how a module's mass might change in flight. As best I can tell, KSP doesn't do anything with these changes directly. In this post, I will try to document these changes, but keep in mind that what's presented here is a best guess based on available metadata, the issue mentioned above, and a couple of conversations on IRC. Will try to update as more information becomes available. The new interfaced definitions are as follows: (definitions generated by Visual Studio from DLL metadata) public interface IPartMassModifier { float GetModuleMass(float defaultMass, ModifierStagingSituation sit); ModifierChangeWhen GetModuleMassChangeWhen(); } public interface IPartCostModifier { float GetModuleCost(float defaultCost, ModifierStagingSituation sit); ModifierChangeWhen GetModuleCostChangeWhen(); } public interface IPartSizeModifier { Vector3 GetModuleSize(Vector3 defaultSize, ModifierStagingSituation sit); ModifierChangeWhen GetModuleSizeChangeWhen(); } The new method GetModuleXXXChangedWhen() informs KSP (or some mod) of how the modifier will change (see enum definitions below with comments added by me) GetModuleMass/Cost/Size() work as before unless the part's mass is supposed to change on staging (i.e. if GetModuleXXXChangedWhen() returns ModifierChangedWhen.STAGED). In that case, it should change based on the staging situation, so that simulations know the correct mass before and after staging. I think that KSP will always pass ModifierStagingSituation.CURRENT when trying to get the correct physics mass in flight (and this is still done every frame regardless). The two enums are as follows public enum ModifierStagingSituation { CURRENT = 0, // Current mass UNSTAGED = 1, // Mass before staging, for sims ... may not be guaranteed to give correct mass after the part has actually been staged STAGED = 2 // Mass after staging, for sims } public enum ModifierChangeWhen { FIXED = 0, // Mass will be set once and never changed STAGED = 1, // Mass will change when staged CONSTANTLY = 2 // Mass changes constantly } Hope that helps a bit...

Hello and welcome to the forums! Please find and upload your output logs - instructions on how to find the log can be found in the first link in my signature. Upload to something like Google Drive or Dropbox, share, and post the link. The logs can usually reveal errors like this pretty quickly.

Probably. I'd look at the configs for the stock radiators.

@5thHorseman I don't think you need a statement there at all. But for future reference yield break will end the enumeration.

@Shadowmage I like having choices, but I've found the MFT/RF tank interface to be quite difficult to work with, so much so that if I actually want to split the tank, I usually end up with separate parts (thus kinda defeating the purpose). Are there any simplifications that could be made? I do have a couple of suggestions there: Create a global or per-tank resource whitelist to limit the number of options you actually see. CRP has quite a lot of resources, and I don't really see the use case for filling a fuel tank with dirt . I think not having to scroll to adjust the common options is critical. Make the common fuel mixtures into actual switchable options. I know that this complicates determining the correct resource amounts ever so slightly, but I think it would improve usability a lot. What if I have a tank that's 90% LFO and 10% Monopropellant, and I want to just it to 95%/5%. Do I need to carefully adjust the LF and O options individually to fill the difference in space? And I apologize in advance, because this is probably going to come off the wrong way, but could you justify to me again why such a complicated switching system is necessary? I know that adding fuel options makes fuel switching a bit more complex, but I fail to see the use case for splitting tanks arbitrarily. The primary fuel/rcs/battery split on the SSTU parts is already pretty good, and UI_ChooseOption actually makes switching a large number of options quite easy and usable.

You have two issues: You are missing ModuleManager. It is required for the community fixes. I believe 2.6.20 is the latest version for KSP 1.0.5 Delete GameData/ModuleAnimateEmissive. This technically won't matter once you fix 1, but it's and old incompatible plugin that should be removed.

Welcome to the forums Please find and post your output log. Instructions on where to find that are in the first link in my signature. After you find it, upload to something like Google Drive or Dropbox, then share it and post the link. It's usually pretty easy to identify errors like this just by looking at the logs.

It's somewhat true in general, but the exact extent varies by engine - in general, the higher the bypass ratio, the less thrust growth you'll see and the sooner it will start to fall off. High bypass turbofans won't see much thrust growth at all, whereas turbojets will keep gaining thrust until the compressor overheats. Well, a lot of the trouble here is that the exact performance parameters are not known (since it's still a mostly theoretical engine). But if you want to increase thrust, modifying the Area parameter is probably the way to go (at least on the SABRE - for other engines there might be other things going on).