48 réponses à ce sujet

[MotoEisen]

FollowTheGourd wrote...

Either that or they improve DAUpdater a bit - at least it comes with the game, so that's a huge plus.

It doesn't come with the game on Mac... doh!

Has anyone seen a workaround or heard anything official regarding this? I know they aren't planning on releasing the toolset, but the ability to *use* mods would be nice.

Modifié par MotoEisen, 24 décembre 2009 - 06:33 .

[FollowTheGourd]

MotoEisen wrote...

FollowTheGourd wrote...

Either that or they improve DAUpdater a bit - at least it comes with the game, so that's a huge plus.

It doesn't come with the game on Mac... doh!

Has anyone seen a workaround or heard anything official regarding this? I know they aren't planning on releasing the toolset, but the ability to *use* mods would be nice.

If the mod's compatible, missing DAUpdater shouldn't stop somebody determined enough... unless there are other issues to contend with on the Mac version.

It'd just be a headache if something doesn't work on the Mac version but does on the PC one. Apparently TransGaming ported it over, and I have no idea what their track record is like (probably also heavily depends on the publisher), but I hope it isn't going to wind up versions behind the PC one with its own incompatibilities.

[ladydesire]

MotoEisen wrote...

FollowTheGourd wrote...

Either that or they improve DAUpdater a bit - at least it comes with the game, so that's a huge plus.

It doesn't come with the game on Mac... doh!

Has anyone seen a workaround or heard anything official regarding this? I know they aren't planning on releasing the toolset, but the ability to *use* mods would be nice.

It should, since that's how the game installs the Bioware DLC packs; are those available to you for download and installation?

[ladydesire]

DarthParametric wrote...

The way it's packed has nothing to do with the installer. It can't do uninstalls, it can't file handle conflicts - it's not a mod installer. Hopefully DAModder will mature into something akin to TSLPatcher, which is the sort of installer the mod community requires.

With modular 2DA files (M2DA) and Builder to Builder (dadbdata), there should be no need for a tool that merges differences, as long as the modding community provides the altered source excel scripts with the Builder to Builder files if they are making changes to Bioware Official content. I won't argue the point on uninstalling, though I really don't see the need for that yet.

To clarify my meaning I want to say that I believe that it was the intention of Bioware that there be a central site where builders could make their components available for those that might not otherwise be able to get the raw scripts to make content compatible with another persons work; I maintain a NWN2 class pack that is built around commonly available content and know how much of a hassle it is to make sure I have the latest version of script sources if one of the modders whose content has been a part of my pack doesn't include them with his work.

Modifié par ladydesire, 25 décembre 2009 - 12:04 .

[MotoEisen]

ladydesire wrote...

MotoEisen wrote...

FollowTheGourd wrote...

Either that or they improve DAUpdater a bit - at least it comes with the game, so that's a huge plus.

It doesn't come with the game on Mac... doh!

Has anyone seen a workaround or heard anything official regarding this? I know they aren't planning on releasing the toolset, but the ability to *use* mods would be nice.

It should, since that's how the game installs the Bioware DLC packs; are those available to you for download and installation?

On the Mac version, the DLC Installer is a separate program that has the DLCs bundled with it. It doesn't work the same as it does on PC. 

[FollowTheGourd]

Mac client aside, I suppose here's an advantage to DAZIP being a blackbox: if your mod winds up in a compilation package, at least you can be more sure that it hasn't been restructured or renamed, and possibly help avoid future version conflicts with your own work...

Modifié par FollowTheGourd, 25 décembre 2009 - 05:40 .

[ladydesire]

FollowTheGourd wrote...

Mac client aside, I suppose here's an advantage to DAZIP being a blackbox: if your mod winds up in a compilation package, at least you can be more sure that it hasn't been restructured or renamed, and possibly help avoid future version conflicts with your own work...

Well, the only things that should need to be compatible are any core scripts that get modified; if modders don't share those, their projects simply end up incompatible with others that modify those scripts and there isn't going to be any way around it.

[FollowTheGourd]

Mainly I'm just thinking old versions of your work overriding newer versions of it, and causing problems. In my present case, there are no B2B files to provide - they're just modifications to the GUI files, which stay out of the way of anybody's DAScript changes or anything else unless they were to also edit those GUI files. I'll probably release the .flm files (not a DA:O resource) - it's just they're pretty big actually and I'm hoping for a better way to edit it in the future.

Recently, I added 2DA files, but I've made sure to properly extend them instead of replacing other core 2DAs - and the only one that's also in the core game is M2DA_base.

Modifié par FollowTheGourd, 25 décembre 2009 - 06:21 .

[TimelordDC]

Actually, even the M2DA_base is a m2da...meaning, you can extend it too.

[ladydesire]

TimelordDC wrote...

Actually, even the M2DA_base is a m2da...meaning, you can extend it too.

Which is how I do it.

[FollowTheGourd]

Yep, I have an M2DA_base_FTG_UIMod.GDA file which I use to extend it starting at the range I noted on the wiki here - I don't have row IDs for anything else, especially not the core game. None of that "break every other patch" fun.

To be more concrete about my concern: I noticed there are a couple mod packs out now that have my simple conversation fonts mod in it (among other people's - like the Winter Forge), but they renamed the mod directory and left out the README file. Basically, somebody could have it installed but not know it's from the same expanded project I'm working on. I searched it out when somebody was asking me how to configure or uninstall it, because some of the defaults were too big for their smaller screen resolution and things were off from how it should have been.

Currently it only scales up the conversation text by a fixed 50%, which makes it more ideal for 1920x1200 resolution or thereabouts (1200/768 = 1.5625).

What I want to do as soon as I finish some other work related to the UI, is go back to that and make it scale more dynamically, depending on the resolution set in game. The further your display is from 1024x768, the smaller everything gets.

But now if there's a conversation.swf file in an override directory that I'm unaware of, it might take precedence over any later changes I make to the UI file and then I'll get questions like "why is it still the same? I thought you said it scaled better now?"

I'm not against it being in a mod pack in principle, but it irks me when they don't tell me, and start changing the names and remove the README files, so when people have issues I have to go and find out what's different. At least if it's a mod pack distributed in places I wouldn't normally reach... I'd still be a bit miffed if it were on the social site, danexus, or damods. But if it's, say, bundled with an adventure as an optional install, I don't really care either. Mainly, my concern is about not having to deal with incompatible versions that could be lurking anywhere.

Modifié par FollowTheGourd, 25 décembre 2009 - 08:52 .

[Phaenan]

Well, if incompatible and/or obsolete releases of several addons are packed together, there is not much the actual authors can do : That'd be the packer's job, provided he's not just leeching for some sad and obscure reasons. Even when we knew about it that's still the packer's job to choose and/or adapt compatible versions. (and I certainly wasn't contacted by anyone ^^) (except by someone moaning about my talktable being hard to tinker with, because he was translating without permission and - duh - without my sources. I expect "his" work will also end up into some modspack, somewhere, someday) (God, do I love lengthy off-topic parenthesis)

As you said, that's more problematic for "core override mods", as opposed to "addins mods". The modifications may indeed be present twice under differents files names / paths, leading eventually to strange results.
But since we have no control over the process - 'cause a guy who didn't even ask for permission is unlikely to pay attention to remarks - I'd still say it's not something to really worry about. I, for one, will rather focus on keeping an eye on the other addons to see if things may collide somehow.

Modifié par Phaenan, 25 décembre 2009 - 10:31 .

[FollowTheGourd]

True, but just to tie it back in to my original point: it seems like just one more reason why I should use DAZIPs instead now. At least, it doesn't seem like they get casually pulled apart, so there's less hassle for a mod author there.

Modifié par FollowTheGourd, 25 décembre 2009 - 10:46 .

[JackFuzz]

Vansen Elamber wrote...

I don't understand why modders have to make the intallation of these mods more difficult then they have to be by not providing the files in .dazip format? If there is a reason for this please enlighten me, as of now I can't see why its done....

Dazip's can't be uninstalled easily.

Once you install it's stuck there and you have to disable from in game.  I guess that's fine and dandy but it's not the "right way" to do things.

Anything "installed" should have an "uninstall".

Once dazip catches up with that mentality then I'll GLADLY do dazips.

[ladydesire]

Why wait when there is a user created tool that does do what you feel DAUpdater should do? Just because I won't use it doesn't mean you should wait on Bioware to fix the one they designed for installing their DA DLC packs.

[FollowTheGourd]

Maybe we should start a "what we'd like to see in DAUpdater" page on the wiki and update it frequently.
At least it wouldn't hurt to document its current issues there. Unless there's some other place to send suggestions...

Just tried it again, and so far it seems the worst part of it is that besides appearing in the DLC page, your core override shows up in the "other campaigns" section no matter what as an unplayable module. It shows up unless you make it extend the single player campaign (or some other one)... ah well. And I'm not so sure how well it's doing at disabling/enabling core resources from the menu without requiring the game to reload, but that might be unavoidable without a lot of extra work.

Modifié par FollowTheGourd, 26 décembre 2009 - 04:17 .

[Proleric]

FollowTheGourd wrote...

...your core override shows up in the "other campaigns" section no matter what as an unplayable module. It shows up unless you make it extend the single player campaign (or some other one)...

I see that the wiki acknowledges that there is a bug which requires modules to be treated as add-ins for now. Your problem (a core add-in being treated as a module) might be a consequence of that workaround, in which case I hope Bioware will fix both issues at the same time. As a matter of interest, how is your add-in coded in the toolset, to distinguish it from a standalone module?

On the wider issue of using .DAZIP, it's clearly intended as the Builder-to-Player format. I'm very interested in the comments in this thread about components and compatibility, but where material is intended to be used by other authors, shouldn't it be in Builder-to-Builder format?

[FollowTheGourd]

Proleric1 wrote...
I see that the wiki acknowledges that there is a bug which requires modules to be treated as add-ins for now. Your problem (a core add-in being treated as a module) might be a consequence of that workaround, in which case I hope Bioware will fix both issues at the same time. As a matter of interest, how is your add-in coded in the toolset, to distinguish it from a standalone module?

I'm not entirely sure I understand the question, but here's what I'm doing. My changes are actually not created in the toolset; they're to the GUI files themselves, which the toolset doesn't help you with. So what I tried in order to make a DAZIP package (without manually creating everything) was to create a new module that doesn't extend anything, has no starting script (selected "none" explicitly), and has no content module (I also tried core resources content module to no avail). The only other thing I did was create a TLK for the module's installed content details.

Then I exported everything (none of which are the files I modified) and then copied the files modified outside of the toolset into the addin's core/data toolset-override directory so they'd get picked up in the B2P process.

Modifié par FollowTheGourd, 26 décembre 2009 - 04:54 .

[Proleric]

FollowTheGourd wrote...

Proleric1 wrote...
I see that the wiki acknowledges that there is a bug which requires modules to be treated as add-ins for now. Your problem (a core add-in being treated as a module) might be a consequence of that workaround, in which case I hope Bioware will fix both issues at the same time. As a matter of interest, how is your add-in coded in the toolset, to distinguish it from a standalone module?

I'm not entirely sure I understand the question, but here's what I'm doing. My changes are actually not created in the toolset; they're to the GUI files themselves, which the toolset doesn't help you with. So what I tried in order to make a DAZIP package (without manually creating everything) was to create a new module that doesn't extend anything, has no starting script (selected "none" explicitly), and has no content module (I also tried core resources content module to no avail). The only other thing I did was create a TLK for the module's installed content details.

Then I exported everything (none of which are the files I modified) and then copied the files modified outside of the toolset into the addin's core/data toolset-override directory so they'd get picked up in the B2P process.

In that case, it's an expected outcome that your module appears under Other Campaigns. If you want it to be treated as a pure add-in, not a module, it needs to extend something e.g. core resource.

[FollowTheGourd]

Thanks, Proleric1. I've barely spent a fraction of the time in the toolset that I've meant to; it didn't immediately occur to me to even "extend" a core resources "module".

By the looks of things, it doesn't display your mod version and URL text in the viewer, so I guess it wouldn't hurt to update the addin's TLK to specify the version in the mod title every release...

It still registers as a save game dependency, but I guess there's nothing to be done there for now. There are some other things having to do with reloading core resources when disabling the mod and not restarting the game... but I need to look further into that. It reloads some of the GUI resources, but not others, which *seems* dependant on whether they're in use at the time. It shouldn't be hard to work around that to make sure things act normally when their 2DA files aren't loaded though (they mostly already do except for some hardcoded stuff which I plan to change)... although just restarting the game would be the next best thing.

Modifié par FollowTheGourd, 27 décembre 2009 - 09:53 .

[FollowTheGourd]

I don't mean to bump my last post, but ask a new question... I guess there's no way for DAUpdater to tell somebody they're installing an older version? It just seems to happily replace whatever version is already there as long as they have the same UID. It doesn't seem to expect version numbers to be in any format I've tried so far to warn otherwise. I guess that's not a huge deal, though.

Also there's the "Cannot find DAUpdater.xml" error unless you run DAUpdater from the bin_ship directory. At least I still get that with the DVD-version on WinXP 32-bit - googled and saw some Steam users having an issue with it, too. It just means double-clicking to install might be out of the question and still cause frustration for those who think it should work.

Sure, PC users are a savvy lot, but "Program Files" is still one of those directories that Windows tells you to keep out of the first time you go there. Writing some sort of install script to run daupdater is just one more thing to go wrong (virus scanner takes issue with it for some crazy reason, or it just looks in the wrong places on somebody's system out there somewhere). But it's still better than having people mess around in the override.

Modifié par FollowTheGourd, 27 décembre 2009 - 05:03 .

[Wombybat]

I have been trying to get the DLC for a couple of weeks now. In game I was unable to see any DLC available and after tracking down some more information I realized that when the game installed the DAZIP files where missing. Downloaded the DAZIP files from http://dragonage.wik...oadable_Content installed them using daupdater.exe and was able to see them in game now. I then tried to use the redeemable code which did not work, as I had already used it in the past and I now get the "that code has already been used message" I brought the game from Steam and like a lot of people have been left with little help from both steam and Bioware as to how I get the content I paid for. What a ridiculous method to use in getting added content, I like the game but I would enjoy it more if I didn't have to spend hours trying to fix a problem that was not my fault. Reminds me of the "blue screen of death" which came with the old microsoft windows.

[AgeofWar]

Чё???

[Kilrogg_]

Very useful contribution