Page 1 of 2
Clobbering order for AddOns .plist keys
Posted: Thu Jan 24, 2013 10:36 am
by 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";
};
}
Re: Clobbering order for AddOns .plist keys
Posted: Thu Jan 24, 2013 10:41 am
by 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.
Re: Clobbering order for AddOns .plist keys
Posted: Thu Jan 24, 2013 1:01 pm
by Wildeblood
Ya, what Smivs wrote. On Windows it's alphabetical, on other systems, unpredictable.
Re: Clobbering order for AddOns .plist keys
Posted: Fri Jan 25, 2013 12:06 am
by Commander McLane
Wildeblood wrote: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.
Re: Clobbering order for AddOns .plist keys
Posted: Fri Jan 25, 2013 2:53 am
by Tricky
Is there any reason why the AddOns directory list can not be scanned and sorted in order to harmonise all OS's?
Re: Clobbering order for AddOns .plist keys
Posted: Fri Jan 25, 2013 7:52 am
by 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
Re: Clobbering order for AddOns .plist keys
Posted: Fri Jan 25, 2013 8:40 am
by Eric Walch
Smivs wrote:... 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.
Re: Clobbering order for AddOns .plist keys
Posted: Fri Jan 25, 2013 8:46 am
by cim
Tricky wrote: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.
Re: Clobbering order for AddOns .plist keys
Posted: Fri Jan 25, 2013 9:12 am
by Commander McLane
cim wrote: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.
Re: Clobbering order for AddOns .plist keys
Posted: Fri Jan 25, 2013 9:27 am
by Eric Walch
cim wrote: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.
Re: Clobbering order for AddOns .plist keys
Posted: Fri Jan 25, 2013 9:29 am
by cim
Commander McLane wrote: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.
Re: Clobbering order for AddOns .plist keys
Posted: Fri Jan 25, 2013 12:05 pm
by Diziet Sma
cim wrote: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.
Re: Clobbering order for AddOns .plist keys
Posted: Fri Jan 25, 2013 1:06 pm
by Pleb
Smivs wrote: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
Re: Clobbering order for AddOns .plist keys
Posted: Fri Jan 25, 2013 8:13 pm
by 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
Re: Clobbering order for AddOns .plist keys
Posted: Sat Jan 26, 2013 9:23 am
by submersible
Halfhand wrote: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.