Skip to content

:THIS[foobar] **EXPERIMENTAL** #11

@Lisias

Description

@Lisias

Currently, we have the following Parch Ordering:

  1. Nodes with no operator ('insert') are loaded by the KSP GameDatabase first.
  2. Patches for modname values in NEEDS, BEFORE, AFTER 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:
    • All patches with :BEFORE are applied
    • All patches with :FOR are applied
    • All patches with :AFTER are applied
  6. All patches with :LAST are applied in order
  7. All patches with :FINAL are applied

On the https://github.com/net-lisias-ksp/MM-FORNEEDS-ProofOfConcept repository, a proposal for a better handling of :FOR was proposed, as well the use of a hypothetical :THIS clausule to make the handling easier.

So the :THIS[foobar] clausule would declares declares the presence of a Add'On (i.e. creates a tag on the Module Manager's set of installed add'ons), and the :FOR[foobar] clausule would loose the ability to declare them but will retain the temporal (ordering) semantic. So 3rd parties could use :FOR[foobar] to allow patching some add'on at the same time the target add'on, and so anyone using :LAST[foobar] would have these patches available avoiding the need to use crappy solutions as :LAST[zzzz-something] on the patch set.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions