theonegalen Posted August 29, 2020 Share Posted August 29, 2020 (edited) Unkerballed Start - Happy New Year! v1.3.1 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) 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 BlueDog Design Bureau (early tree only) CryoEngines CryoTanks Deadly Reentry DMagic Orbital Science Freyja Fuel Tanks Plus Interstellar Extended KAX Kerbalism Kerbonov KNES kOS KW Rocketry Luciole 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 2USI Life Support X-20 Recommended Mods Making History - Official Expansion Missing History - Adds the parts that Making History missedRestock 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 Purpose, Bases 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 usesClever SatsKerbal AcademyBases and Stations RebornRemote Tech Contracts - currently not working. Unofficial fix HERERover Missions ReduxTourism PlusGiving Aircraft a PurposeField Research I also use Kerbal Construction Time, Snacks!, Bureaucracy and highly recommend BARIS or EVA Repairs 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 ---AdjustableModPanelAlternateResourcePanelBAMContBackgroundResourcesCapComChattererClickThroughBlockerCollisionFXUpdatedCommunityCategoryKitCommunityResourcePackCommunityTechTreeContractConfiguratorContractConfigurator-CleverSatsContractConfigurator-FieldResearchContractConfigurator-KerbalAcademyContractConfigurator-KerbinSpaceStationContractConfigurator-RemoteTechContractConfigurator-TourismContractParserContract_Pack_Rover_MissionsCustomBarnKitDMagicOrbitalScienceDeadlyReentryDistantObjectDistantObject-defaultEarnYourStripesEditorExtensionsReduxEngineLightingEnvironmentalVisualEnhancementsFerramAerospaceResearchContinuedFilterExtensionsFilterExtensionsDefaultConfigFinalFrontierFlightTrackerIndicatorLightsIndicatorLightsCommunityExtensionsJanitorsClosetKSP-AVCKerbalAlarmClockKerbalChangelogKerbalConstructionTimeKerbalEngineerReduxMK1StkOpenCockpitMagiCoreMakingLessHistoryMandatoryRCSMemGraphMemorialWallMissingHistoryMoarFEConfigsModularFlightIntegratorModuleManagerMonthlyBudgetsMyTweaks*OhScrap Orion (Stockish Project Orion)PartInfoPoodsCalmNebulaSkyboxProgressParserreDIRECT ReStockReStockPlus ReStockRigidLegsRealPlumeRealPlume-StockConfigsReentryParticleEffectRemoteTechSCANsatSETI-ContractsScattererScatterer-configScatterer-sunflareSciFiVisualEnhancementsScienceSituationInfoScrapYardSigmaReplacements-SkyBoxSmokeScreenSOCK SpaceAgeStageRecoveryStockNoContractsStrategiaTACLSTextureReplacerToolbarControllerTriggerAu-FlagsUnKerballedStartkOSx.Science Changelog: 1.3.1 Hotfix to fix the position of the bottom node on the LVT-05 when Restock is installed. Thanks to Graploos on KSP forums for the bug report. 1.3.0 Update for KSP 1.12.2 Fix LVT05 and LVT10 Engines not showing up with ReStock (again - thanks to multiple people who kept them going while I was away, especially @kcs123 and @hermano) Fix LVT05 and LVT10 Engine Drag Cubes and added compatibility for Waterfall and Rocket Sound Enhancement (thanks to @hermano for the configs!) Fix spelling of Unresearcheable to match SQUAD code Added .netkan file to make things convenient for CKAN users Updated version file for KSP-AVC users Updated configs for stock and Making History Updated config for ReStock+ (thanks to ahmedcharles on github for PR!) Added configs for @Well's mods KNES, Luciole, and X-20 (thanks to @Clamp-o-Tron for PR!) Added config for @SuicidalInsanity's Stockish Project Orion (thanks to @Clamp-o-Tron for PR!) Added configs for @benjee10's reDIRECT and SOCK (thanks to @Clamp-o-Tron for PR!) Added configs for @Nertea's RestockRigidLegs, CryoEngines, and CryoTanks (thanks to ahmedcharles on github for PR!) Added config for @CobaltWolf's BlueDog Design Bureau (incomplete - thanks to @Gordon Dry for PR!) Old changelog: Spoiler 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 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 January 21, 2022 by theonegalen mod update Quote Link to comment Share on other sites More sharing options...
hemeac Posted August 29, 2020 Share Posted August 29, 2020 @theonegalen Congrats on getting this up and running again. Quote Link to comment Share on other sites More sharing options...
pllsr Posted August 29, 2020 Share Posted August 29, 2020 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. Quote Link to comment Share on other sites More sharing options...
Morphisor Posted August 29, 2020 Share Posted August 29, 2020 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. Quote Link to comment Share on other sites More sharing options...
theonegalen Posted August 29, 2020 Author Share Posted August 29, 2020 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 Reborn. Field 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. Quote Link to comment Share on other sites More sharing options...
Nori Posted August 29, 2020 Share Posted August 29, 2020 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 Reborn. Field 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... Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted August 29, 2020 Share Posted August 29, 2020 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. Quote Link to comment Share on other sites More sharing options...
Lisias Posted August 30, 2020 Share Posted August 30, 2020 (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. Quote Link to comment Share on other sites More sharing options...
gunt3rgam3r Posted August 30, 2020 Share Posted August 30, 2020 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. Quote Link to comment Share on other sites More sharing options...
kcs123 Posted August 30, 2020 Share Posted August 30, 2020 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 ? Quote Link to comment Share on other sites More sharing options...
Lisias Posted August 30, 2020 Share Posted August 30, 2020 (edited) 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 August 30, 2020 by Lisias POST POST EDIT Quote Link to comment Share on other sites More sharing options...
hemeac Posted August 30, 2020 Share Posted August 30, 2020 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? Quote Link to comment Share on other sites More sharing options...
Lisias Posted August 30, 2020 Share Posted August 30, 2020 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. Quote Link to comment Share on other sites More sharing options...
dylsh Posted August 30, 2020 Share Posted August 30, 2020 I am so thrilled for this return. I put KSP down for quite a while. This mod has become essential for me to have a play through. Thank you so much, you are a Scholar and a Gentleman. Quote Link to comment Share on other sites More sharing options...
m4ti140 Posted September 2, 2020 Share Posted September 2, 2020 (edited) 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 September 3, 2020 by m4ti140 Quote Link to comment Share on other sites More sharing options...
theonegalen Posted September 3, 2020 Author Share Posted September 3, 2020 (edited) 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 September 3, 2020 by theonegalen Quote Link to comment Share on other sites More sharing options...
Gojira Posted September 3, 2020 Share Posted September 3, 2020 Any hope for BDB support? Quote Link to comment Share on other sites More sharing options...
Clamp-o-Tron Posted September 3, 2020 Share Posted September 3, 2020 I am planning to do bdb when tantares is finished, if nobody else steps up. Quote Link to comment Share on other sites More sharing options...
Gojira Posted September 3, 2020 Share Posted September 3, 2020 Awesome. Quote Link to comment Share on other sites More sharing options...
Lisias Posted September 3, 2020 Share Posted September 3, 2020 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: Nodes with no operator ('insert') are loaded by the KSP GameDatabase first. Patches for modname values in NEEDS, BEFORE, AFTER, LAST that don't exist are removed. All patches with :FIRST are applied. All patches without an ordering directive (:FIRST, :BEFORE, :FOR, :AFTER, :LAST, :FINAL) are applied. For each item in the Unicode-sorted list of modname values: All patches with :BEFORE are applied All patches with :FOR are applied All patches with :AFTER are applied All patches with :LAST are applied 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. Quote Link to comment Share on other sites More sharing options...
R-T-B Posted September 3, 2020 Share Posted September 3, 2020 I may need more caffeine to read that. I'll be back later. Quote Link to comment Share on other sites More sharing options...
theonegalen Posted September 3, 2020 Author Share Posted September 3, 2020 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] Quote Link to comment Share on other sites More sharing options...
TranceaddicT Posted September 4, 2020 Share Posted September 4, 2020 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. Quote Link to comment Share on other sites More sharing options...
Lisias Posted September 4, 2020 Share Posted September 4, 2020 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. Quote Link to comment Share on other sites More sharing options...
JadeOfMaar Posted September 4, 2020 Share Posted September 4, 2020 @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.) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.