[WIP] [Planning/Feedback] Tech Tag Foundation - Part Grouping for easier Tech Tree Creation

[DeltaDizzy]

Tech Tag Foundation

Background

For some time now, @KerbalKore  and I have been working on a pseudo-historical tech tree (named CWPT) , with parallel American, Soviet, and European branches. The vast majority of the US branch  uses Bluedog Design Bureau. However, BDB has several hundred parts, and configuring each one individually would be a mammoth undertaking. In light of this, we decided to instead 'tag' every part, thus allowing us to use tags to group parts and greatly lessen the workload. Soon enough, I realized this could also be helpful for other tech trees wanting to incorporate BDB, resulting in the decision to split out the tags into a standalone mod to be released first (after the tree itself has had months of delays due to IRL circumstances).  I also realized that the tags as they exist now are not the best suited for generic use, as they group parts into the real rockets/spacecraft. This makes sense if you aim for a historical-ish progression, but not so good for a purely gameplay/balancing-focused progression. 

How it works

TTF is essentially a giant ModuleManager patch that adds a single line to all supported parts of each supported mod:

@PART[name]:FIRST:NEEDS[mod]
{
	%techtag = tagName
}

Then, when a tech tree mod loads, it can assign parts to nodes based on the tag, instead of the part name:

@PART:HAS[#techtag[tagName]]
{
	@TechRequired = nodeName
}

Part modders are also given the option to allow the tags to be added directly into the part configs, as is being done with BDB.'

NOTE:

It shouldn't really be an issue, but any patches that use or affect the tags MUST run before LAST[TechTagFoundation].  Any custom fields inserted into part configs throw log warnings if they are still there when KSP compiles the parts. To avoid log spam all tags are removed from all parts in the aforementioned ModuleManager pass.

The Point

Currently, the tags are simply the names of rocket stages or spacecraft, meant to align with the original goals of CWPT.  In the interest of easing the burden on other tech tree makers, I am asking what level of granularity and what 'categories' of tags should be used.

 

Edited October 28, 2020 by DeltaDizzy

[taniwha]

This is a very nice idea. I have been unhappy with EL's tech-tree arrangements but have yet to do anything about it. One of the reasons for that was me being all too aware of tech tree mods. A system like this would make it it so I can arrange EL parts how I see fit for stock, but also group them logically and thus support those tech tree mods out of the box.

[hemeac]

If I knew a few months ago when I started my tech tree mod what I know now about MM patching, I would probably have tried using a tag system for part placement.  Think this is a really great idea on making tech trees modding more accessible.  I would probably implement one using two tags: Branch and Tier.  So may see  something like techBranch = engine; techTier = 2 as that would help with the fact that I am using part upgrades and could use techTier as a basis to automatically place the partupgrade nodes in a later part of the branch.  In my internal documents that list the name of the tech tree names, I have about 30 branches that indicate different technology types such as cockpits, structural parts and wings, command modules, etc.

Also, really great to hear about your work on CWPT, that is something I would be really interesting in using in a future campaign.

Edited October 28, 2020 by hemeac

[JadeOfMaar]

I've wound up providing support for 3 tech trees in OPT Spaceplane Parts. (Updating existing CTT support; and creating support for Tetrix and RP-0). Fuselages and wings bundle up very nicely. Those are most of the parts, but the challenge remains in that the engines are truly various in nature so they still end up scattered pretty widely. With that and the rising provision for tech branches specific to solid and hydrolox rocketry, I've seen the potential need to also tag engines by their propellant and possibly their type, in a more flexible but precise way than targeting the engineType key inside ModuleEngines(FX) {}.

I see OPT's engines as hydrolox (so they are placed accordingly in the hydrolox branch) meanwhile Airplane Plus' engines would remain LFO. OPT also has scramjet and TBCC engines, plus RP-0 has an actual Scramjets tech node so I populated that.

On 10/28/2020 at 1:20 AM, hemeac said:

So may see  something like techBranch = engine; techTier = 2

Following that I would see something like techEngineFuel, techEngineType happening. It would be like the subcategory = 0 key/value you see in many part configs but actually useful in this case. This key pairing would allow for great precision whereas stock ( engineType) just has SOLID_BOOSTER, LIQUIDFUEL, TURBINE, NUCLEAR, ELECTRIC...  but we would want to see:

// Choose one value for each key or don't set the key.
// The part can be targeted for defaults in the asbence of the key(s)
// First listed value is the default
// Propellant dimension
techEngineFuel = liquid, solid, hydrogen, methane, mono, air, atm, metal, electric, exotic

// Class dimension
techEngineType = rocket, hybridEngine, propfan, turbojet, ramjet, scramjet, atomicjet, atomicrocket, ion, torch

// * exotic is a catch-all for sci-fi and fantasy fuels like 
//  USI's Karborundum, WBI's Graviolium, OPT Dark Goo, Taurusfecallium...
// * air vs atm is to distinguish between air-breathing engines 
// that rely on Oxygen or can do without. See IntakeAir vs IntakeAtm usage.
// * hybridEngine can refer to either hybrid solids that accept 
// SolidFuel + a liquid Oxidizer, 
// or engines that are jet + rocket like the RAPIER.
// * ramjet may not be popular now but I'm making use of it myself in engine concepts.

 

Edited October 31, 2020 by JadeOfMaar