Pirate Clan One OXP - The Blitzspears -

[JensAyton]

A unique ID would be rather important, yes. Any implementation that doesn’t work if you rename an OXP is broken. Pity we don’t have such IDs for existing OXPs…

[Commander McLane]

But it would get my vote, one hundred percent!

[Cmdr James]

You’re welcome to implement a dependency system. I suggest “must-load-after” and “should-load-before” keys in requires.plist. The basic logic for this type of dependency management is already implemented in OOOXPVerifier.m.

Does it make sense ever to state load-before? Any kind of sensible dependency management normally only has I depend upon rather than depends upon me. Any patches or whatever should always be loaded after shouldnt they?

Unless maybe you find a broken oxp that has an undeclared dependency, and rather than fix it, you pre-inject a fix? Sounds kind of fishy to me.

[JensAyton]

You’re welcome to implement a dependency system. I suggest “must-load-after” and “should-load-before” keys in requires.plist. The basic logic for this type of dependency management is already implemented in OOOXPVerifier.m. :-)

Does it make sense ever to state load-before? Any kind of sensible dependency management normally only has I depend upon rather than depends upon me. Any patches or whatever should always be loaded after shouldnt they?

Unless maybe you find a broken oxp that has an undeclared dependency, and rather than fix it, you pre-inject a fix? Sounds kind of fishy to me.

I find that should-be-before adds flexibility without significant complexity. For instance, in the OXP verifier, it’s used by various verifier passes to state that they should be run before the list-unused-files stage, which doesn’t need to know about each stage that provides “used files”. It’s not immediately obvious that there’s a use for it with OXPs, but life would be pretty boring if OXPs could only do things we thought would be useful. :-)

Anyway, the unique-identifier problem is a much bigger issue, and, as I recall, the reason I didn’t implement dependency management last time I thought of it. One way would be to let each ship ID an OXP defines be used as a unique ID – being careful to ensure OXPs don’t end up depending on themselves in this way.

[JensAyton]

Come to think of it, here’s a usage scenario: A Really Froody OXP.oxp introduces the SuperCoolShip mk. IIII. Bodacious Missions.oxp uses a SuperCoolShip mk. IIII, and includes it in its shipdata.plist. However, the author knows that A Really Froody OXP.oxp may be updated in future to make the SuperCoolShip mk. IIII even froodier. Therefore, Bodacious Missions.oxp declares that it should load before A Really Froody OXP.oxp, so that if both are installed, the canonical extra-froody SuperCoolShip mk. IIII is used if both are installed.

[Chaky]

I had to... I just had to... I couldn't hep it.. It was chasing me and it was too fast.

Here it is..

[Fatleaf]

I was going through the OXP List and putting Y's into the working boxes of oxp's I have tested and saw that this was blank. Does it work with 1.76? If so I could Y the box?