177 réponses à ce sujet

[Proleric]

Fair comment. Equally, if the number of new campaigns meets current expectations, there will be far too many to resolve every issue by direct communication. Hence the reservation lists and general conduct for good order.

[ladydesire]

Nukenin wrote...

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.)

It's a noble sentiment, but ultimately it's like herding cats...

[DLAN_Immortality]

I agree it's utopic to think all mods can be compatible, but interested modders can do their best nevertheless.

As said, it's just a matter of communication. Make a compatibility b2b so other modders can use it to make their mods compatible. Talk to others and make an effort to add things into your mod. Sometimes it's as easy as getting some coordenates for a waypoint ;-)

In my case, I think my mod is waaaay low priority wise. All the files I have and all the files I've modified have their properties set as "Ser Gilmore" in both owner module and module (I've changed them from "core game resources" or "single player" to my own mod), so they mostly fall into my AddIns/Ser_Gilmore_LBCI/core/* and AddIns/Ser_Gilmore_LBCI/module/* instead of packages/core from the game.

Now I get how comes my mod is the one fuxx0red all the time. :-D
On a brighter note, however, that means I don't need to add other modder's content into mine, but the other way around... I guess that's good news to me, heeh. :-p

Modifié par DLAN_Immortality, 22 avril 2010 - 09:40 .

[Trefalen]

Man, thats a lot of work. I salute your effort.  I will point out one thing, BW will no doubt grab your patch and redo a few things to make it look like they made it and release it.

They get paid, you didn't.

But your heart is in the right place. At the least BW should throw you a bone for making their lives easier.

[Nukenin]

Just as an aside, Bioware themselves could learn a thing or two about reserving ranges and communicating such ranges, as anyone who's wondered why Vigilance looks like Starfang will attest. 

Honestly, though, I just wish Bioware had taken the time to modernize things.  I could rant endlessly on everything they've done wrong and everything they could've done right, but that caliber of ranting needs dollar signs attached. 

Qwinn's thinking about experimenting with a lower (albeit really higher; I've already conditioned my mind to consider higher values of Priority to mean "lower priority") Priority for the next release of his fixpack.  Since most folks rolling out mods and fixes don't tinker with the default 100 Priority, this means instead of his fixpack stomping all over any conflicting toes, it should instead quietly submit its own toes being stomped on.  Folks who install mods for added value (rather than just to fix bugs) would probably rather the fixpack leave their added value stuff alone, and hopefully adjusting the Priority will do the trick.  (In my own experiments it should, but I bet in Bioware's experiments they saw no problem with stealing in 1.03, eh?  )

Oh well, the cantankerous dwarf you see as my avatar is miffed I've been wasting valuable DA playtime goofing around on the forums, so I'll dive under this convenient rock and wait until the massive flamefest erupts between all those competing Duncan's Beard AddIn authors.  

[ladydesire]

Nukenin wrote...


Honestly, though, I just wish Bioware had taken the time to modernize things.

Compared to the morass that was Neverwinter Nights modding (especially if there were two groups modding the exact same 2DA files), DAO is a dream. True, there are going to be issues, but Bioware did try to learn from NWN and made DA more modder-friendly in some ways.

[TimelordDC]

Nukenin wrote...
 I've already conditioned my mind to consider higher values of Priority to mean "lower priority"

Isn't this always the case? Priority #1 means the highest priority.

[Nukenin]

TimelordDC wrote...

Nukenin wrote...
 I've already conditioned my mind to consider higher values of Priority to mean "lower priority"

Isn't this always the case? Priority #1 means the highest priority.

Yes, yes it is.    This is perhaps why it was easy to condition my mind thus.   But I look at Priority as the label for the discrete numeric value of the property itself while priority is what the numeric value represents.  Thus, lower values of Priority denote higher priority.   Higher values of Priority denote lower priority.  Up is down.  Left is right.  In is out.  

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

[Nukenin]

ladydesire wrote...

Compared to the morass that was Neverwinter Nights modding (especially if there were two groups modding the exact same 2DA files), DAO is a dream. True, there are going to be issues, but Bioware did try to learn from NWN and made DA more modder-friendly in some ways.

Yes, they did a better thing with M2DAs, especially if you're just appending rows.  When you have two groups modding the exact same row of an M2DA problem, or using the same row IDs for their respective appends—same problem, just distilled to the row-by-row level.  Are there better solutions?  Maybe we'll see Bioware move towards them in future DA releases. 

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

[ladydesire]

Nukenin wrote...

 When you have two groups modding the exact
same row of an M2DA problem, or using the
same row IDs for their respective appends—
same problem, just distilled to the row-by-row
level.  Are there better solutions?  Maybe we'll
see Bioware move towards them in future DA
releases. 

It boils down to communication and using easily available resources, like the toolset wiki and this site; that was my main annoyance in NWN2 and it still seems that some modders are deliberately trying to be incompatible by refusing to use the centralized resources Bioware made available for DAO.

[Nukenin]

ladydesire wrote...

It boils down to communication and using easily available resources, like the toolset wiki and this site; that was my main annoyance in NWN2 and it still seems that some modders are deliberately trying to be incompatible by refusing to use the centralized resources Bioware made available for DAO.

It may seem that way, but never be quick to attribute to intentional malice what can more likely be explained by ignorance, incompetence, or indifference. 

Then again, I am feverishly finishing up my ultimate BreakPack—DA ModBreaker 3000.  *diabolical laughter* 

Modifié par Nukenin, 23 avril 2010 - 01:55 .

[Proleric]

Nukenin wrote...

ladydesire wrote...

Compared to the morass that was Neverwinter Nights modding (especially if there were two groups modding the exact same 2DA files), DAO is a dream. True, there are going to be issues, but Bioware did try to learn from NWN and made DA more modder-friendly in some ways.

Yes, they did a better thing with M2DAs, especially if you're just appending rows.  When you have two groups modding the exact same row of an M2DA problem, or using the same row IDs for their respective appends—same problem, just distilled to the row-by-row level.  Are there better solutions?  Maybe we'll see Bioware move towards them in future DA releases. 

Modders can avoid using the same row ID for appends by reserving ranges - that's one of the Compatibility tips.

Modding existing rows should only be done as a last resort, because conflict there can only be a win-lose. Sometimes it can't be avoided, in which case incompatibility is inevitable unless the modders can agree a compromise (as you previously suggested).

[MOTpoetryION]

wow i could not read all those posts they just blew me away. IMO this whole issue should not even exist. For a game that was bragged about that it was 5+ years in the making .And then Sat around for 6 months while it was ported to console. And was released in this condition is pathetic. I have from day one been talking about problems with this game.(not looking for any credit) .



And have mostly just been flammed and called a troll, Where the hell were all you guys ? it would of been nice for some backup saying ,there are problems with this game.lol I thought that either all my fellow gamers have gone crazy/blind or i have . I knew there was no way i was the only one these things were happening to.



Dam im just so happy now and relieved you just dont know. Bioware should be so ashamed that the community had to fix this game. This is from a new customers point of veiw It is a bad reflection on bioware IMo. DAo was my first of theirs and have been very open of what i thought about it.I have asked this a few times but it was never answered. Have they always had this many issues with their games? And im not about to go and read all of your projects to find out if its known or not so ill just say here. i have come across a more then a few issues. like this





morragin just loves me to much. lol. sorry just trying to lighten the thread up a bit . here is one



its from redcliff if its know just say so if not ask and ill exlpain it. but i can care less for any credit

[Siegfried.m]

Hi, I know that this fix pack is compatible with Nukenin fixes, but are they included in this patch?
For example, dog and stealing fixes are included in this patch, but about the +Healing Received?
Is it included in the patch?
And is fixed the bug that you need to put the game in pause and the arrow on a character for viewing his mana and vigor?

Modifié par Siegfried.m, 23 avril 2010 - 03:32 .

[Qwinn1234]

MOT, hmm, how did you get that 2nd one to happen? I recognize the left face of the guy, he's the one who takes lyrium potions from the mage's collective, but I don't recognize the right half.



Sigfried:



My own version of fixing stealing and dog fetch has been in all releases of this mod so far, although I do not do the nifty extra floaty notifications that he does. I don't fix +Healing Received in the patch yet. I may well do so in a future release, probably not the *next* release though. That is the sort of bug that I expect Bioware *will* take care of in their next patch (they seem to prefer to focus on gameplay bugs rather than quest/scripting bugs), so I consider it slightly lower priority for fixing from my perspective.



"And is fixed the bug that you need to put the game in pause and the arrow on a character for viewing his mana and vigor?"



I haven't experienced this bug myself. Can someone fill me in on it? My characters' mana and vitality seem to update fine on their portraits.

[Siegfried.m]

ok qwinn, thank you very much for the answer. Congratulations for your devotion....maybe someone must learn this from you....
ah, please fix also some Awakening bugs

Modifié par Siegfried.m, 23 avril 2010 - 04:24 .

[Nukenin]

Proleric1 wrote...

Modders can avoid using the same row ID for appends by reserving ranges - that's one of the Compatibility tips.

Modding existing rows should only be done as a last resort, because conflict there can only be a win-lose. Sometimes it can't be avoided, in which case incompatibility is inevitable unless the modders can agree a compromise (as you previously suggested).

And we see what a wonderful tight mechanism "reserving ranges" is.  2DA ranges in use is comedy, at least.  And these are the people who are trying.   This only works well when it's done by a central, empowered authority.  Right now you will have builders who simply use the wiki as a reference but won't bother to reserve their ranges, and then some who will see some of the outlandish reserved blocks and conclude that it's not a serious, well-followed practice.

Modifying existing M2DA rows is not a "last resort"; when it's a necessity it's a necessity; when it's senseless, it's senseless.   "Last resort" is a bit sensationalist.  Nobody's going to be sweating up against a wall trying to figure out whether their new content or bugfix needs to be an M2DA append or modify-in-place.  The answer is specific to the problem at hand and never an "either/or" choice.  (Hmm, changing the cooldown of an existing ability—modify its row in ABI_base or add a completely new row along with all the changes/recompiles needed to other M2DAs and scripts to support this new skill in place of the old one?  Choosing the former is a "last resort"?  Please!)

The Compatibility page neglects any discussion of event handling, aside from some curious nonsense under "Core Script Integrity".  Folks working with events really need to discover Event Manager.  It's simple, it works, it carries the unholy specter of a "beta" tag.  Of course, it replaces engineevents M2DA conflicts with potential eventmanager M2DA conflicts should someone come up with not-quite-so-unique IDs for the rows in their eventmanager_* M2DA file.  (I just used the first six alphanumerics of my mod name converted to digits using phone number alphabetic-digit conversion for my +healing fix which hooks EVENT_TYPE_EQUIP to handle its magic.)

[Nukenin]

Siegfried.m wrote...

ok qwinn, thank you very much for the answer. Congratulations for your devotion....maybe someone must learn this from you....
ah, please fix also some Awakening bugs

We can't touch most Awakening bugs without access to the Awakening source in the Toolset.  This hasn't happened yet, and it's up in the air if it will happen.  After all, someone with the Awakening source might be able to just roll out their own, unencumbered copy of the expansion, which might concern some folks at Bioware/EA.  Not to mention the issue of how to govern access to the Awakening source in the first place; while everyone with an interest in modifying Dragon Age probably owns the game and thus the Single Player Origins campaign, it's entirely likely that not everyone downloading the toolset will own Awakening.  I suppose they can tie that specific download to those who have registered a copy of Awakening for the PC, but then again, it'd only take one bad seed to turn it around and announce "Awakening for All" on some dubious third-party site.

Gods know Awakening could use its own comprehensive fixpack.   Here's hoping 1.04 will suffice.

[MOTpoetryION]

Qwinn1234

It happend in redcliff when i was talking to the guard buy the windmill, it might of been the one for the lyrium quest . (almost positive.) As soon as i started talking to him he transported. himself, me and whole group down in front of the chantry left of the door to the blackstone guy and transposed himself in the same spot . sorry i just got back from the store. Keep in mind this was before any patches. And when redcliff was ..um problematic. Just thought i would let you all know about these

I have also seen the same thing but with the templar in denerim, that stands over by arl emons estate. he transported over to where the wife you give the notice of death to. no transposing she was already gone, same spot though that she stands at.

ive had once during a back ally fight during a pause giving a potioni was down to only one rogue with a bear pet .And was somehow able to put armor on the bear the slots where not whited out( it was before i found out going thru a waypoint you lose your pet) (lost armor also) doh

i had more, and had screenshots of most of them. but my HD crashed so i need to use brain lol

Modifié par MOTpoetryION, 25 avril 2010 - 07:14 .

[ladydesire]

Nukenin wrote...

Proleric1 wrote...

Modders can avoid using the same row ID for appends by reserving ranges - that's one of the Compatibility tips.

Modding existing rows should only be done as a last resort, because conflict there can only be a win-lose. Sometimes it can't be avoided, in which case incompatibility is inevitable unless the modders can agree a compromise (as you previously suggested).

And we see what a wonderful tight mechanism "reserving ranges" is.  2DA ranges in use is comedy, at least.  And these are the people who are trying.   This only works well when it's done by a central, empowered authority.  Right now you will have builders who simply use the wiki as a reference but won't bother to reserve their ranges, and then some who will see some of the outlandish reserved blocks and conclude that it's not a serious, well-followed practice.

I'm not sure about the "well-followed" part, but it most definitely is a serious practice; unless your comment about a central authority is a reference to Bioware assigning DA ranges, I don't think you realize how close to what you desire this is.

The Compatibility page neglects any discussion of event handling, aside from some curious nonsense under "Core Script Integrity".

What is nonsense about not modifying the core scripts directly, but instead overriding the events you want to modify?

[Nukenin]

ladydesire wrote...

I'm not sure about the "well-followed" part, but it most definitely is a serious practice; unless your comment about a central authority is a reference to Bioware assigning DA ranges, I don't think you realize how close to what you desire this is.

It's a wiki page.  An empowered, central authority would be able to say, "uh, no" to some of the ridiculous reservations that have been claimed.

And it's not what I desire.  It's what other folks need.  I could care less, except that if folks start using it properly it'll get a lot more boring to look at that page. 

ladydesire wrote...

What is nonsense about not modifying the core scripts directly, but instead overriding the events you want to modify?

Nonsense in part because "the core scripts" cover a breadth far wider than just event handling.  Take for instance fixing the stealing issues.  That requires modifying a core script directly.  There is no way, no how that could have been done by hooking an event, since there is no relevant event.

Nonsense in part because overriding events is a blatant exercise in forcing incompatibility, because unless you and everyone else hooking the same event use Event Manager (or some agreed upon counterpart), then there is no way, no how you will ever be compatible.  Only one of you wins when you all are overriding the same row in engineevents.GDA.  So the "advice" boils down to don't overwrite this; overwrite that!  Yay!

Not that I mean to be too harsh on the utility of such information to some folks.  And it'd be nice if I could bring myself to edit the page to mention Event Manager as a possible approach for folks wishing to implement event handlers in a more compatible, play-nice-with-others approach, but I'd insert some sort of snarky comment or three, and while I can get away with that in forums such as these, I feel a wiki is deserving of more social responsibility than I can accord.  (Plus, Event Manager, despite IMHO being a safe approach that will endure until Bioware decides to change event handling in Dragon Age, still carries a "beta" label and all the connotation that entails.  And it uses an ID in M2DA_base—100000—that is within Bioware's "reserved" range. )

[ladydesire]

Nukenin wrote...

ladydesire wrote...

I'm not sure about the "well-followed" part, but it most definitely is a serious practice; unless your comment about a central authority is a reference to Bioware assigning DA ranges, I don't think you realize how close to what you desire this is.

It's a wiki page.  An empowered, central authority would be able to say, "uh, no" to some of the ridiculous reservations that have been claimed.

I agree that 10 million rows is ridiculous, but the person making that mod isn't harming anyone by wanting that many in each of the files mentioned.

And it's not what I desire.  It's what other folks need.  I could care less, except that if folks start using it properly it'll get a lot more boring to look at that page. 

What is improper about posting a listing of the rows you are going to be using at least some of in your mod? The way Bioware designed DA, there are generally no limits on how many rows the 2DA files support; where known, those limits are posted.

[Nukenin]

ladydesire wrote...

I agree that 10 million rows is ridiculous, but the person making that mod isn't harming anyone by wanting that many in each of the files mentioned.
[…]What is improper about posting a listing of the rows you are going to be using at least some of in your mod? The way Bioware designed DA, there are generally no limits on how many rows the 2DA files support; where known, those limits are posted.

Nothing at all, should all those projects be serious.  That some of those projects will never happen is a disservice to the legitimate projects that appear there.  If folks would make their range reservations at a more realistic point in their project development…

…but they won't.  If folks using it don't care, what does it matter that I think it's less-than-spectacular?  I ain't using it.   (Maybe if the Duncan's Beard companion pack gets underway, or the Ferelden Gnome origins…)

[Nukenin]

I went ahead and added a little blurb on Event Handler Conflict (and mention of Event Manager as a possible solution) to the Compatibility page at the toolset Wiki.  Guilt trip wins. :innocent:

[Trefalen]

One thing to add in a future update would be to fix the goof up after the battle of Redcliffe. If NO ONE dies, the revered mother asks for a prayer for those that gave their life... right after Bann Teagan has said we ALL made it! I even tested this with "runscript killallhostiles" and made sure no one died. Guess she is hard of hearing..

Modifié par Trefalen, 24 avril 2010 - 06:58 .