hemeac

@JadeOfMaar, just in case you missed this, this was fixed in 1.11

Really appreciate it!

@Peter JY, there is an Aerobee mod in development that you will want to follow:

@ev0, either solution would work great for me. I have my entire tree setup in an Excel workbook that can generate MM patches for me, so it is a simple change to add in code on my end for whatever method is easiest for you to maintain. As it is though, I think my tree would be mostly setup for your second option. To give you an idea of what I already have: RDNode:NEEDS[KiwiTechTree] { id = tier11 tier = 11 title = #LOC_KTT_tier11_Title // Tier 11 description = #LOC_KTT_tier11_Description // Tier 11 cost = 0 hideEmpty = False nodeName = ktt_tier11 anyToUnlock = False icon = KiwiTechTree/Icons/ktt_icon_tier11 pos = -1090,2260,0 scale = 0.6 } RDNode:NEEDS[CommunityTechTree] { id = exoticNuclearPower tier = 11 title = #LOC_CTT_exoticNuclearPower_title description = #LOC_CTT_exoticNuclearPower_description cost = 2734 hideEmpty = False nodeName = ktt_exoticNuclearPower anyToUnlock = False icon = KiwiTechTree/Icons/ktt_icon_exoticNuclearPower pos = -1090,2128,0 scale = 0.6 Parent { parentID = expNuclearPower lineFrom = RIGHT lineTo = LEFT } }

@Clamp-o-Tron, I'll add this to KTT alongside Nertea's additional NEEDS. This should hopefully help keep KTT compatible with older versions.

@ev0, What are your thoughts about hard coding a statement that nodes that begin with a particular word or phrase will be visible irrespective of whether they have parts/upgrades? If that word was tier*, that could allow Unkerballed the option of working without needing to modify any node ids. However, the flip side is that tier could conceivably be used as a way to distinguish nodes for a yet written tech tree and that could be a difficult to diagnose issue for a tech tree mod author if you happen to not be available if that issue crops up. I don't have super strong feelings about this, I am happy to write a note in the list of mod support for KTT to the affect that RDNode Settings should be enabled. I think no matter what option you choose, you will create some level of compatibility issues :-)

I'm happy with the behavior as is, I should have looked to see if there were options first.

Crusader Kings 3 sucked up a lot of my free time this week, but have made some more progress on the tree. On the late tiers, I have duplicated the id's from Interstellar (icons pending) as that will not only save time, that should help the user experience. For Interstellar users, that mod will still have the final say in the MM patch order war to determine node dependencies and locations as well as a few part locations. @FreeThinker has also generously donated some time to develop a plugin for KTT that should help users that are switching mid-career. The basic idea is that any of the early nodes that I have created should be auto unlocked if their children are unlocked. Lastly, similar to Unkerballed Start, I have adopted empty nodes that indicate the Tier and they display both on the top and bottom of the tech tree. This should help locate part upgrades as descriptions will now include the tier number of the upgrade, based on @flart's suggestion.

I had been using a patch that was borrowed from Unkerballed Start which I think originally came from @flart: //Code adapted from Flart on KSP Forums @TechTree:NEEDS[HideEmptyTechTreeNodes]:FOR[zKiwiTechTree] { // Hide all empty nodes, initially @RDNode,* { @hideEmpty = True } @RDNode:HAS[#id[tier*]] { @hideEmpty = False } } However, I just realized that there is a setting in the options, "Use RDNode Settings". Setting that gets everything to show properly.

@ev0, I've been thinking of adding empty nodes at the top and bottom of the tree that denote the tier (see below). As they are empty, they are getting grabbed by your mod. Do you have any current method to workaround that? This isn't mission critical, but let me know if there is anything that I can do to make your job easier. They currently have a cost of 0 and have an id that starts with tier

If I want to remove a conflicts with from my ckan file for the Kiwi Tech Tree, what is your preferred process?

@flart, agree on <part> has an upgrade in <node_name> [<node_tier>]. Added that to the description text. Awesome on CPT support!

@FreeThinker, That's great, thanks! I will need to mark it as compatible with CKAN as originally listed as incompatible due to the tech tree issue and had not tested the upgrades with KSPIE. My 2.0 update to the tech tree will break existing saves, but that is about a month away at the very earliest. I'll ping you when it is getting closer so can try and coordinate the update. On the update front, the framework for engine upgrade system is largely complete for standard engines. This will be used for the majority of single fuel-type engines that have one ModuleEngines (ie. stock and most mods). This system allows engines to have B9 switches for different fuel types (ie. Hydrolox and Methalox) and will automatically convert the performance (ie. thrust and ISP) of the engines based on the baseline fuel type based on pre-set multipliers. Engine costs and masses are able to change across fuel types as well. These multipliers however can be overridden. Using the Swivel as a proof of concept, I won't be allowing all engines to have four different fuel types. I will be largely using existing mods to inform of the possible fuel types. The exception will be the cryogenic engines in which as before, I will be adding a methalox variant. In the update, I will be switching to Waterfall for the custom plumes for the CryoEngines mod. Unless Nertea or someone else starts working on a large Methalox engine pack. This flexibility in the type of upgrades will be restricted to the simpler engine-types. The R.A.P.I.E.R. and some of the Kerbal Atomics engines will likely stick to something akin to the pre-existing upgrades due to their complexity.

Looks great, I think resizing the nodes to 0.5 has helped it scale well with the compacted size.

@ev0, a quick look and it seems to be working really well with my development version of the tree in 1.11

@Hypercore, Thanks! I haven't tried Real Fuels, but have quickly browsed through some of the cfg files. With the direction of the mod for 2.0, I don't think I could feasibly support the engines with upgrades, but I suspect that it could work with the upgrades to the engines disabled and possibly the fuel tank upgrades. I've given myself a reminder on Github to test how well it works when I have finished up some of the backend work on the new upgrade config code. Real Fuels may even work with KTT 1.3 if you try disabling the engine upgrades. This should be the code that you would need, but may need a bit of fiddling on whether the system upgrades would need to be disabled. @KIWI_GENERAL_SETTINGS:FIRST { @UPGRADES { @ENGINE = off // Options: on/off Turning off will disable the engine upgrades in KTT @FUELTANK = off // Not sure how well these upgrades work with Real Fuels so may be safer to disable // Options: on/off Turning off will disable the fuel tank upgrades in KTT. This includes the composite material upgrade for SRBs. //SYSTEM = on // These may need to be disabled as some have fuel, but still may work out ok. // Options: on/off Turning off will disable the spaceplane system upgrades in KTT. } }

@evileye.x , that's awesome! That's exactly the type of experience that I was hoping to create, so glad that it's working as intended. Happy to see you @TheJewelOfJool, @Clamp-o-Tron, happy to see you all catching up on KSP as well over Christmas :-). I've thrown up a channel on my discord server for contract packs if that's easiest enough for you all. Career Evolution was my go-to in my last career and agree has a really nice flow. There is also an unfinished contract pack that I really liked the look of: I've contacted @KSP_Jack and had not heard from them, so need to assume that it is an all rights reserved license, but may have some good inspiration to work from. Happy on you all taking the lead on what a good contract pack can look at. I'm off work until Jan 4 and generally sticking around Melbourne outside of some day trips and catching up on some deferred house maintenance. I'm hoping to get at least the stock placements settled by then and start working on some of early career engines and can coordinate balancing parts and contract parameters.

That's great to know, thanks!

Based off of Nertea's comments, I think this will break the breaking ground inventory parts, so just a heads up.

@NateDaBeast, you may want to try the solution in the post above yours.

Looks really great. The padding in the interior of the cargo bay is a really nice touch.

@Jiraiyah, the OP notes that it is not compatible with visual mods like AVP, SVP, etc.

@theleg, Zorg has a post in the previous page about the future of RealPlume. It's my understanding that Zorg and other modders are moving to using Waterfall for liquid fuel engines/RCS, but keep RealPlume for SRBs.

@Atlas Gaming I came across it randomly, has been really handy for displaying thrust and ISP statistics in descriptions after altering them with multipliers. There's some other good bits in the code that may come in handy: https://raw.githubusercontent.com/Kerbalism/Kerbalism/master/GameData/KerbalismConfig/System/Reliability.cfg

@Atlas Gaming, I am usually able to use :HAS[] in combination with NEEDS as the basis to apply a patch. Do you have anything in particular? I do not know about rounding, but I have found this really clever way to get an integer that is functionally a floor function using regular expressions in Kerbalism. Think it works through just truncating anything after the point. @rated_ignitions ^= :\.\d+:: // Floor value to get an integer @cyberKerb, think it should be as I don't think the > implies greater than or equal @PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[>0],@MODULE[ModuleScienceContainer]] {}