Jump to content

[1.10.1] UnKerballed Start v1.2.0 (Under New Management Aug 28, 2020)


Recommended Posts

Unkerballed Start - Under New Management!

original by SpinkAkron and theonegalen, now under development by theonegalen

This is an unmanned start mod inspired by Yemo’s SETI, Unmanned Before Manned. It is structured around early probes and aircraft. Manned capsules become available as later tech.

Download link is at bottom of this post.

Overview

  • Starting with the Stayputnik probe core, lack of control is the first challenge to overcome. The QBE is available at Stability (T3) and the OKTO at Flight Control (T4). RCS has been moved to earlier in the tech tree.

  • Only .625m engines are available at start. More powerful engines have been moved up the tech tree. Multi-engine stages are essential. Making History's engine plates are made available earlier to facilitate this.

  • Revamped tech tree - The tech tree has been de-squished, de-tangled, and rationalized. Orphan lines such as Nuclear Power and Colonization have been fully integrated. Additional nodes have been added to flesh out the early tree and where needed at various other points. The Precision Rocketry line has been expanded to cover additional tiers, splitting Rocketry into a Power/Boosters line and a Specialty line. This further slows rocketry advancement. NOTE: All inputs to a node are now required to unlock, not just one like stock. Links that didn't make sense have been removed. The only exception to this is that 

  • Just like the Community Tech Tree, on which this is based, most of the later nodes will have no parts in them unless mods using them are also installed. See the CTT thread for a mod list.

  • To balance the delayed availability of powerful engines, many other parts such as docking clamps and station hubs have been moved up allowing for earlier station development. The intent is that the player spend more time developing the Kerbin SOI before heading out to the planets. Special thanks to @Pand5461 for the concept of later engine availability. That was the key that made the whole project come together.

  • Early aviation with extensive mod support.

  • The Soviet-style Reentry Pods now have their own tech line. They are simple and cheap, but ultimately a dead end. In a low-income playthrough they become a real option.

  • Only the tech tree node placement of parts is effected. No parts or resources are changed, reducing compatibility issues.

  • Two new .625m engines have been added. The LV-T05 and LV-T10 are re-scaled versions of the LV-30 and LV-45. The RT1 SRB is no longer necessary thanks to the stock Mite and Shrimp SRBs.

  • Added .625m Fairing generously provided by @PocketBrotector from his Extended Antenna Progression Mod. Thanks!

  • ON BY DEFAULT - Small parts means more parts so the VAB and SPH can now build craft with 40 parts at Tier 1, enabled by Custom Barn Kit.

 

Screenshot of tech tree branches (click for full size)

BsNx7Vu.png

Compatibility

The only mods that are incompatible are other tech tree mods. All parts added by mods will work as designed but their position in the tech tree may not be consistent with the changes made by this mod. If you’d like a mod adapted, I’d be happy to make a config for it, or accept one on Github.

Custom configs are provided for the following mods so far:

Spoiler

Squad DLC: Making History
Squad DLC: Breaking Ground

AirplanePlus
ALCOR
BARIS
Deadly Reentry
DMagic Orbital Science
Freyja
Fuel Tanks Plus
Interstellar Extended
KAX
Kerbalism
Kerbonov
kOS
KW Rocketry
MAD
Mandatory RCS Part Pack
Mk3Airliner
Missing History
Near Future Construction
Near Future Electrical
Near Future Launch Vehicles
Near Future Spacecraft
Nova Punch
Odin
Open Cockpit
Planetary Bases
Real Chute
RemoteTech
ReStockPlus
RLA Reborn
SCANsat
SETI Probe Parts
Snacks
Station Parts Expansion Redux
TAC Life Support
TAC Self Destruct
Taerobee
Thor
Umbra Space Industries MKS
Universal Storage 2
USI Life Support

Recommended Mods

Making History - Official Expansion 
Missing History - Adds the parts that Making History missed
Restock Plus - You're already using this, right? No? Go get it!

Contracts - Having a good set of contracts that compliment the tech tree is crucial. The stock contracts assume the stock tech tree.

I use Career Evolution Contract Pack, usually paired with Giving Aircraft a PurposeBases and Stations Reborn, and Field Research.

Strategia - replaces stock strategy system

@SpinkAkron uses SETI Contract Pack made by @Yemo, UKS's spiritual godfather.  As an alternative, Exploration Plus is very good for those who prefer a less guided career.
He also uses
Clever Sats
Kerbal Academy
Bases and Stations Reborn
Remote Tech Contracts - currently not working. Unofficial fix HERE
Rover Missions Redux
Tourism Plus
Giving Aircraft a Purpose
Field Research

I also use Kerbal Construction TimeSnacks!Bureaucracy and highly recommend BARIS if you promise not to whine about your rockets blowing up. ;)

Above all, use what gives you the greatest enjoyment. Make the game your own. There is no wrong way to play!

mod list for Spink's Let's Play Using UKS (YouTube playlist)

Spoiler

--- Mod List ---
AdjustableModPanel
AlternateResourcePanel
BAMCont
BackgroundResources
CapCom
Chatterer
ClickThroughBlocker
CollisionFXUpdated
CommunityCategoryKit
CommunityResourcePack
CommunityTechTree
ContractConfigurator
ContractConfigurator-CleverSats
ContractConfigurator-FieldResearch
ContractConfigurator-KerbalAcademy
ContractConfigurator-KerbinSpaceStation
ContractConfigurator-RemoteTech
ContractConfigurator-Tourism
ContractParser
Contract_Pack_Rover_Missions
CustomBarnKit
DMagicOrbitalScience
DeadlyReentry
DistantObject
DistantObject-default
EarnYourStripes
EditorExtensionsRedux
EngineLighting
EnvironmentalVisualEnhancements
FerramAerospaceResearchContinued
FilterExtensions
FilterExtensionsDefaultConfig
FinalFrontier
FlightTracker
IndicatorLights
IndicatorLightsCommunityExtensions
JanitorsCloset
KSP-AVC
KerbalAlarmClock
KerbalChangelog
KerbalConstructionTime
KerbalEngineerRedux
MK1StkOpenCockpit
MagiCore
MakingLessHistory
MandatoryRCS
MemGraph
MemorialWall
MissingHistory
MoarFEConfigs
ModularFlightIntegrator
ModuleManager
MonthlyBudgets
MyTweaks*
OhScrap
PartInfo
PoodsCalmNebulaSkybox
ProgressParser
ReStock
ReStockPlus
RealPlume
RealPlume-StockConfigs
ReentryParticleEffect
RemoteTech
SCANsat
SETI-Contracts
Scatterer
Scatterer-config
Scatterer-sunflare
SciFiVisualEnhancements
ScienceSituationInfo
ScrapYard
SigmaReplacements-SkyBox
SmokeScreen
SpaceAge
StageRecovery
StockNoContracts
Strategia
TACLS
TextureReplacer
ToolbarController
TriggerAu-Flags
UnKerballedStart
kOS
x.Science

 

Changelog:

1.2.0   Update for KSP 1.10
            Fix LVT05 and LVT10 Engines not showing up with ReStock, also gave them worse specific impulse
            Add NEEDS to CustomBarnKit to prevent problems with Bureaucracy
            Moved heatshields out of Life Support and Hydroponics nodes - thanks to Rocketology for pointing it out
            Removed :FINAL from MM patches
            added version file for KSP-AVC users
            Added config for CNAR - Completely Non-Aggressive Rocketry by DylanSemrau
            Added config for Hide Empty Tech Tree Nodes by ev0

Old changelog:

Spoiler

 

1.1.0   Update for KSP 1.8.
            Added config for Breaking Ground DLC suggested by kcs123
            Disabled RT-1, replaced by stock engine.
            Fixes to tech tree suggested by FreeThinker
            Fixes to Intersteller suggested by FreeThinker
            Change to Custom Barn Kit suggested by kcs123 - 
allows SPH and VAB to create 40 part craft at Tier 1
            Change to DMagic Orbital science suggested by kcs123
            Added config for Infernal Robitcs Next suggested by kcs123
            Added config for PEBKAC Launch Escape System suggested by oOScarfacEOo
            Added icons by Tonas1997

1.0.7    Added the rest of the changed parts for 1.7. Derp.
            Reduced cost of Custom Fuel Tanks node

1.0.6    Fix misplaced .75m Waste HexCan for TAC Life Support.

1.0.5    Re-disabled the CustomBarnKit.cfg. In previous versions, I had mistakenly included the non-disabled version.
            Added compatability for 1.7

1.0.4    Fixed the fix for LV10 attachment nodes that I failed to fix.

1.0.3    Incorporated ModZero's fix for LV05 and LV10 attachment nodes when Restock is installed
            and Missing History is not.

1.0.2    Fixed Real Plume configs to eliminate MM warnings.

1.0.1   Fixed tier 13 costs
            Added RealPlume configs
            Added theonegalen's configs for AirplanesPlus, MAD, Mk3Airliner, ReStockPlus, KAX, TAC Self Destruct

1.0.0    Added theonegalen's aero configs
            Adjustment of the starting parts suggested by MaltYebisu
            Standardized engine placement
            More mod configs added.
            Added Tier markers and wings nodes

0.9.1     Unscrewed up the engines.

0.9.0    Balancing.  Added Config for Custom Barn Kit.  Uploaded to Spacedock.

0.8.1    Fix for Antenna not showing at start
            Fix nodes for the new LF engines when Missing History is not present
            BARIS config added
            
0.8.0 Initial Beta release

 


Required mods:

Community Tech Tree

Module Manager

Custom Barn Kit - OPTIONAL for VAB SPH allowing 40-part craft at Tier 1.

Installation Instructions:
1. Uninstall any previous version of the mod when upgrading to the latest version.
2. Copy the UnKerballedStart folder into GameData.

Download:

UnKerballed Start on SPACEDOCK

UnKerballed Start on GITHUB

 

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Edited by theonegalen
Link to post
Share on other sites

Thank you @theonegalen , I have been looking for a Probe's first tech tree which has been updated to 1.10. Can anyone recommend a contract pack which works with this and with 1.10. I have looked at the recommended ones and they all seem not to be compatible with 1.10. Any help would be greatly appreciated, also if this is not the right place to ask I will happily delete my message.

Link to post
Share on other sites
47 minutes ago, pllsr said:

Thank you @theonegalen , I have been looking for a Probe's first tech tree which has been updated to 1.10. Can anyone recommend a contract pack which works with this and with 1.10. I have looked at the recommended ones and they all seem not to be compatible with 1.10. Any help would be greatly appreciated, also if this is not the right place to ask I will happily delete my message.

All contract packs should work with 1.10+ unless otherwise stated, contract configurator was recently updated for it and there's no other meaningful changes to the game in this regard.

Link to post
Share on other sites
4 hours ago, pllsr said:

Thank you @theonegalen , I have been looking for a Probe's first tech tree which has been updated to 1.10. Can anyone recommend a contract pack which works with this and with 1.10. I have looked at the recommended ones and they all seem not to be compatible with 1.10. Any help would be greatly appreciated, also if this is not the right place to ask I will happily delete my message.

This is a perfectly fine place to ask.

I still use Career Evolution Contract Pack. When you load KSP, press CTRL+ALT+F10 and it will show you which contracts are broken in red. I always disable the base and space stations contracts from CE and replace them with Bases and Stations RebornField Research also works great, even though it hasn't been updated in over three years. Giving Aircraft A Purpose is also still really good, but I would only recommend it if you intend to spend a while doing planes before you get to manned orbit.

Unfortunately, I haven't noticed much development in the realm of contracts in the past couple of years. Not many people seem to play career mode, and I think the walling off of the really neat Making History mission creation tools behind paid DLC took the wind out of the sails of contract creators.

Link to post
Share on other sites
4 hours ago, theonegalen said:

This is a perfectly fine place to ask.

I still use Career Evolution Contract Pack. When you load KSP, press CTRL+ALT+F10 and it will show you which contracts are broken in red. I always disable the base and space stations contracts from CE and replace them with Bases and Stations RebornField Research also works great, even though it hasn't been updated in over three years. Giving Aircraft A Purpose is also still really good, but I would only recommend it if you intend to spend a while doing planes before you get to manned orbit.

Unfortunately, I haven't noticed much development in the realm of contracts in the past couple of years. Not many people seem to play career mode, and I think the walling off of the really neat Making History mission creation tools behind paid DLC took the wind out of the sails of contract creators.

Really? Man I love career mode. I never play the other modes. Monetary concerns force me to be smarter and more creative with designs and makes me actually want to recover stages.

Anyway, thanks for updating this. I just started using it a few days ago after being annoyed by being able to send a Kerbal to space with no science spent...

Link to post
Share on other sites
6 hours ago, theonegalen said:

Unfortunately, I haven't noticed much development in the realm of contracts in the past couple of years.

I'm trying to sort out something for Sounding Rockets to make them interesting and worthwhile (and not too grindy.) It's slow , but progressing.

Link to post
Share on other sites

(moved from the old thread)

8 hours ago, kcs123 said:

So, if :FOR[zzzUnkerballedStart] is necessary to have for proper patching order, might be good idea to declare it in some other config file that is not recommended to be deleted/disabled for users that don't like current CustomBarnKit config. Just wanted to be aware of it. Sorry if I'm wrong in case that I missed something else that I didn't aware of.

I would suggest :FOR[zzzUnkerballedStart]:NEEDS[zzzUnkerballedStart] and then create a directory named zzzUnkerballedStart on GameData. The :FOR thingy has this nasty habit of creating the MM tag for the Add'On, no matter what config had issued it. The :NEEDS will get rid of if the directory is not found.

On a personal note, the GameData will be heavily cluttered with tons of "zzz" directories around.

Link to post
Share on other sites

Thanks so much for the upgrade!!  This is my favorite Tech Tree rework.

I was wondering if you meant to remove the VAB/SPH switch custom barn kit?  I was always of fan of switching those around, making your launchpad the restricting upgrade for the KSC.

Thanks again for all the good work.

Link to post
Share on other sites
2 hours ago, Lisias said:

(moved from the old thread)

I would suggest :FOR[zzzUnkerballedStart]:NEEDS[zzzUnkerballedStart] and then create a directory named zzzUnkerballedStart on GameData. The :FOR thingy has this nasty habit of creating the MM tag for the Add'On, no matter what config had issued it. The :NEEDS will get rid of if the directory is not found.

On a personal note, the GameData will be heavily cluttered with tons of "zzz" directories around.

Well, as far as I know UKS does not really need another directory with "zzz" prefix. It already got "UnkerballedStart" directory. So, it can use it as advantage where needed. Somewhere might be enough to have just "UnkerballedStart" in MM BEFORE/AFTER commands and where necessary, second layer of MM commands may be used with "zzzUnkerballedStart". Btw, does not necessary be named as "zzzUnkerballedStart", but since it was used from day of release, it shoul remain, others have wrote their personal MM patches based on it.

UKS does not mess around with changing parts so much, so it is less dangerous with creating something that would broke TS patching, but it is always possible, so it is best to be aware of it and avoid if possible.

6 hours ago, theonegalen said:

Gotcha. It's also in the Making History config.

Would be great if we could move all conversations to the new thread.

What about people who don't have Making History DLC ? Will be :FOR command triggered properly ? Sorry, I didn't have time to inspect the rest of code. If MM in Making History config is ensured to be executed than it is all good, but something to be aware of if it is not a case.

And sorry for being a bit offtopic, but since I watched TS and MM thread and knowing about need for agreement of proper order how MM patches are executed, some idea have arised about it. I don't know if it is possible, or it may require changes in MM itself, but would be possible to have something like this:

// detect combination of already installed mods
@something[]:NEEDS[ModName1,ModName2]
{
	// declare new name that MM is aware of and that can be used for other patches
	:FOR[ModCombination1]
}

@something#2[]:NEEDS[ModName1,ModName2,Modname3,Modname4]
{
	// declare new name that MM is aware of and that can be used for other patches
	:FOR[ModCombination2]
}

// new declared names "ModCombination1" used for actual part patching only if it is declared with proper mod combo:

@PART[KAXVintagePropelator]:NEEDS[ModCombination1]
{
	@TechRequired = start
}

Above is most probably not proper MM syntax, but should be enough to give you idea how it should work. Meaning, "ModCombination1" should exist only with certain combination of already installed mods and any additional patches on parts would be executed only if "ModCombination1" exist. @Lisias, would something like that help with current situation with ongoing race with :LAST/:FINAL MM commands between various mods that mess around with same parts ?

Link to post
Share on other sites
52 minutes ago, kcs123 said:

Above is most probably not proper MM syntax, but should be enough to give you idea how it should work. Meaning, "ModCombination1" should exist only with certain combination of already installed mods and any additional patches on parts would be executed only if "ModCombination1" exist. @Lisias, would something like that help with current situation with ongoing race with :LAST/:FINAL MM commands between various mods that mess around with same parts ?

That's the thing... It depends of the patch. Lets take one example from the OP's github:

@PART[CanardController|tailfin|sweptWing|R8winglet]:NEEDS[CommunityTechTree]:AFTER[zzzUnKerballedStart]
{
	@TechRequired = flight3
}

Why it needs to be done after zzzUnkerballedStart? Since you are adding support for an add'on, why not patching together it? There's no real hard dependency between Unkerballed Start and Airplane.

I would consider something like this:

@PART[CanardController,tailfin,sweptWing,R8winglet]:FOR[AirplanePlus]:NEEDS[UnkerballedStart,AirplanePlus,CommunityTechTree]
{
	@TechRequired = flight3
}

The patch would be applied only if UnkerballedStart, AirplanePlus and CommunityTechTree are installed. And since it's just a string edit, there are no hard dependencies involved. This would gracefully allow anyone willing to second guess this TechTree on Airplane to just use :AFTER[AirplanePlus]:NEEDS[UnkerballedStart] , and any race conditions would be a problem to be handled by people willing to second guess Unkerballed Start - what I think is a saner and fairer.

Using this same logic, the Unkerballed TechTree itself would be patched as:

@TechTree:AFTER[CommunityTechTree]
{
// Nodes added
//fabrication, aeronautics, basicConstruction, earlyAviation, gadgets,
//specializedRocketry, customFuelTanks, gizmos, earlyHeatManagement, 
//specializedRocketry7, specializedRocketry8
<yada yada yada>
}

So people willing to expand/replace things on Unkerballed Start could just use :BEFORE[UnkerballedStart] or :AFTER[UnkerballedStart] .

The problem would be add'ons willing to second guess both CommunityTechTree and UnkerballedStart . A problem that these ones could handle on their zzzThingy themselves. Or just zzz, by Kraken's Sake - what difference it would do with a proper and carefully built :NEEDS ?

Conflicts between incompatible add'ons (as another TechTree completely different from Unkerballed Start) would be better handled by another tool, perhaps on Unkerballed Start itself, checking on startup for incompatible add'ons or checking for its integrity and yelling if something is wrong.

This is something that would be better served on zzzUnkerballedStart:

UnkerballedStartPatchingErrors:FOR[zzzUnkerballedStart]
{
	error:NEEDS[UnkerballedStart,IncompatibleAddOn1,IncompatibleAddOn2] = "IncompatibleAddOn1 and IncompatibleAddOn2 were detected. You should choose only one of them, you can't have both installed"
	error:NEEDS[UnkerballedStart,IncompatibleAddOn3] = "IncompatibleAddOn3 was detected. This thing is imcompatible with Unkerballed Start, you need to remove it"
}

And then checking for any values named "error" on that node at startup.

-- -- -- POST EDIT -- -- -- 

I just realised that UnkerballedStart itself is the one willing to second guess Community Tech Tree!!!

So I need to examine how Community Tech Tree works in order to be sure what I propose works. I'm doing it right now.

-- -- -- POST POST EDIT -- -- -- 

The Community Tech Tree does its patches into the Tech Tree on the LEGACY phase. So anyone using :BEFORE, :FOR or :AFTER will be good on it. It doesn't specifically mentions AirPlanePlus, so Unkerballed Start doesn't needs to try to preventing collisions to CTT, and it's reasonable to assume anyone else willing to second guess Unkerballed Start should do it's magic after it.

Edited by Lisias
POST POST EDIT
Link to post
Share on other sites
29 minutes ago, Lisias said:

Conflicts between incompatible add'ons (as another TechTree completely different from Unkerballed Start) would be better handled by another tool, perhaps on Unkerballed Start itself, checking on startup for incompatible add'ons or checking for its integrity and yelling if something is wrong.

This is something that would be better served on zzzUnkerballedStart:

UnkerballedStartPatchingErrors:FOR[zzzUnkerballedStart]
{
	error:NEEDS[UnkerballedStart,IncompatibleAddOn1,IncompatibleAddOn2] = "IncompatibleAddOn1 and IncompatibleAddOn2 were detected. You should choose only one of them, you can't have both installed"
	error:NEEDS[UnkerballedStart,IncompatibleAddOn3] = "IncompatibleAddOn3 was detected. This thing is imcompatible with Unkerballed Start, you need to remove it"
}

And then checking for any values named "error" on that node at startup.

@Lisias, Guessing this is pseudo-code or is there a mod that handles compatibility checking?

Link to post
Share on other sites
28 minutes ago, hemeac said:

@Lisias, Guessing this is pseudo-code or is there a mod that handles compatibility checking?

It's not a pseudo-code. It's a MM patch.

The aftermath (hopefully) will be a node on the GameDatabase with 0, 1 or 2 values (think on it as an array) called "error".

On the code, you read that node from GameDatabase and ir there are more then zero ocurrences of that value, you call a "Houston" and try to scare the user into fixing the problem.

Link to post
Share on other sites

I found a potential issue with Breaking Ground compatibility: The small head electric rotors (rotor_0*s) are missing from the patch. Moreover, they make way more sense in aviation tree, as their primary use is for electric rotorcraft - in fact that's the only use for rotors in the game period, everything else is better served by servos and wheels.

EDIT: Alternatively put them into "Stability", because another use for them - and the primary reason to make them available around the same time as helicopter blades and big turboshaft - is as tail rotors. currently there's no way to drive secondary rotors that are not connected to the main shaft in any other way than with electricity. I'm trying to make a mini mod that will avert that (essentially introducing excess power from the turboshaft engines as a weightless resource similar to electric charge that can only be used with special, clonned rotor parts) but as it is, those parts are necessary in vicinity of Early Aviation, otherwise the helicopter parts introduced there are useless - there's no way to build a stable helicopter with just those parts, unless you go for a tandem design (which has its own, massive issues, such as inability to yaw with just the rotors themselves due to how much the mechanics of rotor are simplified in BG.

Edited by m4ti140
Link to post
Share on other sites
On 8/30/2020 at 1:07 AM, kcs123 said:

What about people who don't have Making History DLC ? Will be :FOR command triggered properly ? Sorry, I didn't have time to inspect the rest of code. If MM in Making History config is ensured to be executed than it is all good, but something to be aware of if it is not a case.

Above is most probably not proper MM syntax, but should be enough to give you idea how it should work. Meaning, "ModCombination1" should exist only with certain combination of already installed mods and any additional patches on parts would be executed only if "ModCombination1" exist. @Lisias, would something like that help with current situation with ongoing race with :LAST/:FINAL MM commands between various mods that mess around with same parts ?

1. Yes it works. I tested UKS both with and without MH. :FOR is read by MM no matter what... which is why

On 8/30/2020 at 1:43 AM, Lisias said:

 

Why it needs to be done after zzzUnkerballedStart? Since you are adding support for an add'on, why not patching together it? There's no real hard dependency between Unkerballed Start and Airplane.

I would consider something like this:

@PART[CanardController,tailfin,sweptWing,R8winglet]:FOR[AirplanePlus]:NEEDS[UnkerballedStart,AirplanePlus,CommunityTechTree]
{
	@TechRequired = flight3
}

 

would be the absolute worst thing to do. The :FOR[AirplanePlus] would activate any patches that used :NEEDS, :BEFORE, :AFTER, or :LAST[AirplanePlus], causing who knows what kind of chaos. Especially in UKS, because a lot of things are moved around depending on whether or not APP is installed. :FOR is not dependent on :NEEDS, but it is the other way around. :FOR should only ever be used for it's own mod, never for any mod that patches or is dependent on it. So I could put :FOR[UnKerballedStart] or :FOR[zzzUnKerballedStart], but I had better not put :FOR[AnythingElseEver] in a config shipped with UKS. 

:BEFORE[zzzUnKerballedStart] is for the initial positioning of parts in the tech tree, as if it was the only mod the user had installed. :AFTER[zzzUnKerballedStart] will move the parts to places dependent on whether other mods are installed. For example, if NESD's mod OpenCockpits is installed, all other Mk1 inline cockpits, both stock and modded, are moved further up the tree.

If I had been writing the mod in the first place, I wouldn't have had the zzz's, but now that they are there and might be used by other mods or personal configs, I won't change it until 2.0.

On 8/30/2020 at 1:43 AM, Lisias said:

Conflicts between incompatible add'ons (as another TechTree completely different from Unkerballed Start) would be better handled by another tool, perhaps on Unkerballed Start itself, checking on startup for incompatible add'ons or checking for its integrity and yelling if something is wrong.

This is something that would be better served on zzzUnkerballedStart:

UnkerballedStartPatchingErrors:FOR[zzzUnkerballedStart]
{
	error:NEEDS[UnkerballedStart,IncompatibleAddOn1,IncompatibleAddOn2] = "IncompatibleAddOn1 and IncompatibleAddOn2 were detected. You should choose only one of them, you can't have both installed"
	error:NEEDS[UnkerballedStart,IncompatibleAddOn3] = "IncompatibleAddOn3 was detected. This thing is imcompatible with Unkerballed Start, you need to remove it"
}

And then checking for any values named "error" on that node at startup.

That's interesting. I've never seen ModuleManager used in that way. I'll have to look into it.

6 hours ago, m4ti140 said:

I found a potential issue with Breaking Ground compatibility: The small head electric rotors (rotor_0*s) are missing from the patch. Moreover, they make way more sense in aviation tree, as their primary use is for electric rotorcraft - in fact that's the only use for rotors in the game period, everything else is better served by servos and wheels.

EDIT: Alternatively put them into "Stability", because another use for them - and the primary reason to make them available around the same time as helicopter blades and big turboshaft - is as tail rotors. currently there's no way to drive secondary rotors that are not connected to the main shaft in any other way than with electricity. I'm trying to make a mini mod that will avert that (essentially introducing excess power from the turboshaft engines as a weightless resource similar to electric charge that can only be used with special, clonned rotor parts) but as it is, those parts are necessary in vicinity of Early Aviation, otherwise the helicopter parts introduced there are useless - there's no way to build a stable helicopter with just those parts, unless you go for a tandem design (which has its own, massive issues, such as inability to yaw with just the rotors themselves due to how much the mechanics of rotor are simplified in BG.

Thanks, I'll look into it for the next version.

Edited by theonegalen
Link to post
Share on other sites
2 hours ago, theonegalen said:

would be the absolute worst thing to do. The :FOR[AirplanePlus] would activate any patches that used :NEEDS, :BEFORE, :AFTER, or :LAST[AirplanePlus], causing who knows what kind of chaos. Especially in UKS, because a lot of things are moved around depending on whether or not APP is installed. :FOR is not dependent on :NEEDS, but it is the other way around. 

Nope. From the very MM documentation:

Quote

Patches are applied in the following order:

  1. Nodes with no operator ('insert') are loaded by the KSP GameDatabase first.
  2. Patches for modname values in NEEDS, BEFORE, AFTER, LAST that don't exist are removed.
  3. All patches with :FIRST are applied.
  4. All patches without an ordering directive (:FIRST, :BEFORE, :FOR, :AFTER, :LAST, :FINAL) are applied.
  5. For each item in the Unicode-sorted list of modname values:
    1. All patches with :BEFORE are applied
    2. All patches with :FOR are applied
    3. All patches with :AFTER are applied
  6. All patches with :LAST are applied
  7. All patches with :FINAL are applied

So, :FOR[AirplanePlus]:NEEDS[AirplanePlus,UnkerballedStart] will be plain removed if AirplanePlus or UnkerballedStart is not present, and will never have the change to create the tag on MM's data structures used on :FOR, :BEFORE, :AFTER and :LAST.

This can be easily verified using 3 simple configs:

Spoiler
[GameData/ModA/config.cfg]
PART
{
	name = ModA-Part
	title = This is the title of ModA.
}

[GameData/ModB/config.cfg]
@PART[this-does-not-exists]
{
	title = Just to force the ModB tag on th MM taglist
}

[GameData/ModC/config.cfg]
@PART[ModA-Part]:FOR[ModA]:NEEDS[ModA,ModB,ModC] // Using ModC in :NEEDS is pleonasm, as we are ModC and we are installed!
{
	@title ^= :$: And ModC was here!:
}

 

And the results:

Spoiler
[LOG 05:32:01.283] [ModuleManager] INFO: compiling list of loaded mods...
Mod DLLs found:
  Name                                    Assembly Version         Assembly File Version    KSPAssembly Version      SHA256

  Assembly-CSharp                         0.0.0.0                  0.0.0.0                                           434c492a25266f65c6f952ff06fc4ad0fc890fa648354779030b830c284d3e33
  KSPe                                    2.2.1.2                  2.2.1.2                  2.2                      c5483e1b14e39bbb261bcaf6bc1527e905ca154bf77b40f996894ad32e99fe3d
  ModuleManagerWatchDog                   0.0.1.0                  0.0.1.0                                           d6c3f815d21b5a010475468b15cfc5a9ef1df341c564fbd0a18226239e9459d5
  Scale_Redist                            1.0.0.0                  2.4.3.16                                          db4cabcab06a39d381eb9144a091c70b44f453dd4b59c3cdc7ffb4620847aa7c
  ModuleManager                           4.1.4.3                  4.1.4.3                  4.1                      2b7a928849c0560e827dc9beb5e296764ad8094e0d135136175472381c7f41b0
  KSPAPIExtensions                        2.2.1.2                  2.2.1.2                  2.2                      41676a0be0593816a97cc63dc99ceb637c44306628cabf385feb517c52d515d2
  KSPe.UI                                 2.2.1.2                  2.2.1.2                  2.2                      3b263d3716fb23ee5711eb103202125f1259149a6020ff95e52ab9d3c222d4ac
  KSPSteamCtrlr                           0.0.1.35                 0.0.1.35                                          70c884b63b0d5d913dff497fa8246934b21f13327934494966e6b0a5c15556e7
  Steamworks.NET                          9.0.0.0                  9.0.0                                             8d80c44126c0e241077bc384fd22fd8ee9cd709c2b166dc4947fda839930c46e
Non-DLL mods added (:FOR[xxx]):
  ModA
Mods by directory (sub directories of GameData):
  000_KSPAPIExtensions
  ModB
  ModC
  Squad
  __LOCAL

<cut>

  [LOG 05:33:42.278] [ModuleManager] INFO: Adding post patch to the loading screen 3
[LOG 05:33:42.910] [ModuleManager] Version 4.1.4.3 /L Experimental
[LOG 05:33:43.328] [ModuleManager] INFO: Calling KSPe.KSP.11.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 05:33:43.328] [ModuleManager] INFO: Calling KSPe.KSP.12.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 05:33:43.328] [ModuleManager] INFO: Calling KSPe.KSP.13.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 05:33:43.557] [ModuleManager] INFO: Checking Cache
[LOG 05:33:43.686] [ModuleManager] INFO: SHA generated in 0.126s
[LOG 05:33:43.686] [ModuleManager] INFO:       SHA = 31-67-89-FA-9E-DC-A3-3F-A8-CA-32-4F-80-44-D6-2A-8E-9C-A8-7E-31-3F-3A-57-1B-BE-9A-7D-FF-1F-02-CA
[LOG 05:33:43.688] [ModuleManager] INFO: Pre patch init
[LOG 05:33:43.822] [ModuleManager] INFO: compiling list of loaded mods...
[LOG 05:33:43.824] [ModuleManager] INFO: Loading Physics.cfg
[LOG 05:33:43.828] [ModuleManager] INFO: Extracting patches
[LOG 05:33:43.854] [ModuleManager] INFO: Applying patches
[LOG 05:33:43.856] [ModuleManager] INFO: :INSERT (initial) pass
[LOG 05:33:43.883] [ModuleManager] INFO: :FIRST pass
[LOG 05:33:43.883] [ModuleManager] INFO: :LEGACY (default) pass
[LOG 05:33:43.891] [ModuleManager] INFO: :BEFORE[__LOCAL] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :FOR[__LOCAL] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :AFTER[__LOCAL] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :BEFORE[000_KSPAPIEXTENSIONS] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :FOR[000_KSPAPIEXTENSIONS] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :AFTER[000_KSPAPIEXTENSIONS] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :BEFORE[ASSEMBLY-CSHARP] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :FOR[ASSEMBLY-CSHARP] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :AFTER[ASSEMBLY-CSHARP] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :BEFORE[KSP-1.1] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :FOR[KSP-1.1] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :AFTER[KSP-1.1] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :BEFORE[KSP-1.2] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :FOR[KSP-1.2] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :AFTER[KSP-1.2] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :BEFORE[KSP-1.3] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :FOR[KSP-1.3] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :AFTER[KSP-1.3] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :BEFORE[KSPAPIEXTENSIONS] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :FOR[KSPAPIEXTENSIONS] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :AFTER[KSPAPIEXTENSIONS] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :BEFORE[KSPE] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :FOR[KSPE] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :AFTER[KSPE] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :BEFORE[KSPE.UI] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :FOR[KSPE.UI] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :AFTER[KSPE.UI] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :BEFORE[KSPSTEAMCTRLR] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :FOR[KSPSTEAMCTRLR] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :AFTER[KSPSTEAMCTRLR] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :BEFORE[MODA] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :FOR[MODA] pass
[LOG 05:33:43.894] [ModuleManager] INFO: Applying update ModC/config/@PART[ModA-Part]:FOR[ModA]:NEEDS[ModA,ModB,ModC] to ModA/config.cfg/PART[ModA-Part]
[LOG 05:33:43.902] [ModuleManager] INFO: :AFTER[MODA] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :BEFORE[MODB] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :FOR[MODB] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :AFTER[MODB] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :BEFORE[MODC] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :FOR[MODC] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :AFTER[MODC] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :BEFORE[MODULEMANAGER] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :FOR[MODULEMANAGER] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :AFTER[MODULEMANAGER] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :BEFORE[MODULEMANAGERWATCHDOG] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :FOR[MODULEMANAGERWATCHDOG] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :AFTER[MODULEMANAGERWATCHDOG] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :BEFORE[SCALE_REDIST] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :FOR[SCALE_REDIST] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :AFTER[SCALE_REDIST] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :BEFORE[SQUAD] pass
[LOG 05:33:43.904] [ModuleManager] INFO: :FOR[SQUAD] pass
[LOG 05:33:43.904] [ModuleManager] INFO: :AFTER[SQUAD] pass
[LOG 05:33:43.904] [ModuleManager] INFO: :BEFORE[STEAMWORKS.NET] pass
[LOG 05:33:43.904] [ModuleManager] INFO: :FOR[STEAMWORKS.NET] pass
[LOG 05:33:43.904] [ModuleManager] INFO: :AFTER[STEAMWORKS.NET] pass
[LOG 05:33:43.904] [ModuleManager] INFO: :FINAL pass
[LOG 05:33:43.904] [ModuleManager] INFO: Done patching
[LOG 05:33:43.904] [ModuleManager] INFO: Saving Cache
[LOG 05:33:43.948] [ModuleManager] INFO: Saving cache
[LOG 05:33:44.091] [ModuleManager] INFO: ModuleManager: 1 patch applied
[LOG 05:33:44.091] [ModuleManager] INFO: Ran in 0.533s

 

And from ConfigCache:

UrlConfig
{
    parentUrl = ModA/config.cfg
    PART
    {
        name = ModA-Part
        title = This is the title of ModA. And ModC was here!
    }
}

 

However, now we need a counter-proof. Let's remove ModB from GameData and see what we get:

Spoiler
[LOG 05:43:38.816] [ModuleManager] INFO: Adding post patch to the loading screen 3
[LOG 05:43:39.366] [ModuleManager] Version 4.1.4.3 /L Experimental
[LOG 05:43:39.763] [ModuleManager] INFO: Calling KSPe.KSP.11.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 05:43:39.763] [ModuleManager] INFO: Calling KSPe.KSP.12.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 05:43:39.763] [ModuleManager] INFO: Calling KSPe.KSP.13.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 05:43:39.990] [ModuleManager] INFO: Checking Cache
[LOG 05:43:40.125] [ModuleManager] INFO: SHA generated in 0.132s
[LOG 05:43:40.125] [ModuleManager] INFO:       SHA = 4E-84-AD-6A-31-3F-75-2C-74-5C-DE-58-1B-09-44-5D-E6-0A-25-ED-60-53-AC-C3-D7-38-39-A2-14-45-5D-74
[LOG 05:43:40.131] [ModuleManager] INFO: ConfigSHA loaded
[LOG 05:43:40.139] [ModuleManager] INFO: Deleted : ModB/config.cfg.cfg
[LOG 05:43:40.139] [ModuleManager] INFO: Cache SHA = E5-96-5E-BB-19-5E-85-88-52-FA-38-07-6B-41-1D-C2-EA-19-37-12-C0-A6-9C-D8-32-C5-8D-F3-10-43-CD-4B
[LOG 05:43:40.139] [ModuleManager] INFO: useCache = False
[LOG 05:43:40.140] [ModuleManager] INFO: Pre patch init
[LOG 05:43:40.280] [ModuleManager] INFO: compiling list of loaded mods...
[LOG 05:43:40.281] [ModuleManager] INFO: Loading Physics.cfg
[LOG 05:43:40.285] [ModuleManager] INFO: Extracting patches
[LOG 05:43:40.301] [ModuleManager] INFO: Deleting root node in file ModC/config node: @PART[ModA-Part]:FOR[ModA]:NEEDS[ModA,ModB,ModC] as it can't satisfy its NEEDS
[LOG 05:43:40.311] [ModuleManager] INFO: Applying patches
[LOG 05:43:40.313] [ModuleManager] INFO: :INSERT (initial) pass
[LOG 05:43:40.339] [ModuleManager] INFO: :FIRST pass
[LOG 05:43:40.339] [ModuleManager] INFO: :LEGACY (default) pass
[LOG 05:43:40.340] [ModuleManager] INFO: :BEFORE[__LOCAL] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :FOR[__LOCAL] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :AFTER[__LOCAL] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :BEFORE[000_KSPAPIEXTENSIONS] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :FOR[000_KSPAPIEXTENSIONS] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :AFTER[000_KSPAPIEXTENSIONS] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :BEFORE[ASSEMBLY-CSHARP] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :FOR[ASSEMBLY-CSHARP] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :AFTER[ASSEMBLY-CSHARP] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :BEFORE[KSP-1.1] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :FOR[KSP-1.1] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :AFTER[KSP-1.1] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :BEFORE[KSP-1.2] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :FOR[KSP-1.2] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :AFTER[KSP-1.2] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :BEFORE[KSP-1.3] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :FOR[KSP-1.3] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :AFTER[KSP-1.3] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :BEFORE[KSPAPIEXTENSIONS] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :FOR[KSPAPIEXTENSIONS] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :AFTER[KSPAPIEXTENSIONS] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :BEFORE[KSPE] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[KSPE] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[KSPE] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[KSPE.UI] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[KSPE.UI] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[KSPE.UI] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[KSPSTEAMCTRLR] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[KSPSTEAMCTRLR] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[KSPSTEAMCTRLR] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[MODA] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[MODA] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[MODA] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[MODC] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[MODC] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[MODC] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[MODULEMANAGER] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[MODULEMANAGER] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[MODULEMANAGER] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[MODULEMANAGERWATCHDOG] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[MODULEMANAGERWATCHDOG] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[MODULEMANAGERWATCHDOG] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[SCALE_REDIST] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[SCALE_REDIST] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :AFTER[SCALE_REDIST] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :BEFORE[SQUAD] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :FOR[SQUAD] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :AFTER[SQUAD] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :BEFORE[STEAMWORKS.NET] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :FOR[STEAMWORKS.NET] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :AFTER[STEAMWORKS.NET] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :FINAL pass
[LOG 05:43:40.343] [ModuleManager] INFO: Done patching
[LOG 05:43:40.343] [ModuleManager] INFO: Saving Cache
[LOG 05:43:40.384] [ModuleManager] INFO: Saving cache
[LOG 05:43:40.509] [ModuleManager] INFO: ModuleManager: 0 patches applied (0 %)
[LOG 05:43:40.509] [ModuleManager] INFO: Ran in 0.518s

 

And on the ConfigCache:

UrlConfig
{
    parentUrl = ModA/config.cfg
    PART
    {
        name = ModA-Part
        title = This is the title of ModA.
    }
}

 

So, yeah. The stunt works fine.

As we can easily verify, there're no real dependencies between :FOR and :NEEDS. All we have is a clever sequence of well defined actions taken on well defined phases of the patching process.

"Source Code" and evidences of the thing working as I say it does on KSP 1.3.1 and 1.10.1 (I considered testing on more KSP versions unneeded) are on my github - so anyone can easily check him/herself .  @R-T-B, I think this will interest you.

 

Link to post
Share on other sites
11 hours ago, Lisias said:

Nope. From the very MM documentation:

So, :FOR[AirplanePlus]:NEEDS[AirplanePlus,UnkerballedStart] will be plain removed if AirplanePlus or UnkerballedStart is not present, and will never have the change to create the tag on MM's data structures used on :FOR, :BEFORE, :AFTER and :LAST.

This can be easily verified using 3 simple configs:

  Hide contents

[GameData/ModA/config.cfg]
PART
{
	name = ModA-Part
	title = This is the title of ModA.
}

[GameData/ModB/config.cfg]
@PART[this-does-not-exists]
{
	title = Just to force the ModB tag on th MM taglist
}

[GameData/ModC/config.cfg]
@PART[ModA-Part]:FOR[ModA]:NEEDS[ModA,ModB,ModC] // Using ModC in :NEEDS is pleonasm, as we are ModC and we are installed!
{
	@title ^= :$: And ModC was here!:
}

 

And the results:

  Reveal hidden contents

[LOG 05:32:01.283] [ModuleManager] INFO: compiling list of loaded mods...
Mod DLLs found:
  Name                                    Assembly Version         Assembly File Version    KSPAssembly Version      SHA256

  Assembly-CSharp                         0.0.0.0                  0.0.0.0                                           434c492a25266f65c6f952ff06fc4ad0fc890fa648354779030b830c284d3e33
  KSPe                                    2.2.1.2                  2.2.1.2                  2.2                      c5483e1b14e39bbb261bcaf6bc1527e905ca154bf77b40f996894ad32e99fe3d
  ModuleManagerWatchDog                   0.0.1.0                  0.0.1.0                                           d6c3f815d21b5a010475468b15cfc5a9ef1df341c564fbd0a18226239e9459d5
  Scale_Redist                            1.0.0.0                  2.4.3.16                                          db4cabcab06a39d381eb9144a091c70b44f453dd4b59c3cdc7ffb4620847aa7c
  ModuleManager                           4.1.4.3                  4.1.4.3                  4.1                      2b7a928849c0560e827dc9beb5e296764ad8094e0d135136175472381c7f41b0
  KSPAPIExtensions                        2.2.1.2                  2.2.1.2                  2.2                      41676a0be0593816a97cc63dc99ceb637c44306628cabf385feb517c52d515d2
  KSPe.UI                                 2.2.1.2                  2.2.1.2                  2.2                      3b263d3716fb23ee5711eb103202125f1259149a6020ff95e52ab9d3c222d4ac
  KSPSteamCtrlr                           0.0.1.35                 0.0.1.35                                          70c884b63b0d5d913dff497fa8246934b21f13327934494966e6b0a5c15556e7
  Steamworks.NET                          9.0.0.0                  9.0.0                                             8d80c44126c0e241077bc384fd22fd8ee9cd709c2b166dc4947fda839930c46e
Non-DLL mods added (:FOR[xxx]):
  ModA
Mods by directory (sub directories of GameData):
  000_KSPAPIExtensions
  ModB
  ModC
  Squad
  __LOCAL

<cut>

  [LOG 05:33:42.278] [ModuleManager] INFO: Adding post patch to the loading screen 3
[LOG 05:33:42.910] [ModuleManager] Version 4.1.4.3 /L Experimental
[LOG 05:33:43.328] [ModuleManager] INFO: Calling KSPe.KSP.11.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 05:33:43.328] [ModuleManager] INFO: Calling KSPe.KSP.12.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 05:33:43.328] [ModuleManager] INFO: Calling KSPe.KSP.13.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 05:33:43.557] [ModuleManager] INFO: Checking Cache
[LOG 05:33:43.686] [ModuleManager] INFO: SHA generated in 0.126s
[LOG 05:33:43.686] [ModuleManager] INFO:       SHA = 31-67-89-FA-9E-DC-A3-3F-A8-CA-32-4F-80-44-D6-2A-8E-9C-A8-7E-31-3F-3A-57-1B-BE-9A-7D-FF-1F-02-CA
[LOG 05:33:43.688] [ModuleManager] INFO: Pre patch init
[LOG 05:33:43.822] [ModuleManager] INFO: compiling list of loaded mods...
[LOG 05:33:43.824] [ModuleManager] INFO: Loading Physics.cfg
[LOG 05:33:43.828] [ModuleManager] INFO: Extracting patches
[LOG 05:33:43.854] [ModuleManager] INFO: Applying patches
[LOG 05:33:43.856] [ModuleManager] INFO: :INSERT (initial) pass
[LOG 05:33:43.883] [ModuleManager] INFO: :FIRST pass
[LOG 05:33:43.883] [ModuleManager] INFO: :LEGACY (default) pass
[LOG 05:33:43.891] [ModuleManager] INFO: :BEFORE[__LOCAL] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :FOR[__LOCAL] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :AFTER[__LOCAL] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :BEFORE[000_KSPAPIEXTENSIONS] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :FOR[000_KSPAPIEXTENSIONS] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :AFTER[000_KSPAPIEXTENSIONS] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :BEFORE[ASSEMBLY-CSHARP] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :FOR[ASSEMBLY-CSHARP] pass
[LOG 05:33:43.891] [ModuleManager] INFO: :AFTER[ASSEMBLY-CSHARP] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :BEFORE[KSP-1.1] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :FOR[KSP-1.1] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :AFTER[KSP-1.1] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :BEFORE[KSP-1.2] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :FOR[KSP-1.2] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :AFTER[KSP-1.2] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :BEFORE[KSP-1.3] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :FOR[KSP-1.3] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :AFTER[KSP-1.3] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :BEFORE[KSPAPIEXTENSIONS] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :FOR[KSPAPIEXTENSIONS] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :AFTER[KSPAPIEXTENSIONS] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :BEFORE[KSPE] pass
[LOG 05:33:43.892] [ModuleManager] INFO: :FOR[KSPE] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :AFTER[KSPE] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :BEFORE[KSPE.UI] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :FOR[KSPE.UI] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :AFTER[KSPE.UI] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :BEFORE[KSPSTEAMCTRLR] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :FOR[KSPSTEAMCTRLR] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :AFTER[KSPSTEAMCTRLR] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :BEFORE[MODA] pass
[LOG 05:33:43.893] [ModuleManager] INFO: :FOR[MODA] pass
[LOG 05:33:43.894] [ModuleManager] INFO: Applying update ModC/config/@PART[ModA-Part]:FOR[ModA]:NEEDS[ModA,ModB,ModC] to ModA/config.cfg/PART[ModA-Part]
[LOG 05:33:43.902] [ModuleManager] INFO: :AFTER[MODA] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :BEFORE[MODB] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :FOR[MODB] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :AFTER[MODB] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :BEFORE[MODC] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :FOR[MODC] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :AFTER[MODC] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :BEFORE[MODULEMANAGER] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :FOR[MODULEMANAGER] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :AFTER[MODULEMANAGER] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :BEFORE[MODULEMANAGERWATCHDOG] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :FOR[MODULEMANAGERWATCHDOG] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :AFTER[MODULEMANAGERWATCHDOG] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :BEFORE[SCALE_REDIST] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :FOR[SCALE_REDIST] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :AFTER[SCALE_REDIST] pass
[LOG 05:33:43.903] [ModuleManager] INFO: :BEFORE[SQUAD] pass
[LOG 05:33:43.904] [ModuleManager] INFO: :FOR[SQUAD] pass
[LOG 05:33:43.904] [ModuleManager] INFO: :AFTER[SQUAD] pass
[LOG 05:33:43.904] [ModuleManager] INFO: :BEFORE[STEAMWORKS.NET] pass
[LOG 05:33:43.904] [ModuleManager] INFO: :FOR[STEAMWORKS.NET] pass
[LOG 05:33:43.904] [ModuleManager] INFO: :AFTER[STEAMWORKS.NET] pass
[LOG 05:33:43.904] [ModuleManager] INFO: :FINAL pass
[LOG 05:33:43.904] [ModuleManager] INFO: Done patching
[LOG 05:33:43.904] [ModuleManager] INFO: Saving Cache
[LOG 05:33:43.948] [ModuleManager] INFO: Saving cache
[LOG 05:33:44.091] [ModuleManager] INFO: ModuleManager: 1 patch applied
[LOG 05:33:44.091] [ModuleManager] INFO: Ran in 0.533s

 

And from ConfigCache:

UrlConfig
{
    parentUrl = ModA/config.cfg
    PART
    {
        name = ModA-Part
        title = This is the title of ModA. And ModC was here!
    }
}

 

However, now we need a counter-proof. Let's remove ModB from GameData and see what we get:

  Reveal hidden contents

[LOG 05:43:38.816] [ModuleManager] INFO: Adding post patch to the loading screen 3
[LOG 05:43:39.366] [ModuleManager] Version 4.1.4.3 /L Experimental
[LOG 05:43:39.763] [ModuleManager] INFO: Calling KSPe.KSP.11.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 05:43:39.763] [ModuleManager] INFO: Calling KSPe.KSP.12.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 05:43:39.763] [ModuleManager] INFO: Calling KSPe.KSP.13.ModuleManagerSupport.ModuleManagerAddToModList()
[LOG 05:43:39.990] [ModuleManager] INFO: Checking Cache
[LOG 05:43:40.125] [ModuleManager] INFO: SHA generated in 0.132s
[LOG 05:43:40.125] [ModuleManager] INFO:       SHA = 4E-84-AD-6A-31-3F-75-2C-74-5C-DE-58-1B-09-44-5D-E6-0A-25-ED-60-53-AC-C3-D7-38-39-A2-14-45-5D-74
[LOG 05:43:40.131] [ModuleManager] INFO: ConfigSHA loaded
[LOG 05:43:40.139] [ModuleManager] INFO: Deleted : ModB/config.cfg.cfg
[LOG 05:43:40.139] [ModuleManager] INFO: Cache SHA = E5-96-5E-BB-19-5E-85-88-52-FA-38-07-6B-41-1D-C2-EA-19-37-12-C0-A6-9C-D8-32-C5-8D-F3-10-43-CD-4B
[LOG 05:43:40.139] [ModuleManager] INFO: useCache = False
[LOG 05:43:40.140] [ModuleManager] INFO: Pre patch init
[LOG 05:43:40.280] [ModuleManager] INFO: compiling list of loaded mods...
[LOG 05:43:40.281] [ModuleManager] INFO: Loading Physics.cfg
[LOG 05:43:40.285] [ModuleManager] INFO: Extracting patches
[LOG 05:43:40.301] [ModuleManager] INFO: Deleting root node in file ModC/config node: @PART[ModA-Part]:FOR[ModA]:NEEDS[ModA,ModB,ModC] as it can't satisfy its NEEDS
[LOG 05:43:40.311] [ModuleManager] INFO: Applying patches
[LOG 05:43:40.313] [ModuleManager] INFO: :INSERT (initial) pass
[LOG 05:43:40.339] [ModuleManager] INFO: :FIRST pass
[LOG 05:43:40.339] [ModuleManager] INFO: :LEGACY (default) pass
[LOG 05:43:40.340] [ModuleManager] INFO: :BEFORE[__LOCAL] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :FOR[__LOCAL] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :AFTER[__LOCAL] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :BEFORE[000_KSPAPIEXTENSIONS] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :FOR[000_KSPAPIEXTENSIONS] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :AFTER[000_KSPAPIEXTENSIONS] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :BEFORE[ASSEMBLY-CSHARP] pass
[LOG 05:43:40.340] [ModuleManager] INFO: :FOR[ASSEMBLY-CSHARP] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :AFTER[ASSEMBLY-CSHARP] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :BEFORE[KSP-1.1] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :FOR[KSP-1.1] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :AFTER[KSP-1.1] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :BEFORE[KSP-1.2] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :FOR[KSP-1.2] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :AFTER[KSP-1.2] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :BEFORE[KSP-1.3] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :FOR[KSP-1.3] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :AFTER[KSP-1.3] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :BEFORE[KSPAPIEXTENSIONS] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :FOR[KSPAPIEXTENSIONS] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :AFTER[KSPAPIEXTENSIONS] pass
[LOG 05:43:40.341] [ModuleManager] INFO: :BEFORE[KSPE] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[KSPE] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[KSPE] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[KSPE.UI] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[KSPE.UI] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[KSPE.UI] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[KSPSTEAMCTRLR] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[KSPSTEAMCTRLR] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[KSPSTEAMCTRLR] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[MODA] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[MODA] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[MODA] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[MODC] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[MODC] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[MODC] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[MODULEMANAGER] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[MODULEMANAGER] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[MODULEMANAGER] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[MODULEMANAGERWATCHDOG] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[MODULEMANAGERWATCHDOG] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :AFTER[MODULEMANAGERWATCHDOG] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :BEFORE[SCALE_REDIST] pass
[LOG 05:43:40.342] [ModuleManager] INFO: :FOR[SCALE_REDIST] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :AFTER[SCALE_REDIST] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :BEFORE[SQUAD] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :FOR[SQUAD] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :AFTER[SQUAD] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :BEFORE[STEAMWORKS.NET] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :FOR[STEAMWORKS.NET] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :AFTER[STEAMWORKS.NET] pass
[LOG 05:43:40.343] [ModuleManager] INFO: :FINAL pass
[LOG 05:43:40.343] [ModuleManager] INFO: Done patching
[LOG 05:43:40.343] [ModuleManager] INFO: Saving Cache
[LOG 05:43:40.384] [ModuleManager] INFO: Saving cache
[LOG 05:43:40.509] [ModuleManager] INFO: ModuleManager: 0 patches applied (0 %)
[LOG 05:43:40.509] [ModuleManager] INFO: Ran in 0.518s

 

And on the ConfigCache:

UrlConfig
{
    parentUrl = ModA/config.cfg
    PART
    {
        name = ModA-Part
        title = This is the title of ModA.
    }
}

 

So, yeah. The stunt works fine.

As we can easily verify, there're no real dependencies between :FOR and :NEEDS. All we have is a clever sequence of well defined actions taken on well defined phases of the patching process.

"Source Code" and evidences of the thing working as I say it does on KSP 1.3.1 and 1.10.1 (I considered testing on more KSP versions unneeded) are on my github - so anyone can easily check him/herself .  @R-T-B, I think this will interest you.

 

You are looking at the wrong page of the MM documentation. Here in https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax:

Quote

The stuff within the needs section is based on either:

  • A plugin .dll with the same assembly name.
  • A subdirectory name under GameData. (Names with spaces can be used, just remove the spaces: GameData/My Mod/ => :NEEDS[MyMod]
  • A FOR[Blah] defined would allow NEEDS[Blah]

 

Link to post
Share on other sites
2 hours ago, theonegalen said:

A FOR[Blah] defined would allow NEEDS[Blah]

I don't believe this functionality happens when you think it happens.

1. ALL configs are loaded regardless.

2. Configs are parsed for unmet :NEEDS

3. Those configs are discarded.

4. MM begins processing configs and the :FOR conditional now starts declaring.

So, as described, a config with :NEEDS[modA]:FOR[modA] will only be processed if modA is present.  If not, it will be discarded BEFORE being parsed by MM and the :FOR declaring a non-existent mod present.

That said, if anyone else uses :FOR[modA], modA WILL be recognized ... but it won't be you're doing.

 

Link to post
Share on other sites
3 hours ago, theonegalen said:

You are looking at the wrong page of the MM documentation. Here in https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax:

You are not looking at all. I had read the source, I had backported MM to 1.3.1 (1.2.2 in progress).

And I had wrote a well documented Proof of Concept.

It works exactly as I say it does.

Additionally, I strongly suggest you read the material you link yourself. The very page you linked says:

Quote

Patch order

The BEFORE, FOR, and AFTER keywords can be used to control in what order your patch is applied. See this page for details.

Where "this page" is the page I linked above, and you claimed it's the wrong page to read. :)

It's a step away from the current Comfort Zone, no double. But yet, there are plenty evidences above proving that you are wrong about the way you think things work on MM. It's time to reassess the situation.

Go to the github repo I linked. Test it. Try to prove me wrong. Try to find a situation where that stunt could be harmful. I'm not asking you to believe in me, I'm inviting you to check what I'm saying.

Link to post
Share on other sites

@kcs123 In regards to this snippet, this is not how MM works. If it does work, do let me know, otherwise, this is a recipe for bad behavior from MM.

// detect combination of already installed mods
@something[]:NEEDS[ModName1,ModName2]
{
    // declare new name that MM is aware of and that can be used for other patches
    :FOR[ModCombination1]
}

 

@Lisias regarding your proposal here, I'll have you know that :FOR does two jobs. It sets the order that a given patch runs, but it also declares that the given mod is installed so it should never be used if you don't own that mod.

@PART[CanardController,tailfin,sweptWing,R8winglet]:FOR[AirplanePlus]:NEEDS[UnkerballedStart,AirplanePlus,CommunityTechTree]
{
    @TechRequired = flight3
}

This patch is self-confirming (and therefore, a very bad example) because the needed mod is given in the FOR. FOR says "I exist" which meets the NEEDS.

 

UnkerballedStartPatchingErrors:FOR[zzzUnkerballedStart]
{
    error:NEEDS[UnkerballedStart,IncompatibleAddOn1,IncompatibleAddOn2] = "IncompatibleAddOn1 and IncompatibleAddOn2 were detected. You should choose only one of them, you can't have both installed"
    error:NEEDS[UnkerballedStart,IncompatibleAddOn3] = "IncompatibleAddOn3 was detected. This thing is imcompatible with Unkerballed Start, you need to remove it"
}

This looks like good syntax. I'm confident that this will work correctly.

With regard to this sample piece:

@PART[CanardController|tailfin|sweptWing|R8winglet]:NEEDS[CommunityTechTree]:AFTER[zzzUnKerballedStart]
{
    @TechRequired = flight3
}

That's perfectly fine. :AFTER includes the function of :NEEDS. But assuming these are stock parts, the AFTER segment isn't necessary. :FOR[UnkerballedStart] is implied by the patch merely existing inside the UnkerballedStart folder in GameData. Otherwise, that patch should be be changed to:

@PART[CanardController|tailfin|sweptWing|R8winglet]:AFTER[CommunityTechTree]
{
    @TechRequired = flight3
}

 

Quote

Well, as far as I know UKS does not really need another directory with "zzz" prefix. It already got "UnkerballedStart" directory. So, it can use it as advantage where needed. Somewhere might be enough to have just "UnkerballedStart" in MM BEFORE/AFTER commands.

@kcs123 You are correct. Having a "zzzUnKerballedStart" pseudo-mod is largely unneeded. Alphanumerically, this mod is already positioned to have any patches it carries run after nearly every other mod within the LEGACY pass (before the BEFORE, FOR, AFTER passes, and barring the use of LAST, FINAL and FOR[zzz]). Furthermore, this mod is primarily a tech tree mod, mutually exclusive with other tech tree mods, so there should be no competition to prepare for, and there should be no need to have more than one z, or, such passes can be replaced with :LAST[UnkerballedStart]. This is why :LAST exists. (Granted @theonegalen owns this mod I respect where he knows or believes that competitive patching is still needed.)

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...