Clobbering order for AddOns .plist keys

[submersible]

Is there a defined or predictable order in which plists eg planetinfo.plist are applied and hence can be clobbered by another plist? Are whole structures clobbered ?

eg: my.oxp defines a planetinfo for Lave ; and my-v2.oxp defines it also

Code: Select all

{
   "0 7" = {
       texture = "my-oxp-texture.png";
   };
}

Code: Select all

{
   "0 7" = {
       texture = "my-v2-oxp-texture.png";
   };
}

[Smivs]

As far as I know, it depends on the order that OXPs are loaded - last one loaded wins. The load order is unpredictable, with some compters seeming to do this alphabetically and others seemingly at random.

[Wildeblood]

Ya, what Smivs wrote. On Windows it's alphabetical, on other systems, unpredictable.

[Commander McLane]

Ya, what Smivs wrote. On Windows it's alphabetical, on other systems, unpredictable.

Small correction: on Windows and Mac it's alphabetical, on Linux it's unpredictable.

[Tricky]

Is there any reason why the AddOns directory list can not be scanned and sorted in order to harmonise all OS's?

[Smivs]

The trouble here is that, say they could be allways be made to load alphabetically, all new OXPs would be called z_newOXP.oxp

[Eric Walch]

... all new OXPs would be called z_newOXP.oxp

Definitely not! I would always uses Ω_newOXP.oxp for my files to make sure I beat the z-files.

[cim]

Is there any reason why the AddOns directory list can not be scanned and sorted in order to harmonise all OS's?

People might start relying on a particular order, giving unexpected bugs if people use another method of sorting their OXPs (e.g. renaming OXP folders, or creating folders like 'eyecandy.oxp' and 'ships.oxp' inside their AddOns folder to categorise their addons).

In answer to the original question, you can guarantee that OXP A will be loaded after OXP B by placing OXP A inside OXP B.

[Commander McLane]

In answer to the original question, you can guarantee that OXP A will be loaded after OXP B by placing OXP A inside OXP B.

… and now I can see a whole new level of madness coming over us all, with OXPers giving detailed instructions as to where exactly to install their OXPs. Goodbye, good ol' days of "just drop it into AddOns".

But seriously, and before that madness begins: everybody, please be aware that telling the player to install an OXP within another OXP is not an option for Mac users, because for them OXPs are (or at least appear to be) single files with no "inside" to begin with. Guiding single users—especially those who want to get into OXPing—through how to deal with packages is okay, and a necessary step in learning how to create OXPs. But that's different from what the general public should be expected to learn and do on their computers, in order to just play a simple game.

[Eric Walch]

People might start relying on a particular order, giving unexpected bugs if people use another method of sorting their OXPs

And sorting will also be language specific. At least on the mac, the sorting of things like u, ü, ù etc used to be customised with the language settings. And I used to have a numeric sorting 'plug-in' that made sure that the string '000044' was sorted after '22'. Just a pity that most programs never called the system sorting routine to do their sorting.

[cim]

But seriously, and before that madness begins:

Indeed. It's useful to know if you're testing an OXP and want to drop a temporary override to a file or two in; it's not suited to distribution.

[Diziet Sma]

In answer to the original question, you can guarantee that OXP A will be loaded after OXP B by placing OXP A inside OXP B.

At first I thought "Aha! Here's a neat way to deal with the Halsis/BGS problems on Linux!" but after reading the rest of this thread, I think I'll just leave it as is.. patching BGS itself.

[Pleb]

The trouble here is that, say they could be allways be made to load alphabetically, all new OXPs would be called z_newOXP.oxp

Ah, the good old days of quake (and quake engine releated) mods... zzzzzzzzzzzzzzzzzzzzzzzzzzzMy_New_Mod_Frag_Frag_Frag.pk3

[Halfhand]

Maybe oxp dependencies could be looked at the same time, that would fix a lot of compatibility issues as well as missing oxps.

it would also determine a load order that couldn't be overridden by oxp names.

just my tuppence

[submersible]

Maybe oxp dependencies could be looked at the same time, that would fix a lot of compatibility issues as well as missing oxps.

it would also determine a load order that couldn't be overridden by oxp names.

just my tuppence

That's really the only realistic option by the sounds of it. Looking at trunk (and I probably should have done this to begin with) it would need some serious rethink of how OXP loading and verification is determined. I wonder if it is important to anyone other than me.

To demand that some other OXPs are loaded BEFORE yours would mean a format something like,

Code: Select all

{
  "version" = "1.77";
  "depends" = {
    "my_base_package" = "0.09";
    "Cabal_Common_Comms" = "1.4.5"
  };
}

and of course that raises the question of how to stamp OXPs with that information without fully loading them first.