Jump to content

TranceaddicT

Members
 View Profile  See their activity

  • Posts

    730

  • Joined

  • Last visited

 Content Type 

Everything posted by TranceaddicT

  1. TranceaddicT
    @etmoonshade Sorry, best I've got for you is to do what you probably already do. 1. copy the patches that do what you don't want, 2. revert the values you don't like, 3. Tag as :FINAL.
  2. TranceaddicT
    To disable/prevent loading, no. MM loads every patch it finds from the get go. Then, it proceeds to dismiss those patches for which there are unmet :NEEDS. Can you give me an example of KSPIE-NF you find bothersome? I haven't used it so I'm not familiar. Also, if I may so bold, if you're maintaining a singular MMConfig that can get difficult to manage. I create a folder '__myLOCAL' with an internal structure which mirrors /GameData. Each patch only addresses one issue for that mod. /GameData ../mmyLOCAL ../../ModA ../../ModB ../ModA ../ModB
  3. TranceaddicT
    This. Revel in your wrongness, own it.
  4. TranceaddicT
    WTH is your thrust-to-weight ratio????
  5. TranceaddicT
    More wrongness
  6. TranceaddicT
    Oh, don't misunderstand me. It's funny. It's even fookin' funny. It's still wrong.
  7. TranceaddicT
    True, but it so depends on what you want to do. If you're just checking for it to be there, before pushing the module, yeah. But, you really want a sequential patch. @PART[*]:HAS[MODULE[kOSProcessor]]:NEEDS[Gobbledegook] { %diskSpace = 10000 %ECPerBytePerSecond = 0.00001 %ECPerInstruction = 0.000008 } @PART[*]:HAS[!MODULE[kOSProcessor]]:NEEDS[Gobbledegook] { %MODULE { %name = kOSProcessor %diskSpace = 10000 %ECPerBytePerSecond = 0.00001 %ECPerInstruction = 0.000008 } }
  8. TranceaddicT
    That's just wrong.
  9. TranceaddicT
    For module checking you want to use something like this: @PART[*]:HAS[MODULE [kOSProcessor]{ }
  10. TranceaddicT
    FYI, CKAN will track (as auto-detected, "AD") those mods. I will notify you when they get updated in CKAN's database. Then, you can right-click to reinstall the tracked version.
  11. TranceaddicT
    Your should remove it. If you get any warnings or complaints about Module[Resourceful], they can be safely disregarded.
  12. TranceaddicT
    CKAN, SpaceDock and GitHub will all tell you which version this is currently available for.
  13. TranceaddicT
    What I think is not exactly ideal. IMHO Add'On tags should be directory agnostic - or, at least, should exist a way to overrule this (like that :THIS of mine). Yeah, this is legacy behaviour from when MM was first conceived. Then:FOR guy added and then things got complicated. There are still patches out there with no conditionals and they get processed before anything else. So, no TS installed? If that is the case, that's an unintended consequence. My understanding is if there's declared mod.dll or no folder, then the :NEEDS condition hasn't been met and the patch should be discarded. What you described, means the :BEFORE,:FOR and :AFTER conditionals are being evaluated as they're being loaded and module manager is making the declaration for them. Ah, okay, now what you said makes more sense. This is where we diverged. It may be time to review the legacy behavior. MM had been around long enough that :FOR can be reimplemented to act as it intuitively should - a positional pointer between :BEFORE & :AFTER. And, as a result, could make way for introducing a :THIS conditional.
  14. TranceaddicT
    :FOR[TweakScale]:NEEDS[TweakScale] will never happen. The 1st thing module manager does is initial load every patch that is in GameData. The 2nd thing it does is discard every patch which has a :NEEDS conditional that is not met. Only then does it begin applying patches. Another trick module manager does is it considers a directory folder to be a mod. So, the folder GameData/TweakScaleCompanion is considered mod by module manager. This is the reason a personal mod folder (for me, zzzzzAS_KSPMods) got processed. Being an end-user, dude with :FOR[TweakScale]:NEEDS[TweakScale] should be using :NEEDS[TweakScale]:FINAL to ensure his is the last patch ever. I think the use case you presented is better suited to mods with companion-style directory hierarchies, like TweakScale. Because TweakScale has complementary configuration patches which exist SEPARATE from the core module itself, you're use case is better applied :FOR[TweakScaleCompanion/ABC]:NEEDS[TweakScale] (yeah, it can parse subdirectories.) That also solves your :THIS situation.
  15. TranceaddicT
    Pictures, or it didn't happen.
  16. TranceaddicT
    MS Edge is chromium-based, so yeah it should exhibit the save behavior Chrome does. (SIDENOTE: Since their codebase i are the same, you can load Chrome Webstore extensions into Edge.)
  17. TranceaddicT
    Yeah, about that :FOR milestone. I think you should probably be going for :NEEDS. The strange thing about the :BEFORE > :FOR > :AFTER sequence ... only :FOR will cause a non-installed mod to be recognized as if it IS installed. So this is a bad arrangement: authorModB will not create a new part because of authorModA's :FOR[FooBar]. authorModA has a MMConfig: @PART[authorModA]:FOR[FooBar] {} authorModB has a MMConfig: +PART[authorModB]:NEEDS[!FooBar] {} This is a good arrangement: authorModB will create a new part because of authorModA's :FOR[FooBar]. authorModA has a MMConfig: @PART[authorModA]:NEEDS[FooBar] {} authorModB has a MMConfig: +PART[authorModB]:NEEDS[!FooBar] {}
  18. TranceaddicT
    TbF, ":LAST" is a new passSpecifier. It was introduced in Jan 2020, so ...
  19. TranceaddicT
    Patching commits in this order: :FIRST :Remove unmet NEEDS, :BEFORE, :AFTER, :LAST LEGACY (no ordering) patching :BEFORE :FOR :AFTER :LAST :FINAL (This SHOULD NOT be used by mod makers and is intended for the end-user/player.)
  20. TranceaddicT
    It shouldn't be a problem. Try uninstalling and reinstall. If that doesn't work, post your KSP.log to a file server (Dropbox, Google Drive) and link it here.
  21. TranceaddicT
    You should check out the organization pages on GitHub. https://github.com/KSP-KOS
  22. TranceaddicT
    @bodryxon Check your GitHub.
  23. TranceaddicT
    Try this ...
  24. TranceaddicT
    Change @MODULE[ModuleB9PartSwitch],* { @SUBTYPE[*],* to @MODULE[ModuleB9PartSwitch],* { @SUBTYPE,*
  25. TranceaddicT
    Feel free to review the documentation and submit a filter design.
×
×
  • Create New...