[1.9.1-1.10.1] Kiwi Tech Tree Overhaul 1.3.0 (17 December 2020)

[hemeac]

@evileye.x and @Clamp-o-Tron, I pushed an update to my Github repository that should help KTT, Kerbalism and Engine Ignitor work better together.  I haven't put it in a new release yet, as I want to do a couple more things before the next release this weekend.  But the repository should be stable if you want to test.

Kerbalism has three distinct features for engine reliability: start-up failure, burn duration, ignitions.  With the new patch, when Engine Ignitor is present, the start-up failure and ignitions for Kerbalism will be disabled only for the engines that have configurations for Engine Ignitor.  For both Engine Ignitor configured engines and non-configured engines, the burn duration calculation from Kerbalism  will remain present.  For non-configured engines, the number of ignitions and start-up failure will come from Kerbalism.  

Some of the default behavior is modifiable in: GameData/KiwiTechTree/KiwiConfig.cfg.  Clamp-o-Tron has done a pull request for Kerbalism to make patching Engine Ignitors easier, but in the mean time to ensure that the behavior works as good as possible, you will need to go to KerbalismConfig/Support/EngineIgnitor.cfg and change the patch to:

// disable all engine failures
@PART[*]:HAS[@MODULE[ModuleEngines*]]:NEEDS[EngineIgnitor,!KiwiTechTree]:AFTER[Kerbalism]
{
  !MODULE[Reliability]:HAS[#type[ModuleEngines*]] {}
}

Is there any interest from either of you or @linuxgurugamer for some default values for engines if they do not have a configuration?  

Kerbalism uses an algorithm described here to make the calculation:

// this calculates ignitions from thrust, and vac/atm ISP ratio:
// - the lower the thrust, the higher the ignition count.
// - the higher the difference between vacuum and atmosphere ISP, the higher the ignition count.
// thrust 0-350 gives 64-1 ignitions (custom exponential-ish scale).
// vac/atm ratio gives no bonus if below 150%, and then a linear bonus of +1 ignitions for every extra 20%.
// some specific engine types will receive further bonus.

That's something that I should be able to and happy to setup, but I would need some guidance on what some values they should be, when the IgnitorType should be Internal or not, the chance for failure when unstable and some EC values.  I will stick to Kerbalism's system for my own save, so will only do this if someone wants this feature.

Edited November 19, 2020 by hemeac

[linuxgurugamer]

4 hours ago, hemeac said:

there any interest from either of you or @linuxgurugamer for some default values for engines if they do not have a configuration

Sure, go ahead and make a PR, ping me when you do.

[Clamp-o-Tron]

Working on a default configuration now.

@linuxgurugamer can you take a look at this? It's a bit limiting in what can be done with the mod.

https://github.com/linuxgurugamer/EngineIgnitor/issues/12

[hemeac]

@Clamp-o-Tron Awesome, let me know if you want help testing or if any of the settings I set up for Engine Ignitor need to be tweaked.

[Clamp-o-Tron]

Just now, hemeac said:

@Clamp-o-Tron Awesome, let me know if you want help testing or if any of the settings I set up for Engine Ignitor need to be tweaked.

I'm just doing a pass on the stuff that support has been added for.

I regret to inform you that I'm not going to be finishing BDB- I'm not good enough with the inner workings and balance to really make BDB play well. 

I'm going to actually contribute some models to this, notably tiny sounding rocket parts and an XLR-11.

[hemeac]

@Clamp-o-Tron, No worries, I estimated it at 60 hours even at my fastest pace.  BDB is going to be one of those mods that is just tough to tackle due to the scope.  Will need to discretize it into chunks to process at a time similar to Near Future so it is not quite so daunting. 

Definitely cannot say no to sounding rockets and the XLR-11!

[hemeac]

Kiwi Tech Tree 1.1.0

• Added Asset Mk1, Stock TKS, Tundra Exploration/Technologies Support
• Better Bureaucracy support in CustomBarnKit config
• Fixed incorrect FOR passes in various Kerbalism configs leading to potential conflicts with patches when Kerbalism was not installed.
• Added improved compatibility between Engine Ignitor and Kerbalism (Will require a hot patch in KerbalismConfig, see forum for details)
• Confirmed continued support for updates in Conformal Decals, Modular Launch Pads, Smart Docking Aid
  Behind the scenes:
• Standardized cold gas thruster upgrades when Rational Resources installed
• Added additional engine upgrade configurations

Next set will be the Tantares suite of mods by Beale.

[flart]

I am not familiar with the "B9PS upgrade", is it like B9PS Variants, so I can switch to the not-upgraded variant?

Is it ok to switch unkerballed start techtree midgame, any error in the save ?

Edited November 20, 2020 by flart

[dylsh]

4 minutes ago, flart said:

I am not familiar with the "B9PS upgrade", is it like B9 Variants, so I can switch to the not-upgraded variant?

Is it ok to switch unkerballed start techtree midgame, any error in the save ?

Yeah im getting a B9 serious warning over variants 

[hemeac]

@flart, I have only tested on new saves, but would guess switching tech trees mid-save would cause bad things to happen.  @dylsh, are you getting a serious warning in a new game or testing an old one?

[dylsh]

1 hour ago, hemeac said:

@flart, I have only tested on new saves, but would guess switching tech trees mid-save would cause bad things to happen.  @dylsh, are you getting a serious warning in a new game or testing an old one?

I tried an existing game as well as a new game. I found it had to do with Kerbal Atomics

[hemeac]

@dylsh, I haven't been able to generate any errors when testing Kerbal Atomics engines.  I had run into issues with some of the detailed  descriptions in B9 so I had previously put in some placeholder text, but the engines themselves appear to be working as I am expecting them to in my installation.  Can you post a log file and the engines you have had an issue with and I will see if I can reproduce the issue.  Are you using any of the extras from Kerbal Atomics such as KerbalAtomicsNTRsUseLF or KerbalAtomicsLH2NTRModSupport?

[dylsh]

15 minutes ago, hemeac said:

@dylsh, I haven't been able to generate any errors when testing Kerbal Atomics engines.  I had run into issues with some of the detailed  descriptions in B9 so I had previously put in some placeholder text, but the engines themselves appear to be working as I am expecting them to in my installation.  Can you post a log file and the engines you have had an issue with and I will see if I can reproduce the issue.  Are you using any of the extras from Kerbal Atomics such as KerbalAtomicsNTRsUseLF or KerbalAtomicsLH2NTRModSupport?

Yes of course. I’ll reproduce the issue and the log tomorrow 

[dylsh]

@hemeac I messed around with it some more, and came to find out the problem is not with kerbalatomics itself, but rather the KerbalAtomicsNTRsUseLF extra addon.

 

here is a log: https://www.dropbox.com/s/dyqar620ziuvz9y/Player.log?dl=0

This log represents a limited mod install to make your job easier. Thanks!

[flart]

I installed and tested a little bit on current install. For switching TechTree midgame it's needed to clear all techtree nodes from the save (I used KML), then cheat some science and research manually to more-or-less the same level.

Some Feature Requests:

• Upgrades need to be purchased manually in the techtree, they will not work otherwise, but I like purchasing parts later, in the Editor.
  It is not very convenient to hover mouse parts for checking does it an upgrade or a new part.
  A possible solution is special cost for the uprades, for example last digit is 1: 5001, 801, etc.
• FileTree — some people could want to disable some function of the overhaul except the TechTree,
  It could be upgrades, science, new parts or patches to parts.
  Current FileTree makes it pretty difficult: some mod upgrades in the \Configurations\Mods\*\ per mod, some mod upgrades in the Configurations\Core\Upgrades\

 

Some Problems:

• In the TechTree I don't see nodes, that number tier level, though the patch for not hiding them (HideEmptyNodes.cfg) in the package.
• I also have B9PS Warning, it is about the restock+ Cherenkov engine:
  

 

Found Incompatibilities:

• Last update of Smart Docking Aid update stock SAS modules info,
  
  
  but with kiwi they look stock again
   
   
• these patches for stock parts 
  @title = Mk1-0 "Anticipation" Command Pod break stock localization. It's better to use localization strings
  #autoLOC..... = Mk1-0 "Anticipation" Command Pod
  And it's break Community Part Titles. Also I am not sure why you need to change names there, patches are not so crucial.

Edited November 21, 2020 by flart
Incompatibilities

[hemeac]

6 hours ago, dylsh said:

@hemeac I messed around with it some more, and came to find out the problem is not with kerbalatomics itself, but rather the KerbalAtomicsNTRsUseLF extra addon.

 

here is a log: https://www.dropbox.com/s/dyqar620ziuvz9y/Player.log?dl=0

This log represents a limited mod install to make your job easier. Thanks!

@dylsh,  I have added support for KerbalAtomicsNTRsUseLF, thanks for going through and testing.  The update has been pushed to Github, but will have an official release next weekend.  @flart, your issue seems to be different though.  My only guess at the moment is that another mod exists that patches the Chrenkov from Restock Plus to be a multi-mode engine other than Kerbal Atomics.  I should be able to go through your ModuleManager.log to see what is patching the Cherenekov and try narrowing it down from there.

@flart, thanks for the feedback. 

1. For switch mid-game, that's great that you were able to get it to work, but I won't support any attempts as that I think that will be a source of never-ending pain.
2. I took the HideEmptyNodes.cfg largely verbatim from Unkerballed Start as you probably saw in the internal notes, but as I hadn't implemented a Tier numbering structure in the tree itself, that code is redundant, but should otherwise be harmless.  I don't use Hide Empty Nodes and haven't really tested to see if it works well with KTT.
3. I understand the point on the upgrades, KSP's upgrade system leaves a lot to be desired.  For me I felt that the B9 switch with upgrades within the R&D lab was the lesser of two evils when compared to duplicating parts and adding upgraded statistics.   I felt that the VAB and SPH windows  would get very cluttered when needing to go through and comparing duplicate models.  However, I do not understand your comment about a special solution.
4.  Now that I have standardized the vast majority of upgrades, it should be feasible to disable various aspects of the upgrades and have it set as global options.  That probably falls under a larger release  and requires some testing and will probably wait for a bit before that gets implemented.
5. In regards to the file structure, I am happy with the organization and works well for me, but the general rule is that the various upgrade system patches fall in Configurations\Core\Upgrades\.  Part Upgrade nodes fall within each individual mod folder.  The squad patches are the exception to the rule.

[flart]

1 hour ago, hemeac said:

I do not understand your comment about a special solution.

There, in the RnD, we see costs of parts-or-upgrades.
If all upgrades satisfied some pattern (for example, on this screenshot would be 13501 and 6301), they would be easily separable from the parts without mouse hovering over them.

Spoiler

 

As a person, who have had Unkerballed Start + cut out science from the ProbesBeforeCrew, I see that PBC idea that crewed science > uncrewed science has changed and uncrewed science base values are bigger in the Kiwi. Why so?

 

Edited November 21, 2020 by flart

[Clamp-o-Tron]

11 minutes ago, flart said:

There, in the RnD, we see costs of parts-or-upgrades.
If all upgrades satisfied some pattern (for example, on this screenshot would be 13501 and 6301), they would be easily separable from the parts without mouse hovering over them.

  Reveal hidden contents

 

As a person, who have had Unkerballed Start + cut out science from the ProbesBeforeCrew, I see that PBC idea that crewed science > uncrewed science has changed and uncrewed science base values are bigger in the Kiwi. Why so?

 

@hemeacI think they mean changing the last digit so that you can tell quickly?

I believe as someone who has been somewhat close to development that uncrewed science values are higher than crewed because Kiwi is meant to be played with Kerbalism, and Kerbalism overhauls the science system which inherently makes uncrewed missions less rewarding, and Kerbalism offers lots of sweet sweet science points for crewed very long-duration experiments. This also could be because the tree has a spirit of using science as a means to crewed exploration, not the other way around.

[hemeac]

@flart, also thanks again for catching that the Smart Docking Aid update did knock out compatibility, will push an update for that to Github soon, just going through another log file at the moment.

Some of the flavour text added to the titles is part of the "core" design of KTT.  It is something that keeps me interested enough to create patches rather than just staring at Notepad++ and Excel.  I had not added localization support as had very low expectations that people would use KTT, but given that there is interest in the mod, I will be trying to work in localization support as the mod develops to make it more accessible.  I wasn't aware of Community Parts Titles, but will add as a to-do for a compatibility pass.

I think @Clamp-o-Tron stated more clearly than I can.  I thought I used values similar to PBC as a baseline, but it is possible that I changed them when working through some rough calculations to determine if there was enough easily achievable science to get to the Mun and beyond.   I am definitely open to suggestions on science points for the stock game and how they vary across manned and unmanned experiments. 

I  understand your comment about the visibility, think that should be easy to do with a late pass on the partupgrade nodes, thanks for the suggestion!

[flart]

2 hours ago, Clamp-o-Tron said:

uncrewed science values are higher than crewed because Kiwi is meant to be played with Kerbalism, and Kerbalism overhauls the science system which inherently makes uncrewed missions less rewarding, and Kerbalism offers lots of sweet sweet science points for crewed very long-duration experiments. This also could be because the tree has a spirit of using science as a means to crewed exploration, not the other way around.

Doesn't  :NEEDS[!FeatureScience] make patches works only when Kerbalism science is disabled?
 

2 hours ago, hemeac said:

some rough calculations to determine if there was enough easily achievable science to get to the Mun and beyond.
I am definitely open to suggestions on science points for the stock game and how they vary across manned and unmanned experiments. 

Every science mod makes much more available science, that why I like  lowered PBC  values for an uncrewed science.
Only DMagicOrbitalScience alone makes huge difference for the available science. 

As an example, firstly it's patches for the stock science in the case without any other science mods for "achievable Mun and beyond", and secondly lowered science in the  PBC-way for the stock and the mods.

It's patch that I use for the Interkosmos. The values very small because parts are almost the same little boxes.

Spoiler

@EXPERIMENT_DEFINITION:HAS[#id[Photometer]]:NEEDS[Interkosmos]
{
	@baseValue = 3  // 10
	@scienceCap = 3
	@dataScale *= 3
}

@EXPERIMENT_DEFINITION:HAS[#id[GasAnalyzer]]:NEEDS[Interkosmos]
{
	@baseValue = 4  // 12
	@scienceCap = 4
	@dataScale *= 3
}

@EXPERIMENT_DEFINITION:HAS[#id[IRSpectrometer]]:NEEDS[Interkosmos]
{
	@baseValue = 3  // 10
	@scienceCap = 3
	@dataScale *= 3
}

@EXPERIMENT_DEFINITION:HAS[#id[Hydrometer]]:NEEDS[Interkosmos]
{
	@baseValue = 2   // 8
	@scienceCap = 2
	@dataScale *= 4
}

@EXPERIMENT_DEFINITION:HAS[#id[Photopolarimeter]]:NEEDS[Interkosmos]
{
	@baseValue = 4  // 10
	@scienceCap = 4
	@dataScale *= 2.5
}

@EXPERIMENT_DEFINITION:HAS[#id[Crystals]]:NEEDS[Interkosmos]
{
	@baseValue = 5  // 8
	@scienceCap = 5
	@dataScale *= 2
}

 

 

Edited November 22, 2020 by flart

[hemeac]

@flart, again appreciate you taking the time to go through and look through the configs.  It looks like if I had set up the stock science for PBC values, that was changed back to stock values either accidentally or for a reason that I can no longer recall.  I am a bit hesitant to change science values now that I have hit a public release, but I will add some modified values as an optional extra on the next release and  incorporate that into the 1.5 release as that is intended to be the re-balancing update.  Part of my future plan is to scale the unlock points for tech nodes depending on the number of science-heavy mods detected such as DMagic, Interkosmos, BDB and Coatl Aerospace.  With each mod installed, the unlock nodes would increase to a degree that would make it a bit more challenging, but hopefully not "grindy".  

The :NEEDS[!FeatureScience] is intended as Kerbalism has it's own science system so those patches would not work as intended with Kerbalism Feature Science active.  I generally rely on the default Kerbalism values for stock experiments.  For mods such as Interkosmos which are not natively supported in Kerbalism, I define my own science experiments to fit the parts which you would see in GameData/KiwiTechTree/Configurations/Mods/Interkosmos/Interkosmos_Kerbalism.cfg.  

Edited November 22, 2020 by hemeac

[hemeac]

@flart, many of the updates in the next release will be due to your feedback, so really appreciate it.  Planning on doing a bit more work and will have an official release for next weekend, but pushed through some changes to Github which should be stable and has a couple of bug fixes.

 

There are a couple of changes to the science system by adding some options, but the current values are set as the default in order to not disturb any careers in progress.  This should be save game friendly.

The first is Science values for Non-Kerbalism installs, there are now three settings:

• stock (uses stock experiment values)
• default (close to stock values, but the science cap is the same as the base value so science does not need to be re-run and a reduction in transmittable science for experiments like goo
• hard  (reduces any unkerballed experiments to about half of the default level and for some mods, reduces the biome specific experiments)

The second is Tech Tree point defaults, again three settings

• default (the default used for KTT with Kerbalism-specific values)
• hard (adds additional points, particularly to early nodes)
• adaptive ( adds points to each tier based on the number of science mods multiplied by the Tier level multiplied by a constant (defaults at 1)).  Science mods  include: BDB, Coatl Aerospace, Dmagic, Interkosmos, Kraken Science, LTech, Mars Direct, Tantares SP.  To give an example, default  Tier 4 node costs 80 points to unlock.  With 6 science mods and a multiplier constant of 1, the adaptive model will be 80 + 4x6x1 = 104

You  can change these settings within GameData/KiwiTechTree/KiwiConfig.cfg.  They cannot be set in game unfortunately.

I would recommend creating a patch for changing these configuration values.  Unlike other personal patches, they should use either no defined pass or :FIRST.  Any changes using :FINAL will be ignored as my patches occur before the FINAL pass.

Edited November 22, 2020 by hemeac

[hemeac]

The next round of changes are up on Github which can fully disable various (or all) elements of the upgrade system that is introduced KTT.  All upgrades are set as "on" by default.  I haven't extensively tested with having the options partly enabled or disabled, but they should all work properly.  However, if anyone wants to double check having various combinations of the Fuel tank and System toggles "on" and "off", that is where any potential conflicts will arise.  As in the previous post, you can find these toggles in GameData/KiwiTechTree/KiwiConfig.cfg

KIWI_GENERAL_SETTINGS
{
	UPGRADES
	{
		BATTERY = on 			// Options: on/off Turning off will disable the battery density upgrades in KTT
		ENGINE = on 			// Options: on/off Turning off will disable the engine upgrades in KTT
		COMMAND = on 			// Options: on/off Turning off will disable the command pod structural upgrades in KTT
		FUELTANK = on 			// Options: on/off Turning off will disable the fuel tank upgrades in KTT.  This includes the composite material upgrade for SRBs.
		PARACHUTE = on	 		// Options: on/off Turning off will disable the parachute upgrades in KTT. 
		RCS = on				// Options: on/off Turning off will disable the RCS upgrades in KTT. This is only relevant if Rational Resources is installed, otherwise it is disabled.
		SAS = on				// Options: on/off Turning off will disable the Probe SAS upgrades in KTT.  Note that this result in the default SAS level for all probes and they may be out of order in the tech tree.  I will not balance accordingly.
		SOLAR = on		 		// Options: on/off Turning off will disable the solar panel upgrade system upgrades in KTT. Only relevant if Near Future Solar is installed, otherwise it is disabled.
		SPACECAPABLE = on 		// Options: on/off Turning off will disable the space capabile upgrade system upgrades in KTT.
		STRUCTURAL = on 		// Options: on/off Turning off will disable the structural parts upgrade system upgrades in KTT.
		SYSTEM = on 			// Options: on/off Turning off will disable the spaceplane system upgrades in KTT.
	}
}

 

[flart]

I doesn't have plume for Poodle
the patch misses :NEEDS[RealPlume], or something like that in the string:

!PLUME {} // In case RealPlume is installed as we will insert our own.
 

Also the Poodle is no longer vacuum  engine, wh-a-at 

Edited November 23, 2020 by flart

[hemeac]

@flart, were you having issues with the plume with or without RealPlume?  Do you have Waterfall installed?  If you have RealPlume, have you updated to the latest versions?  I haven't tested in the latest versions in which Zorg has started to do some compatibility passes for Waterfall.  I am fairly confident it was working in my game, but will recheck this evening. 

As for the Poodle in general, I was really bothered by the big difference between the new Poodle variant in 1.10.  So split the two variants.  Decided to keep the Poodle name for the original model and Malshi the name for the new variant.  As the nozzle length is longer on the new variant (Malshi), decided to have that keep the vacuum stats and make the Poodle more capable at sea level.