16 réponses à ce sujet

[Qwinn1234]

I've searched the forums and the DA Builder Wiki and I can't find an answer to this question.  If you have multiple mods that touch the same filename, and each mod has it located in the same directory within their respective hierarchies (such as say modules/override/toolsetexport), what determines their order of precedence?  Is it based on the UID of the mods, alpha or reverse alpha?  The order in which they're enabled in the downloadable content tab?  Create date of the mods?  I've seen various guesses as to what it might be, but no hard answer.  It's a pretty serious issue in terms of working out mod compatibility problems.

The closest I've seen an attempt to answeris here, from the DA Builder wiki "Compatibility page":

http://social.biowar...p/Compatibility

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.

But if you follow that link to the "Source directory priorities" list, it only tells you what the load order is within different directories in the overall packages/core/addins/etc. hierarchies, but not what happens when you have, say, two different mods that both have their own version of genpt_party.plt in their respective addins/<Module UID>/override/toolsetexport directory.

Knowing what determines which takes precedence in that situation would be *extremely* helpful in working out compatibility issues.  Thanks for any help you can offer!

Modifié par Qwinn1234, 22 avril 2010 - 02:30 .

[Nukenin]

While I've answered with my honest conjecture in your project announcement thread elsewhere, here I will simply provide blatant misinformation in an attempt to sow confusion and discord.

Dragon Age assigns each module a "Cool Factor".  This is a clever calculation which is a trade secret, so I shan't spoil it too much here, lest mod authors try to game Cool Factor like website scammers try to game Google's pagerank.

Anyway, Cool Factor begins at 42.  Then  the directory path is consulted, and CF is adjusted by the presence of the following:

Documents +13
Program Files +5
packages +8
core +7
override +5
AddIns +3
module +2
nuk +9000
qw -800

At this point, CF is squared, a cube root is found, and it's multiplied by the current Dollar-Euro conversion rate modified by a fuzz factor derived from the mod's popularity on four key DA mod hosting sites (or 1.5 if a net connection is not available).

If a net connection is still available, the CF is mutated into three alternate numbers by a variety of pseudo-random algorithms, and the results used to seed four computer-generated charcoal-style drawings (one based on the original CF, the others based on the pseudo-random mutations) which are then presented to a panel of no less than 500 human judges through Amazon's Mechanical Turk service.  Once a consensus has been reached through Mechanical Turk, the winning drawing is then run through an image processor to determine the average ambient light level on a scale of 0.0 (pitch black) to 1.0 (pure white).  This value is then multiplied by the average price of tea in China in vintage Monopoly money, to which is added the original derived CF converted to the metric system.

The resultant CF (whether online or not) is then factored into primes, which are then used to determine mod load order, though there's a slight chance the mods will be further shuffled slightly to further prevent gaming the CF system.  Also, on 64-bit Windows Millenium systems it's known that the mod order is inverted causing all the mods to load upside down.

Okay, there's a nice bit of misinformation for someone to vehemently counter. 

Modifié par Nukenin, 22 avril 2010 - 03:36 .

[Nukenin]

Okay, working on a fix to my Stealing fix (floaty notification for stolen inventory items), it now seems that the mod order for stuff installed under AddIns is dictated by the order in Downloadable Content (viewable from the main menu or Journal in game).

What governs that?  AddIns.xml.  It looks like reinstalling .dazips in the desired order may be enough to rearrange the order in Downloadable Content.

[Qwinn1234]

Okay, that seems plausible. Did you find that out via experimentation?

And I see in your other thread that the load order is FIFO (First In First Out) as opposed to LIFO. If you've got 5 mods all with the same file in your load order, it is the file in the .dazip that is installed *first* that will be operative, because once it finds a file it's looking for, it doesn't bother continuing to search further. (The alternative, which is just as plausible and I've seen in other systems, is that it would search the entire list of mods and use the *last* one.)  Am I interpreting correctly?

If so, then yeah, this produces the rather odd situation that, in the case of a comprehensive fixpack, you'd actually want to install it LAST. Wow. That's gonna take some getting used to.

Unless, of course, you're just installing your mods manually by dumping files into an override folder, in  which case you'd want to dump fixpack files into the override directory first and then copy content mods in after it, allowing them to overwrite.

Urf.  Writing up the install notes on that should be fun.

(On the other hand, this means I *don't* have to convert/change my mod's UID for the sake of some alphabetic hierarchy, which gets a big old woohoo!)

Modifié par Qwinn1234, 22 avril 2010 - 07:28 .

[Proleric]

Of course, if you were to use unique resource names, following the convention suggested on the Compatibility page, you wouldn't have this problem... Not always easy, I know, but where there's a will, there's a way...

[Qwinn1234]

Proleric1, in most cases that's not a real problem. But when you get things like the final epilogue slideshow at the end of the game, with multiple mods wanting to make changes to it for whatever reason (me to fix the bugs, others to add lines about their NPC mod's character's fate), if you have each mod install a unique resource name variant of the relevant dialogue, the issue still remains: which one will actually run?

[Nukenin]

Yep, as I mentioned in your project thread in a recent post, we do have the interesting situation in which folks will want to install fixpack-type .dazips last.

And I'd keep a comprehensive fixpack as a .dazip and force folks to load it into the module hierarchy; that way you don't have to deal with the peculiarities of folks putting those files into packages/core/override.

Conversely, folks who author specialized fixes or mods might want to make their files available as a .zip bundle extractable into packages/core/override for those special cases where the end-user might want to ensure the fix or mod is always available (and are prepared and knowledgeable enough to deal with the mayhem if they have many such fixes or mods floating around in packages/core/override).

Meanwhile, yes, this was discovered while updating my Stealing Fix to 1.2 (and now 1.21).  The bestest version of my Stealing Fix ever!  But when I was testing, I discovered that the toolset merrily put the relevant chunk of AddIns.xml at the end, after your fixpack's entry, and then all of a sudden your fixpack's stealing fix was taking precedence, making testing my changes slightly awkward until I realized I could just reinstall your fixpack to bump it to the bottom of the list.

Awakening, Return to Ostagar, and the two disabled Feastday packs actually appear below it for reasons I shan't be bothered to investigate despite being above it in AddIns.xml.  Okay, i did investigate—looks like module property "Priority" actually may have some influence here.  When I tested, I tried to raise my Priority to move my fix up in the list (since the toolset doesn't let you lower priority below 100, despite a lot of the DLC items having priority 1), but it looks like what I was actually doing was moving my fix down in the list.

Interesting.  So putting your fixpack at a higher priority might ensure it stays down in an end-user's Downloadable Content list.

[Nukenin]

Proleric1 wrote...

Of course, if you were to use unique resource names, following the convention suggested on the Compatibility page, you wouldn't have this problem... Not always easy, I know, but where there's a will, there's a way...

The Compatibility page rather misses the boat here—aside from a single paragraph referencing the Source directory priorities page, which alas does not cover the order in which modules under AddIns/{module}/{subfolder} are queried, only the order in which those subfolders are queried.  E.g. we know that AddIns/moduleA/core would take priority over AddIns/moduleA/module, but we're asking how the game determines priority when a file is present both in AddIns/moduleA/core and AddIns/moduleB/core.

We aren't immediately concerned with modules playing nice with each other (IMHO that's a different issue albeit one that can be informed by what we discover here); we're concerned with how the game determines who gets to go first. 

Modifié par Nukenin, 22 avril 2010 - 04:04 .

[Qwinn1234]

Okay, now I'm either not understanding something, or this is pretty wildly counterintuitive.



Files in mod at the TOP of the downloadable content list get priority, I thought. If the game finds a particular file in a mod at the top of the load order, then similar files in similar folders further down the list don't even get searched for.



And if you assign "Priority" to your mod, it puts you at the *bottom* of the list?



Doesn't that essentially mean that clicking Priority means you are DE-prioritizing that mod?

[TimelordDC]

The simplest test would be to have multiple variants of skill_stealing.ncs in different modules and run the game and check. Each script can have a different floaty message that you can see. Enable/disable some of the mods to see where the game fetches the script from.



In any case, I think the core files are loaded in no matter what you override and then, the overriden files are used, if present. Again, a simple test would be to remove skill_stealing.ncs from the program files scripts erf file and check.



I don't know if Nukenin has already done some of these tests but looking at the posts, it does like it is more conjecture than fact.

Another option you could try is to have a base mod that includes all fixes and any other 'fixer' can extend this base mod (which extends Single Player in itself). If that works, Qwinn's mod (since it is so extensive) can serve as the base 'fix' mod.

[Nukenin]

Qwinn1234 wrote...

Okay, now I'm either not understanding something, or this is pretty wildly counterintuitive.

Files in mod at the TOP of the downloadable content list get priority, I thought. If the game finds a particular file in a mod at the top of the load order, then similar files in similar folders further down the list don't even get searched for.

And if you assign "Priority" to your mod, it puts you at the *bottom* of the list?

Doesn't that essentially mean that clicking Priority means you are DE-prioritizing that mod?

Yes. 

I guess with Priority, #1 really is #1.  Of course, from the toolset you can't set your priority below 100; you'd have to manually edit your module's relevant manifest.xml.  That probably shouldn't be done, though.  Most user-created mods and fixes will be installing themselves at priority 100, and we've seen that installation order can be used as an end-user controllable way to shuffle those around.

Raising Priority, however, is a good way to make sure a broad fixpack can be more easily overridden by specific fixes.  I.e. think of Priority as "Nice Factor".  The higher the Priority, the nicer your AddIn is when mixed with others.

Right now the Nicest mods (that I've got installed) are Awakening (Nice Factor 110), Return to Ostagar (Nice Factor 200), Feastday Gifts (Nice Factor 300), and the nicest mod ever, Feastday Pranks, with a whopping Nice Factor 302.

I hereby declare that all fixes and mods with a Nice Factor of 100 aren't that Nice at all.

Also, most of the DLC items are really mean, with Nice Factors of 1.

I'm tempted to make my fixes the meanest ever by giving them Nice Factors of 0.  But nah, I'll just hang with the crowd and stick with the default 100. :innocent:

[Nukenin]

TimelordDC wrote...

The simplest test would be to have multiple variants of skill_stealing.ncs in different modules and run the game and check. Each script can have a different floaty message that you can see. Enable/disable some of the mods to see where the game fetches the script from.

In any case, I think the core files are loaded in no matter what you override and then, the overriden files are used, if present. Again, a simple test would be to remove skill_stealing.ncs from the program files scripts erf file and check.

I don't know if Nukenin has already done some of these tests but looking at the posts, it does like it is more conjecture than fact.
Another option you could try is to have a base mod that includes all fixes and any other 'fixer' can extend this base mod (which extends Single Player in itself). If that works, Qwinn's mod (since it is so extensive) can serve as the base 'fix' mod.

I'm content with what I've discovered and confirmed.  It's easy to test, just manually edit priorities in AddIns.xml.  I set my stealing fix to Priority 900 (possibly making it the Nicest mod ever) and it dropped all the way to the bottom of Downloadable Content, despite still appearing ahead of Qwinn's fix in AddIns.xml.

So Priority is the main governor here (albeit backwards from what folks would conclude from the word "priority").  Changing ExtendedModuleUID to that of Qwinn's fixpack did not change the location of my fix in the Downloaded Content list; in game, his stealing fix (which is distinguished from mine by virtue of having no notification, and distinguished from the game's by virtue of being fixed) was still used.

So Priority trumps when determining search order—AddIns with lower Priority are searched first.  For AddIns with equal Priority, installation order (specifically, order in AddIns.xml) determines search order.

ExtendedModuleUID does nothing when the file in question is a core override (i.e. under AddIns/{ModuleUID}/core).  When the file in question is a module override (i.e. under AddIns/{ModuleUID}/module), ExtendedModuleUID does not influence search order at all (i.e. if the extended module still has a lower Priority than the module that extends it, or they both have the same Priority but the extended module appears before the module that extends it in AddIns.xml, the extended module will still be searched first.  If the extended module is disabled, however, then files under AddIns/{ModuleUID}/module for the extending module will not be searched at all.

(To test that, I made my Dog Find fix higher in Priority than Qwinn's fixpack, then made it an extension of the fixpack.  His fixpack's dog find fix still overrode my fix, because it had lower Priority.  Disabling his fixpack while leaving my Dog Find Fix enabled resulted in the game reverting to the original, broken dog find behavior, because the game ignored AddIns/nuk_dogfindfix/module/* because the "extended module" qw_fixpack_1 was disabled.

Now that I've wreaked havoc on my Downloaded Content by manually mangling Priorities, I will reinstall the three affected module .dazip files… and voila!  Nukenin's Stealing Fix appears before Nukenin's Dog Find Fix which appears before Qwinn's fixpack—exactly the order in which I reinstalled them.  (Previously, Nukenin's Dog Find Fix appeared first, so I've confirmed that reinstallation/AddIns.xml order does indeed play a role.)

Okay, I've achieved enlightenment.   Sorry if this confuses the heck out of the reader. 

[Nukenin]

Yes, I know, I left out a closing paren.  Here ya go: )

[Nukenin]

tl;dr summary so far:

AddIns with lower Priority are searched first.  AddIns with equal Priority are searched in order of their appearance in AddIns.xml which can be governed by (re)installation order. However, packages/core/override/* is searched before anything else, and AddIns/{ID}/core/* will be searched before any AddIns/{ID}/module/*.

Hope this helps. 

Modifié par Nukenin, 22 avril 2010 - 05:48 .

[Qwinn1234]

Okay, so if that's the case, then I'll plan (pending further testing) that for my next release I'll set my priority to 105, such that any other player mods installed will override. That way I won't interfere with any other mods, and (in general, I'm sure there'll be exceptions but those should be managable) the worst that'll happen if you mix my mods with others is that their stuff will work but some of my fixes won't be applied, it shouldn't behave worse than the vanilla game though. At least most of the time.

Modifié par Qwinn1234, 22 avril 2010 - 05:48 .

[Nukenin]

Set the Priority to 666. 

[Nukenin]

Nukenin wrote...

tl;dr summary so far:

AddIns with lower Priority are searched first.  AddIns with equal Priority are searched in order of their appearance in AddIns.xml which can be governed by (re)installation order. However, packages/core/override/* is searched before anything else, and AddIns/{ID}/core/* will be searched before any AddIns/{ID}/module/*.

Hope this helps. 

Bear in mind that "lower Priority" is meant to be read as "lower value for Priority", which actually denotes higher priority.  Semantics!

Modifié par Nukenin, 23 avril 2010 - 12:04 .