Redefining datablocks from another add-on

Author Topic: Redefining datablocks from another add-on  (Read 1716 times)

Say I have an add-on that uses datablocks from another pack, but I want my add-on to be standalone and not force the pack as a required add-on. If I define datablocks that are identical to and named the same as those from the other pack, and duplicate the necessary files into my zip, will this work? Or will it cause loading issues with players/something else that I don't know about? Would I be better off adding a conditional to only redefine using the files in the zip if the other pack doesn't exist?

Say I have an add-on that uses datablocks from another pack, but I want my add-on to be standalone and not force the pack as a required add-on. If I define datablocks that are identical to and named the same as those from the other pack, and duplicate the necessary files into my zip, will this work? Or will it cause loading issues with players/something else that I don't know about? Would I be better off adding a conditional to only redefine using the files in the zip if the other pack doesn't exist?
redefining the exact same datablocks would work but it would be better to just force the other addon as a required addon

if its a small enough addon(maybe you're making a weapon pack and you only need a small addon, you can do something like this:
Code: [Select]
if(!$AddOn__Weapon_Gun)
{
   exec("Add-Ons/Weapon_Gun/server.cs");
   gunItem.UIName = "";
}
so the if() part checks if the gun addon is enabled, then if not, the addon is executed.
the "gunItem.UIName = "";" part removes the gun item from the wrench list as the addon wasnt executed, so the host probably didnt want the gun.

That makes sense. The main reason I don't want to force the add-on is that I'm editing a gamemode and I don't want to constrain the server host's choice in weapon packs.

my suggestion is you create a clone of the weapon instead of overwriting it in general. you should generally do that

my suggestion is you create a clone of the weapon instead of overwriting it in general. you should generally do that
But if I make no changes to the datablocks, overwriting should be okay right? I don't need the weapons specifically so much as their particle effects.

You should never tamper with the functionality of an add-on that you don’t manage (and therefore can’t control updates and deal with cross-compatibility issues). Say you hardcode a re-definition of the datablock of say the duplicator. Now if Zeblote releases an update that changes field names or adds new fields that are required for the add-on to work, your add-on forcing the old version of the datablock could break your add-on and more than likely break Zeblote’s duplicator.

Instead you should look into forcerequiredaddon and then use inheritance to duplicate the add-ons datablock into your own custom datablock, for example:
Code: [Select]
datablock itemData(copiedDuplicator : sourceDuplicator) //substitute for correct name
{
    redefinedField = “redefined value”;
};

For more info check the stickied topic about using forceRequiredAddon to avoid duplicating datablocks.
« Last Edit: June 03, 2018, 05:27:40 PM by Dannu »

Now if Zeblote releases an update that changes field names or adds new fields that are required for the add-on to work, your add-on forcing the old version of the datablock could break your add-on and more than likely break Zeblote’s duplicator.
I see your point. But I wanted to avoid using forcerequiredaddon for an entire weapons pack (namely Quake Type weapons) and all the datablocks that would consume when I only need datablocks from a select few weapons. It seems at this point my best bet is just to create renamed versions of the datablocks I want but copy over their fields and assets. Or to make a conditional declaration of the original datablocks only if the other pack is not enabled.

if you plan on releasing anthing you shouldn't overwrite it. if its for your own custom server, feel free to edit antyhing