177 réponses à ce sujet

[nikki191]

thank you so much for this i so hope someone fixes all the bugs and glitches for awakening

[Nukenin]

It ultimately depends on whether or not Bioware makes the Awakening source available for the toolset.

If they don't, then I hope they produce a patch of comparable "fixiness" (to Qwinn's fixpack) for Awakening.

[Qwinn1234]

I'm hoping they contract me out to produce it That's kinda the main point for me... I *do* enjoy fixing games and would continue to enjoy it if doing it for money, but for the huge opportunity costs in the time it takes me to do it all, it's not something I can do for more games than I'm already doing without some sort of compensation. So, yeah, Awakening has a zillion bugs and I really would love to fix 'em, but I need to eat too, I can't fix Origins AND Awakening AND make any sort of living (never mind maintaining the 3 PS:T mods, heh).

Modifié par Qwinn1234, 21 avril 2010 - 08:34 .

[ladydesire]

Qwinn1234 wrote...

So, yeah, Awakening has a zillion bugs and I really would love to fix 'em, but I need to eat too, I can't fix Origins AND Awakening AND make any sort of living (never mind maintaining the 3 PS:T mods, heh).

Sheesh; I gave up modding Neverwinter Nights 2 to mod DAO, since I didn't think I could work a full time job and mod for two games and do justice to both of them.

[DLAN_Immortality]

Qwinn1234 wrote...

Immortality and ladydesire:

In terms of new content mods, I think the sanest way to handle it will be to just adopt the policy that, when installing our mods, you install my fixpack first and then yours over top of it, allowing you to overwrite my files. That's generally how it's done in most mod communties I've seen, in that it's required that the fixpack gets installed first and content mods are installed after.

Except for the fact that DAO doesn't work that way...

No matter the order people install, my mod always ends up fuxx0red. I know from experience. :-)

So, basically, if a mod has a file I'm also touching, I flag it as incompatible.

The only way for my mod to work is that you add my modifications into whatever file we're colliding with, and otherwise then players will have to choose which mod to install, of course...

Well, this, if you make any change in the future, I guess. For now they should work well together. :-)


EDIT: About a "better system". There is no better system because the toolset is retarded and we can't append files like we did in BG. We can only override.
Good times... ¬_¬

Modifié par DLAN_Immortality, 21 avril 2010 - 09:38 .

[Nukenin]

With Dragon Age it's all about directory search order.   In the case of my own fixes and Qwinn's, mine seem to take priority because their "nuk*" folder names appear before "qw*" in the search order.

A concerned mod author can always create an "override" version of their fixes that are meant to be unzipped to a subfolder in {Dragon Age}/packages/core/override; this will always override anything under {Dragon Age}/AddIns/*.  They can make this available as an alternate download for folks needing to "force" the issue.  (Obviously, if a user mixes multiple such overrides concerning the same file, hilarity and unpredictability will ensue.)

Or you can do the ol' phone book trick.  Make your mod's UID (and thus folder name under AddIns) triple-A.  "aaa_megafix" for instance.  This is assuming the search order under AddIns *is* ascending by folder name (module UID).  It's entirely possible it's random or in whatever "default" order Windows returns polled folder names and it's just a fluke that mine are appearing before Qwinn's.

I think the <modname>/core folder takes precedence over all <modname>/module folders, so representing your module's relevant fixes as a core override might also do the trick to override any module maintaining its fixes in the "module" subfolder, while still retaining the ability to present and manage your module under "Downloaded Content".

Or just wait until everything's rolled up into that wonderful magical mythical mysterious maniacal Patch 1.04, which Fixes Everything™ Or Else®.

[Nukenin]

DLAN_Immortality wrote...

[…]EDIT: About a "better system". There is no better system because the toolset is retarded and we can't append files like we did in BG. We can only override.
Good times... ¬_¬

The better system would be to produce a WeiDU-like utility that groks Dragon Age resources and force all mod authors to transition their work to this system.  Then there'd be much magic and mayhem to be had.  Just because nobody's done it yet doesn't mean it can't be done. 

[Qwinn1234]

I think nukenin may be on to something, and possibly tweaking the UID could work. Immortality, what's the UID on your mod? Mine begins with qw_. If yours starts alphabetically after that, it'll be a simple matter for me to download your mod, create a deliberate conflict and see if your mod overrides mine.

If not... ugh. Honestly I have no idea how to "copy" a mod database from one UID to another, or even if it *can* be done. Which would mean creating a new mod and reimplementing every fix so far. UGH. I'd really like to test and make sure that renaming my mod to aaa_ something would have the desired effect before I stop everything to go through *that* hell.  It does have to be loading the mods in *some* non-random order, we just gotta figure out what that order is and exploit it.

If I do have to redo it all to get an aaa_ UID... ugh, thank God I at least commented the hell out of everything.

Modifié par Qwinn1234, 21 avril 2010 - 11:40 .

[Nukenin]

Heh, Qwinn, you want your comprehensive fixpack to be the "baseline" folks can override if need be, so I think yours is safe at "qw*".  Unless you want to move it down to "zzz_*"    (Assuming overrides in the AddIns folder are indeed processed in alphabetical folder order.)

Moving from one UID to another isn't trivial, but you just put the old one in the hierarchy of the new one and then change properties on all the relevant files.  Obviously a comprehensive fixpack is going to touch a lot of files.

[Qwinn1234]

"Moving from one UID to another isn't trivial, but you just put the old one in the hierarchy of the new one and then change properties on all the relevant files. Obviously a comprehensive fixpack is going to touch a lot of files."

Oooh, that's a good idea! Yeah, I'll definitely go that route if this becomes necessary.

That said, though, I'm confused... you're saying that zzz would load *before* aaa? I thought you meant the opposite. Loading in reverse alphabetical order would be kinda unusual. If that's what your experiment between our mods indicated, I'm guessing that yes, something is making mine load before yours, but reverse alphabetical order isn't it. Maybe create date or something? It'd be good to find out what. I'm gonna research and see if Bioware has answered this question anywhere, and if not, will post a thread devoted to hopefully getting them to answer it. It's a pretty important issue.

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

[Qwinn1234]

Did the research, couldn't find an answer, posted this thread:



http://social.biowar...8/index/2372681

[Nukenin]

EDIT: Looks like module search order is dictated by the order in which things appear in "Downloadable Content" as instructed by AddIns.xml.  So disregard the below willy-nilly.

(Warning: this may be conjecture; like the Most Radiant of Lathander, Kelddath Ormlyr, I am too super-important to be touched, much less be bothered with actually testing things to substantiate conjectures.)

Actually, what I'm saying is say you had three modules that each overrode skill_stealing.ncs.  Module "aaa_stealfix" does it as an extension of the Single Player game.  Module "nr2_stealfix" does it as a Core Resource.  Module "zzz_stealfix" does it as an extension of the Single Player game.  Then there's "BillyStealFix" which the user is asked to unzip manually in {DA}/packages/core/overrride.  (Here, {DA} is the Dragon Age user directory under "My Documents" or such, while we'll use {PF:DA} to refer to the DA installation directory under Program Files or steamapps or wherever.)

Let's assume the user has just installed "aaa_stealfix" and "zzz_stealfix".

Dragon Age needs to load "skill_stealing.ncs".  First it looks under {DA}/packages/core/override and subfolders thereof.  Nothing.  It looks under {PF:DA}/packages/core/override (a nasty place to put stuff if it indeed is second in the search order as the toolset wiki implies).

Then it looks at {DA}/AddIns/{modules}/core (I'll skip the subfolders and other locations).  Nothing.  Then it looks at {DA}/AddIns/aaa_stealfix/module.

Aha!  It's found skill_stealing.ncs.  Done.

The fix under {DA}/AddIns/zzz_stealfix/module is never seen, since aaa_stealfix's was found first.

Now nr2_stealfix is installed.  When skill_stealing.ncs is searched for, it will be found before either of the {DA}/AddIns/{modules}/module implementations, because {DA}/AddIns/nr2_stealfix/core is searched before either of the {DA}/AddIns/{modules}/module directories.

The player then unzips "BillyStealFix" to {DA}/packages/core/override.  Now when the game looks for skill_stealing.ncs, it'll be found there first, as that's the first place the game will look.

I guess the word "override" is misleading.  You're not loading files one on top of another; you're loading the first file found, and the source directory priorities govern the order in which directories are searched.



Of course, I could be completely wrong. 

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

[sami jo]

Conflicting overrides tend to make the game freeze and/or crash to desktop. When that does not happen, one of the two conflicting overrides is used and the other is ignored in its entirety. This is why modders make such an effort to work together to keep their mods compatible.

[Nukenin]

sami jo wrote...

Conflicting overrides tend to make the game freeze and/or crash to desktop. When that does not happen, one of the two conflicting overrides is used and the other is ignored in its entirety. This is why modders make such an effort to work together to keep their mods compatible.

There is no such thing as a "conflicting override".  One file wins and is loaded, the others lose and aren't.

Now since a given module can be comprised of multiple files, any subset of which can be overridden by the same files in a module found earlier in the directory search order, or files found individually in the core override folder—that's when you'd have "conflict".  I'm sure some of it could even produce freezing or crashing, though I wouldn't say it'd "tend to".  But the conflict is because one module's files are being partially overridden.  Not "ignored in its entirety."

Of course, to the end user who is neither aware of nor cares how this stuff happens behind the scenes, I suppose they've already skipped down to the next post. 

[Proleric]

Nukenin wrote...

sami jo wrote...

Conflicting overrides tend to make the game freeze and/or crash to desktop. When that does not happen, one of the two conflicting overrides is used and the other is ignored in its entirety. This is why modders make such an effort to work together to keep their mods compatible.

There is no such thing as a "conflicting override".  One file wins and is loaded, the others lose and aren't.

That's true of individual conflicts, of course, but if there is more than one type of compatibility issue, it is possible to end up with some of mod A's resources and some of mod B's, in which case anything can happen.

So, the search for understanding in this thread is good.

Having recently come upon the earlier discussion about ownership and credit, I recognise that we need to be very careful.

Evidently, the prevailing cultures on other games have not all been the same. Also, there may be a cultural difference between modding the OC and building new campaigns from components.

Hopefully, we can agree that this community belongs to Bioware and that this site operates according to the Terms of Service.

Beyond that, there are no hard rules. We are a voluntary association of equals - no one other than Bioware can dictate how we should behave.

Some of us consider that the benefits of an open systems approach outweigh all other considerations in a non-commercial environment. So, whether a behaviour is courtesy or discourtesy is a matter of opinion. Nothing said here is in any way binding on the community.

My personal preference is to credit people for their work and avoid using material whose author appears to be unduly concerned with ownership. Quinn has also committed to giving credit. So, there's no need to discuss this further, as long as everyone accepts that their opinions are not binding on other people.

[Nukenin]

Proleric1 wrote...

Nukenin wrote...

There is no such thing as a "conflicting override".  One file wins and is loaded, the others lose and aren't.

That's true of individual conflicts, of course, but if there is more than one type of compatibility issue, it is possible to end up with some of mod A's resources and some of mod B's, in which case anything can happen.
[…]

Which is exactly what I said in the paragraph following the line you quoted.  

[Nukenin]

As I replied in Qwinn's query elsewhere, it looks like the order in which modules (under {DA}/AddIns) are searched is dictated completely by the order presented in "Downloadable Content" (accessed via the main menu or on the rightmost tab in the in-game Journal).  This is governed by AddIns.xml ({DA}/Settings) and it seems this can be effectively dictated by the order in which .dazips are (re)installed.  So alphabetical order doesn't necessarily enter into it.  It just so happened that my installation had the user-contributed mods installed alphabetically. 

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

[UpiH]

Why is it that these incidents come to mind upon reading this thread?

http://lucasforums.c...ad.php?t=181258

http://www.lucasforu...ad.php?t=185785

http://knightsoftheo...ont_Again;37146

Then there was the infamous Team Gizka issue. The last man standing sat on the hard work of numerous other modders.

Some want money, some fame and fortune. Oh well.

Modifié par UpiH, 22 avril 2010 - 09:33 .

[DLAN_Immortality]

Nukenin: You are actually on something when you say this:



"A concerned mod author can always create an "override" version of their fixes that are meant to be unzipped to a subfolder in {Dragon Age}/packages/core/override; this will always override anything under {Dragon Age}/AddIns/*. They can make this available as an alternate download for folks needing to "force" the issue. (Obviously, if a user mixes multiple such overrides concerning the same file, hilarity and unpredictability will ensue.)"



Okay, it might not be the best solution, but I could certainly distribute cutscene_slideshow.dlg and party_events.dlg separately for people having compatibility issues... hm.



Okay, yeah. Good thinking. :-)



Anyways, back to the topic: yeah, basically it's like a lottery. Maybe your mod is screwed, maybe not. Not way to really do anything about it, so in the meantime I think we should try to have our mods as clean as possible.



For example, for Ser Gilmore I do not touch any script or plot from the OC, because I figured it will conflict badly with fix mods. It's a shame I had to override cutscene_slideshow.dlg and party_events.dlg, (and char_stage.are), but I tried to make my mod as less "pain in the butt" as possible...

[Nukenin]

Since the first release of my Stealing fix, I've made available the appropriate .ncs file (and .GDA file to fix tactics for stealing, and a variant of the .GDA file to shorten the cooldown for those impatient rogues out there) as a separate download, for knowledgeable folks to plop into packages/core/override as they desire.  And I made available my modified sys_treasure_h.nss source script for folks wanting to take my work and merge it into any modifications they themselves have been making to the same code (or just to satisfy their curiosity as to what I did).

Of course, scripts are so much more simpler and straightforward than other resources. 

If one has many such files, it'd be best to bundle them up in a folder and zip that up; they can then unzip into packages/core/override and have all the files together in one folder.  I've not bothered with that since my stealing fix at its core is just the one compiled script, and an (optional) choice of one of two .GDA files.

I personally still prefer the .dazip since it plops the fix into "Downloaded Content" and allows the end user to selectively disable.

It's kinda funny—in the past with these sorts of things, you wanted to install the "base fixes" first and install override fixes after.  But with the way "Downloaded Content" seems to influence load order, and the way it gets populated, you kinda want to install the more specific fixes first and the "base fixes" last.

I wished the "Priority" entry in the module properties had some impact here, but I think it's only used in resolving M2DA conflicts.  It's really best to let the end user have the ultimate governance over module load order, anyway, so at least "(re)install in the order you want" is possible "easy" advice to offer those having issues with multiple mods.

EDIT: I think "Priority" does have an impact.  It just appears to be the reverse of what I was thinking when I futzed with it.  Raising it will move your module down in "Downloadable Content" (i.e. later in the search order) so putting a comprehensive fixpack at a higher priority may help to ensure it loads later than specific fixes with the default "100" priority.  

EDIT to the EDIT: I really should avoid using terms like "loads later" since what's really being determined here is search order—i.e. which file is found first.  Only that file is loaded, there's no "load order" at play here.

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

[ladydesire]

DLAN_Immortality wrote...

For example, for Ser Gilmore I do not touch any
script or plot from the OC, because I figured it
will conflict badly with fix mods. It's a shame I
had to override cutscene_slideshow.dlg and
party_events.dlg, (and char_stage.are), but I
tried to make my mod as less "pain in the butt"
as possible...

I felt so much the same way when I started doing my class mod that I delayed releasing it until I had found a way to override the functionality of sys_chargen.ncs without actually placing a modified copy of that file in the override folder. I've got that class mod down to one modified default Bioware script in the toolset; while I am modifying Bioware dialog files to better integrate the class into the game, these changes are mainly cosmetic and should not interfere with fixes to the game from either Bioware or others. My companion mod will be done the same way.

[DLAN_Immortality]

I think modders will have to ultimately work together and make their mods compatible.



It sucks to have to choose between mods to install... so yeah, could be nice to find a way to work together to make our mods compatible.



Kudos too, ladydesire! :-) I'll be also happy to modify my mod when yours is completed in case we need to create a combined char_stage or cutscene_slideshow or whatever. :-)

[Nukenin]

tl;dr summary so far of my findings in Qwinn's other thread:

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 - 06:01 .

[Proleric]

That's good to know.

Incidentally, I obviously didn't make my earlier point clearly enough. The compatibility page in the wiki mentions a number of issues - resource name conflict is only one. A mod might get some or all of the right resources, but the wrong 2DA, and so on.

I'd echo ladydesire and DLAN_Immortality. Rather than looking for better ways of competing for the same space (such as the packages override), modders might have more success by adopting compatibility techniques. Some of these are akin to defensive driving, i.e. they don't entirely depend on other people doing the right thing.

[Nukenin]

Despite the best intentions of the Compatibility page, the best recourse for builders looking to assure smooth interoperability between their various fixes and content additions is—communication, be it directly or through behaviors such as posting usable, mergeable, and/or well-documented outlines of their fixes or content additions as a form of "precommunication".  This incorporates the sensible preparation and reservation/publication of ID ranges, prefixes, etc, as discussed in various forms on the Compatibility page, but such things are never going to be a perfect substitute for just the good ol' back-and-forth.

As a simple example, nothing on that page will help Builder A who fixes skill_bamboozle.ncs (mod A) and Builder B who adds features to skill_bamboozle.ncs (mod independently get their atomic replacements of skill_bamboozle.ncs (mod A and mod to coexist.  Only communication will enable them to cooperatively produce a mod C that is the unified combination of both mod A and mod B, and that will serve as an effective replacement for mod B.  (mod A remains discrete, as some end-users may want the fixes it delivers without the feature additions of mod B.)