Alshain

Nice, I'll keep an eye out, and thank you very much.

I'm having an issue where no matter how big my maneuver is, the half-burn time is always 0, and Time to Node and Time to Node Burn are identical. Any ideas how to resolve this?

Precisely, Kerbal engineer already does this (though in testing BBT, I found it appears to be bugged) it's basically a countdown timer to Time to Node - 0.5 * Burn Duration (I think KER is a little more precise than that though, it takes other items into account, like fuel mass reduction during the burn). I can just keep using KER if it gets fixed, it's just my KER HUD is so long, and I'm always looking for ways to shorten it and make it less distracting and more stock alike ;). This mod will help me get rid of a few items even with out that.

Is there not way to tell you the flat time to burn, like Kerbal Engineer does (like a half burn time)? I love the way this tucks away neatly next to the NavBall, I was hoping to be able to shorten my Engineer HUD list a bit.

I had no idea! That is fascinating.

If you think you have a bug, it is best to report it on the mod thread. However, yes, you usually have to wait for a patch.

Ok, here is the new version. It should work, however I did discover a bug during my final testing. If you are playing with the option to unlock parts/upgrades with funds, that is ignored, the upgrade is available the moment the tech tree node is researched. https://www.dropbox.com/s/4uz85bptzifw2o8/PartUpgrade_beta_v0.5.1_recompile2.zip?dl=0

@Streetwind So, interestingly there was a VersionChecker script throwing an exception error and apparently that somehow shut down half the mod. I'm not clear on how that was happening, part of the mod was clearly functional in the tech tree, but I nuked the version checker and it works completely now, as far as I can tell. I'm preparing an upload now.

Hmm, yeah I concur.

It looks like you aren't adding the part to the TechTree, from what I can tell is is done in a separate node. Here is Merill's config for the LVT30. Pay close attention to the first PART node that begins with +. So what he does is he precedes the part node with @PART to modify the initial stats of the part (when you first unlock) and uses +PART to add a stub to the tech tree that will enhance the part. ////////////////////////////////////////////////////////////////////// // Example of ModuleManager conf to upgrade LV-T15 with UpgradePart // Author : Merill // Licence: CC-BY-SA ////////////////////////////////////////////////////////////////////// //stub part to show on the tech tree but not in the vab. +PART[liquidEngine] { //new name, title & descrioption @name = liquidEngineStubGeneralRocketry @title = LV-T30 Upgrade num 1 @description = Reduce the mass to 1.5t, increased the heat resitance to 1200°K, improve the isp by 20-30 and the thrust of the engine by 15. Add also an alternator. //select tech node @TechRequired = generalRocketry //do not show in vab @category = none //add all upgrades @mass = 1.5 @maxTemp = 1200 @cost = 1000 @MODULE[ModuleEngines*] { minThrust = 0 @maxThrust = 215 @atmosphereCurve { @key,0 = 0 310 @key,1 = 1 260 } } @MODULE[ModuleAlternator] { @RESOURCE[ElectricCharge] { rate = 3 } } } +PART[liquidEngine] { @name = liquidEngineStubAdvRocketry @title = LV-T30 Upgrade num 2 @description = Reduce the mass to 1.25t, increased the heat resitance to 1500°K, improve the isp by 20 and the thrust of the engine by 15. Improve also the alternator and add a gimbal module. @TechRequired = advRocketry @category = none @mass = 1.25 @maxTemp = 1500 @cost = 900 @MODULE[ModuleEngines*] { minThrust = 0 @maxThrust = 230 @atmosphereCurve { @key,0 = 0 330 @key,1 = 1 280 } } @MODULE[ModuleAlternator] { @RESOURCE[ElectricCharge] { rate = 7 } } } +PART[liquidEngine] { @name = liquidEngineStubHeavyRocketry @title = LV-T30 Upgrade num 3 @description = Reduce the mass to 1t, increased the heat resitance to 2000°K, improve the isp by 20 and the thrust of the engine by 20. Improve also the alternator and the gimbal module. @TechRequired = heavyRocketry @category = none @mass = 1 @maxTemp = 2000 @cost = 800 @MODULE[ModuleEngines*] { minThrust = 0 @maxThrust = 250 @atmosphereCurve { @key,0 = 0 350350 @key,1 = 1 300 } } MODULE { name = ModuleGimbal gimbalTransformName = thrustTransform gimbalRange = 1 useGimbalResponseSpeed = true gimbalResponseSpeed = 5 } @MODULE[ModuleAlternator] { @RESOURCE[ElectricCharge] { rate = 10 } } } //Here, modifying the LV-T15 part @PART[liquidEngine] { //initial values for mass, maxttemp, alternator and engine lower than default @mass = 2 @maxTemp = 1000 //remove this module, it's added in an upgrade. !MODULE[ModuleAlternator]{} @MODULE[ModuleEngines*] { minThrust = 0 @maxThrust = 200 @atmosphereCurve { @key,0 = 0 280 @key,1 = 1 240 } } //module to upgrade the mass //if multiple tech in the list have been researched, the only one used is the last in this list. // when a vessel load, this module restore his last mass (because it shouldn't upgrade) MODULE { name = ModuleUpgradeMass //if you have problems with data persistance, you can set this field to false, to make part in flight magically upgrades when you research a new tech. //persitance = true //default true //list of techName / value to set TECH-VALUE { generalRocketry = 1.5 advRocketry = 1.25 heavyRocketry = 1 } // example: if generalRocketry and heavyRocketry are researched, The lv-t15 mass value will be the one of heavyRocketry because it's below in the list. } //same as the mass, but change the max temp value MODULE { name = ModuleUpgradeMaxTemp TECH-VALUE { generalRocketry = 1200 advRocketry = 1500 heavyRocketry = 2000 } } //same as the mass, but change the cost value MODULE { name = ModuleUpgradeCost TECH-VALUE { generalRocketry = 1000 advRocketry = 900 heavyRocketry = 800 } } //module to upgrade engine (in a more easy way than ModuleUpgradeModule) MODULE { name = ModuleUpgradeEngine //Here, it's a list of an other type of "TECH-VALUE" // each TECH-VALUE node contain an upgrade at a tech level. // like ModuleUpgradeMass, only the last researched is taken. TECH-VALUE { tech = generalRocketry // the min/max thrust is considered with vaccum isp => it give the min/max fuel flow. minThrust = 0 maxThrust = 215 atmosphereIsp = 260 vacuumIsp = 310 } TECH-VALUE { tech = advRocketry minThrust = 0 maxThrust = 230 atmosphereIsp = 280 vacuumIsp = 330 } TECH-VALUE { tech = heavyRocketry minThrust = 0 maxThrust = 250 atmosphereIsp = 300 vacuumIsp = 350 } } //this module is designed to upgrade other modules //It's more compicated, and maybe i change it in a future day. // right now, you should create a new module for each type/tech combinaison // note: Please, do not add multiple module with the same name to your part, i can only upgrade one of them. MODULE { name = ModuleUpgradeModule //module upgrade type : create, replace or delete. type = create //tech needed to apply this upgrade tech = generalRocketry //If you want to use multiple ModuleUpgradeModule on this part with the same type/tech, add this field with a unique int id //id = 144124 //add all modules to [add|replace|delete] here. As it's defined in a normal part. MODULE { name = ModuleAlternator RESOURCE { name = ElectricCharge rate = 3 } } } //if you want to upgrace a upgrade-created modle, it must be place AFTER the creation one. MODULE { name = ModuleUpgradeModule type = replace tech = advRocketry MODULE { name = ModuleAlternator RESOURCE { name = ElectricCharge rate = 7 } } } MODULE { name = ModuleUpgradeModule type = create tech = advRocketry //In ModuleUpgradeModule, vessel-persisted fields must have a type in {primitif | string | vector[3|3d|4] | Color[32] | Matrix4x4 | Quaternion[D]} // other fields are ignored. //persitance = true //default true MODULE { name = ModuleGimbal gimbalTransformName = thrustTransform gimbalRange = 0.5 useGimbalResponseSpeed = true gimbalResponseSpeed = 2 } } MODULE { name = ModuleUpgradeModule type = replace tech = heavyRocketry MODULE { name = ModuleGimbal gimbalTransformName = thrustTransform gimbalRange = 1 useGimbalResponseSpeed = true gimbalResponseSpeed = 5 } //you can upgrade multiple modules MODULE { name = ModuleAlternator RESOURCE { name = ElectricCharge rate = 10 } } } }

@Streetwind That is unfortunate, have you tried more than one module? Is there a specific module you tested? I wish I knew more about how the mod was supposed to work. The code is very well organized, and decently documented. EDIT: It doesn't appear in the tech tree at all? I installed it with some older demo configs included with the source and I am seeing them. You might double check there are no errors in the configs.

The problem here is it doesn't know where to put the stages. Your subassembly could be a lifter, or it could be a payload. One would add the stages at the end of the stack and the other at the beginning. So instead it tries to put them in the original staging order from where it was saved. However, if you have something there, it gets mixed. The way I tackle this problem is simple. In the subassy description, I list the number of stage groups (see picture). Then I add blank stages BEFORE attaching the subassembly. The works fine for lifters, but may not quite work as well for payloads. I don't know a better way for that. As far as what Squad could do, I do think it should NEVER mix. It should always create the stages somewhere, even if they are in the wrong place, that is better than being mixed.

The problem there is you will run up against the realism folks. Planes in the early space programs had ejection seats, they didn't eject their whole cockpit off the plane. Not only would that look ridiculous and IMO make the plane incredibly ugly, but it simply isn't real. Perhaps, only the Mk1 and maybe Mk2 should have them, neither the STS or Buran had ejection seats, as far as I know the DreamChaser will not either.

Good news, that part has already been implemented, it's called quicksave

I've used constellations and also names (or partial names) of nautical ships before. My planes are usually birds. Where are the puns?

Thanks for all the hard work!

Literally, yes. Reasonably, no.

I think 3 of each is extreme. A 0/18 runway would be nice for polar launches but, a separate launchpad for polar launches isn't really needed a rocket starts by going straight up and can turn any direction it needs to. Your '90 Degree' runway is mislabeled, that is a 0/18 runway (i.e. 0 degrees/180 degrees) the one we already have is a 09/27 (i.e. 90/270). That's what those numbers painted on the runway mean. Real airfields, like my hometown commuter airport have runways because of wind. Craft can be redirected to a more favorable approach. For KSP there is no wind, though taking off on polar would still be a good idea.

Well there is a small apron outside the SPH. I mean, I wouldn't expect it to be a international airport. Just, turning a large plane around on the runway is a PITR EDIT: Don't get me wrong though, a 0/18 runway would also be very nice. I don't know that we need 3 of them, or 3 launch pads, that may be a little extreme.

I'd settle for the runway to have a proper taxiway lol.

You probably have some controlling part that is upside down. A probe core, a command pod, or even a docking port that you are controlling from it's perspective. Right click your command pod and click "Control From Here", if that doesn't work, the part itself is upside down.

ROFL. There is no telling what would or would not be affected by that bug. It's bug, they are unpredictable. How do you know a decoupler would work?

The stock docking ports are decouplers that will allow crew transfer in CLS.

Another way is to load the craft in a stock copy of the game. It will tell you which parts it doesn't recognize.

If you haven't tried it, it's pretty simple. You can't get landers on the ground, you can't planes off the ground, and you can't get rovers to drive. You can still build stations though, so that's something I guess.