hemeac

@Croquedure and @The Flying Kerbal, I was reading about LADEE recently which I think is relevant to your comments about the Mun "dust storms" in AVP: https://www.nasa.gov/ames/ladee "The LADEE mission revealed that tiny meteoroids contribute to the Moon’s exosphere, including by delivering it water. Like bugs on a car windshield, these grains of rocky material traveling through space pelt the lunar surface almost constantly as the Moon makes its way around the Sun. On Earth, they burn up in the atmosphere as meteors, but with the almost negligible atmosphere on the Moon, the particles smash into the surface with tremendous speed. Although the grains are mostly smaller than the head of a pin, they can hit at speeds greater than 21 miles per second, releasing immense heat and vaporizing part of the soil and the meteoroids themselves. The resulting gases can then enter the lunar atmosphere. When the number of these impacts went up – for instance, if the Moon passed through a relatively dense stream of micrometeoroids – LADEE’s instruments recorded a corresponding increase in certain gases in the exosphere. Researchers used that data to study what the fate of these additional materials might be: Would they fly off into space? Or, heated by the Sun, would they hop around the lunar surface? ... Addressing a longstanding mystery from the Apollo era was also on LADEE’s to-do list. Astronauts in orbit around the Moon reported seeing a glow on the horizon before sunrise. One possible explanation was that lunar dust, electrically charged by the Sun’s ultraviolet light, was levitating above the surface. However, the spacecraft’s instruments found no evidence of any effect that could be seen by the human eye. "

Really like the layout of the tree. I think FFT when out of the beta should play nicely with all of the near future mods. Also congrats on your soon to be 2000th post.

Kiwi Tech Tree 0.9.7 (Github) General Upgrade System framework implemented; supported configs will now indicate the location of the part or system upgrade (in the majority of cases). Upgrade for parts updated in about 1/3 of supported mods Engine Ignitor Configs courtesy of @Clamp-o-Tron Bug fixes for BDB and Kerbalism (BDB does not have support in the tech tree, it just will not currently cause errors due to patches with KTT; note that there are still errors arising from issues between BDB and Kerbalism) This was a fairly large update to add some general upgrade templates to KTT. They have been applied to some, but not all mods. Just wanted to see if they would cause conflicts with any setups before continuing to push too far ahead, so if you test this, please let me know with any log files and mod list to help narrow down issues. One known issue is an issue that nuclear engines are not able to show vacuum stats within B9 detailed description. I do not know why they are failing in those engines and just those values. The issue does not appear to be impacting the engine performance itself. I have placed some placeholder text in the B9 description so you should not experience MM errors. If you are an expert in MM syntax and have some time to help diagnose, would love to hear from you. There were some files that were deleted from the last release due to changes in the patches, so please delete the entire folder if you are re-installing.

RTB has a longer post in the bleeding edge thread, but he's been working on code for the comet system and fixing an old issue with solar flux that impacts saves with multiple suns. Think the latter is also present in 1.9.1 as well.

I've been working a probes first style mod that adds parts upgrades and some part balancing. Still testing, but @Clamp-o-Tron has been starting to explore some ideas on contracts. If you haven't started your game yet and want to give it a quick test and report any issues, would definitely appreciate. If my tree is not to your style, Unkerballed Start would be a good start, but there is also theJesuit's Tetrix which also does a more compact overhaul. I haven't personally tried Tetrix, but think it is worth checking out.

You can find it here:

There is some work on a standalone beamed power plugin, that may fall closer to scope there? https://spacedock.info/mod/2492/Beamed Power Plugin

I realized the importance of this as I was starting to forget where I placed the upgrades as more parts were added.

I've added some patches that add in the tech tree node that the upgrades are located in. Think this is a bit easier to use than the generic "This part has upgrades!" text currently. I do not think I am able to pull in the title of the tech tree nodes using MM patching without hard coding in the locations of the upgrades. Think this hits a good enough balance.

That's a pretty good space saving in the last version

These look great

You will need to make sure to set the permission on the file so it is visible, I can't access the log file currently. If the log spam was from Kopernicus, that may have been a separate bug, but think @R-T-B has fixed that in an updated release

No, but there is a new version of the bleeding edge out that has the fix, so that may be better to get at this point.

Thanks! @Clamp-o-Tron has volunteered for BDB. Don't envy that task, BDB is a constantly evolving mod :-) Just a quick general update. Have been working on some behind-the-scenes work to make the workflow faster in the long-run by standardizing some of the upgrades. This is due to some feedback from github user T10a who suggested some of the hydrolox upgrade values were a bit too high. I am generally ok with them at the moment, BUT thought it was an opportunity to allow users flexibility in making that choice for themselves. The general config framework (this extends further, so just an illustration): KIWI_ENGINE_MULTIPLIERS { KEROLOX // This is for standard and Aerospike LF/O Fuel Engines { THRUST_MULTIPLIER = 1.2 // This gives the engine 20% additional thrust when upgraded. ISP_MULTIPLIER = 1.1 // This gives the engine 10% higher specific impulse when upgraded. UPGRADE_ENTRYCOST_MULTIPLIER = 1.5 // This is the cost multiplier for the upgrade relative to the original entry cost of the part. UPGRADE_COST_MULTIPLIER = 0.5 // This is additive, so upgrades engines cost 50% more than baseline UPGRADE_MASS_MULTIPLIER = 0.1 // This is additive, so upgrades engines have 10% more mass than baseline } // Kerbal Atomics adds a dual-mode for NERV, but I will not separate out the multipliers NUCLEAR // This is for standard NERV Nuclear Engines { THRUST_MULTIPLIER = 1.2 // This gives the engine 20% additional thrust when upgraded. ISP_MULTIPLIER = 1.1 // This gives the engine 10% higher specific impulse when upgraded. UPGRADE_ENTRYCOST_MULTIPLIER = 1.5 // This is the cost multiplier for the upgrade relative to the original entry cost of the part. UPGRADE_COST_MULTIPLIER = 0.5 // This is additive, so upgrades engines cost 50% more than baseline UPGRADE_MASS_MULTIPLIER = 0.1 // This is additive, so upgrades engines have 10% more mass than baseline } } We tag engines that will get an upgrade: @PART[liquidEngine3_v2]:FOR[KiwiTechTree] // LV-9090 "Terrier" { @TechRequired = advRocketry @entryCost = 5000 @cost = 750 engineUpgradeType = standardLFO engineNumber = 909 engineNumberUpgrade = 969 engineName = Terrier engineNameUpgrade = Maltese enginePartUpgradeName = terrierUpgrade } And a later pass applies those values into a B9 Part Switch: // Standard LFO Engine Upgrade @PART[*]:HAS[#engineUpgradeType[standardLFO]]:FOR[zzKiwiTechTree] { // Add these here without % or @ so they can be manually overriden by individual parts if required thrustMultiplierConfig = #$@KIWI_ENGINE_MULTIPLIERS/KEROLOX/THRUST_MULTIPLIER$ ispMultiplierConfig = #$@KIWI_ENGINE_MULTIPLIERS/KEROLOX/ISP_MULTIPLIER$ costMultiplierConfig = #$@KIWI_ENGINE_MULTIPLIERS/KEROLOX/UPGRADE_COST_MULTIPLIER$ massMultiplierConfig = #$@KIWI_ENGINE_MULTIPLIERS/KEROLOX/UPGRADE_MASS_MULTIPLIER$ ... } I've pushed an update to Github which has applied this to Stock + AirplanePlus. Will be going through and adding this framework the supported mods over the next week or so to allow more consistency in the experience.

Having introduced the bug, I felt obliged to try and actually fix the issue. Hopefully this will be the final pass,

When I was reading your previous post about corrosion, I was reminded of the rust/dirt maps used by Transport Fever to indicate the spots that the vehicles start to show their age over time. https://www.transportfever2.com/wiki/doku.php?id=modding:resourcetypes:mtl

I don't think I have ever been more excited for a release!

I had seen a couple reports in the BDB thread about some issues with Kerbalism, so I think that might be the culprit, looking through your log file, it appears to be throwing an exception on the solar panels that have multiple variants such as the OAO.solarUpper part. Nothing to see here...

There is no copy protection on KSP, so you can create a copy of it and place it elsewhere on your computer to run. That would give you a safe version to try adding OPM and Kopernicus without impacting any of your main saves.

I did a test this evening and that seems to do the trick and have sent the patch to @R-T-B to review. It came down to the fact that the Kopernicus patch looks to ensure that B9 switch in the Near Future Solar parts can find the kopernicus solar module, but was defined too broadly so would flag any module that has SolarPanel in it's name. It turns out that KSPIE adds a module to all solar panels called FNSolarPanelWasteHeatModule. B9 didn't know which module to patch so it threw an exception and you got the popups. I am not sure what would happen in that situation as I didn't test, but I am guessing you would always get the default advanced charge rate and the basic and concentrated variants would still default to the same values.

@JcoolTheShipbuilder, the fix to your issue should come for the next Kopernicus Bleeding Edge update, but if you are comfortable editing cfg files in a text editor, you can go to line 42 of Kopernicus/Config/SolarPanels.cfg and change the line to: @name = KopernicusSolarPanels

You can take a look at two posts above yours, but the short answer is, it sort of does, but I wouldn't use it in a save game that matters yet in JNSQ.

Did you end up getting explicit permission from Nertea to re-distribute the deprecated parts? He has released those originally as an all rights reserved license so if you received that permission, you should clarify that in your original post so there isn't any confusion. I think you also need to include license file in the zip file in Spacedock as well as your license in your original post that contains the downloads as I believe that is a requirement for the forum. This may be helpful: If you are looking for some help on modelling, you can take a look at making a donut in Blender to start before you start working on parts for KSP:

My fuelswitch patch should add in methalox fuel if you have an empty folder called CryoTanksMethalox in your gamedata folder. That is what Nertea uses in his patch to decide whether to add methalox tank variants, so I stuck to the same convention for the engines and tanks. Did a quick check and it does apply to both the ascent and descent stages of MAH.

@StoneWolfPC, it was different a few versions ago and was changed to solve another problem with JNSQ and BDB. Looks like that introduced an issue with KSPIE. As an untested hot-patch, you could try changing line 42 of Kopernicus/Config/SolarPanels.cfg to @name = KopernicusSolarPanels. That may not be the final solution as will need to test through combinations of mods in which this patch has created issues in the past