You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a workaround on my install, I edited the contract config files to remove the tech requirements, but you might want to find a more user friendly solution to this issue.
I understand that there are essentially two ways to handle this : scrap the tech requirements altogether as I did (quite radical), or make the research requirement depend on an explicit list of parts (or something similar which is not liable to change between users) rather than relying on tech tree node names.
If we can't achieve a desired outcome with what's available in CC, it might be needed to modify CC itself (for example to be able to create custom part lists or categories from inside contract definitions, if not already possible), which I suppose is a whole other can of worms.
What do you think ? Is this worth changing ?
Maybe a workaround can be found in Gradual Progression Tech Tree instead ? (I suggested maybe creating invisible nodes with the required names, that get unlocked alongside their new counterparts (Survivability -> Parachutes, etc)
The text was updated successfully, but these errors were encountered:
None of the BDB contracts are available to me because the required tech tree nodes do not exist for me (I use https://forum.kerbalspaceprogram.com/topic/226275-1125-gradual-progression-tech-tree-a-mod-focused-slower-early-game-tech-tree-024/, a fairly new tech tree mod that is markedly different from stock but is built mainly around BDB)
As a workaround on my install, I edited the contract config files to remove the tech requirements, but you might want to find a more user friendly solution to this issue.
I understand that there are essentially two ways to handle this : scrap the tech requirements altogether as I did (quite radical), or make the research requirement depend on an explicit list of parts (or something similar which is not liable to change between users) rather than relying on tech tree node names.
It seems that the REQUIREMENT node of a CONTRACT_TYPE can have data of type PartUnlocked, where the "part" component can be a list of AvailableParts : https://github.com/jrossignol/ContractConfigurator/wiki/PartUnlocked-Requirement https://github.com/jrossignol/ContractConfigurator/wiki/AvailablePart-Type
This could be potentially be populated by AllParts() filtered by the string value of the part, the IsUnlocked() and Category() methods, etc... guess I'll test that when I get the time.
If we can't achieve a desired outcome with what's available in CC, it might be needed to modify CC itself (for example to be able to create custom part lists or categories from inside contract definitions, if not already possible), which I suppose is a whole other can of worms.
What do you think ? Is this worth changing ?
Maybe a workaround can be found in Gradual Progression Tech Tree instead ? (I suggested maybe creating invisible nodes with the required names, that get unlocked alongside their new counterparts (Survivability -> Parachutes, etc)
The text was updated successfully, but these errors were encountered: