Depends a lot on how the actual dependencies themselves are coded, but if they use things like "IsA" then the answer is immediately a resounding "no".
Even if they use things like "MyClass(Actor) != None", I don't really know what the behavior will be (it's probably undefined or first come first served at worst, scoped to their own packages at best).
Either way, you're doing it the wrong way for what you want to achieve.
First, if the idea is for your package to work with whichever other package is loaded in the server, then you cannot hold dependencies to 3 variations of them all at once in the first place, since that would defeat the whole purpose of what you're doing, as that would require server owners to have all 3 versions.
And then, as new versions come along, you will probably want to support them too, and suddenly the whole thing explodes when you require admins to have 4, 5, 6, ... versions installed simply because you support all of them.
So the moment you hold 3 dependencies like that, you're already doing it wrong. Having this in mind should already make you seek a different way of doing things.
With that out of the way, so how can you support the 3 of them, without holding 3 dependencies?
Instead of directly depending on them with a single package, you have to invert the dependencies flow, and you do so by splitting your single package into 4 different ones.
One of the packages will be the core implementation, and it's where you actually implement all the common functionality, and is the one which has your mutator and whatnot to load everything up, and this package doesn't depend on anything at all whatsoever.
The other 3 however, will only have 1 dependency each: a dependency towards their respective package that you want to target.
Which means:
1 - Out of the 4 packages you provide, admins just need to use 2 of them: the core one and the one targeted for the BT version they're running, and they do not need to install the other versions.
2 - Whenever a new version comes along, you don't have to update your core package, you just need to create a new one for that version specifically, meaning that the whole thing scales well with new versions and require minimal maintenance and updates.
3 - You can deprecate and remove support for any version by simply not updating its respective package.
4 - Specific code and fixes to a package will remain in a separate package, while the core will remain always clean and work the same way.
A more practical example through a sample of code would be something like this: consider your core package with no ties to any other package, and have a class like this:
Code: Select all
class BT_SpecMutator expands Mutator;
var globalconfig string BTSpecHudPackageClass;
function PreBeginPlay ()
{
local class<HUD> BTHudClass;
Super.PreBeginPlay();
BTHudClass = class<HUD>(DynamicLoadObject(BTSpecHudPackageClass, class'Class'));
if (BTHudClass != None) {
Level.Game.HUDType = BTHudClass;
} else {
//throw some error here
}
}
Which then in its .ini file, BTSpecHudPackageClass could be "MyBTPlusPlusTournament_C.BT_SpecHUD_Tournament" for example, or any other corresponding to any other package.
You could even improve it by simply have it as "BTSpecHudPackage" where in the ini you would just need to have the package name, while the class would remain the same (this enters a bit the concept of interfaces, which I am not delve into right now).
Having that said, this can be improved and done in your own way of course, this is simply the most basic example of what I am trying to show you concerning the management of dependencies for each version.
But doing this or something similar, you eliminate any dependency problems you have now and that you may have in the future.