I made a wiki entry summarising ways of making mods mutally compatible, based on what little I know. Improvements welcome!
Mod Compatibility
Débuté par
Proleric
, mars 05 2010 10:23
#1
Posté 05 mars 2010 - 10:23
#2
Posté 05 mars 2010 - 01:27
Good start; I'll see if I can give examples of how to do some of those things after I get off work.
#3
Posté 05 mars 2010 - 03:54
ohh nice
#4
Posté 08 mars 2010 - 12:19
Resource names need to be unique within type. For example,
genpt_party.plt and genpt_party.nss are different resources, becasue
the type is different. However, if two modules both have resources
called genpt_party.plt, only one will load in game, following the Source directory priorities.
Within the toolset database, duplicate resource names are
forbidden, but there's nothing to stop different builders making
resources which accidentally conflict, so it's wise to choose a unique
range of names. Each builder can register the prefix they require. See Resource Naming Convention.
Oh no... this is shocking.... So, it's not enough that resources are unique within a module. I have 150 resources named like chest_1, chest_2, ncp_bernard, npc_oren and so on. If the resources need to be globally unique with in the DA:O, then, this is a disaster. I suppose that a total disaster is avoided since it's possible to rename resources from the Properties after checkin - in and the toolset seems to be wise enough to automatically update the places where the resources are used.
#5
Posté 08 mars 2010 - 10:15
The only time one will override the other is if both are loaded in the same session. If this never happens, the names don't need to be globally unique, however it is not always clear when some things get loaded so to be absolutely sure no conflicts occur, at the very least add a unique module specific prefix/suffix to every resource you don't intent to override.
#6
Posté 09 mars 2010 - 08:31
Quite right. The game only loads one campaign at a time. However, all enabled add-ins which extend it or have core resources can conflict with it (not to mention stuff in other override folders such as "packages" which may have wandered into the player's configuration).
The unique prefix is a good defence, which doesn't depend on other builders adopting best practice. For example, if I call my resources coc_chest1, the probability of some other builder using that name is almost nil, whereas chest1 is probably already out there somewhere.
The unique prefix is a good defence, which doesn't depend on other builders adopting best practice. For example, if I call my resources coc_chest1, the probability of some other builder using that name is almost nil, whereas chest1 is probably already out there somewhere.
Modifié par Proleric1, 09 mars 2010 - 08:33 .





Retour en haut







