Aller au contenu

Photo

How can I make my mod work in Awakening?


  • Veuillez vous connecter pour répondre
8 réponses à ce sujet

#1
Captain Digby

Captain Digby
  • Members
  • 5 messages
Hi all,

To teach myself how to script and the like I've been building a mod that adds a bunch of shiny new abilities to the blood mage specialization. Most of the abilities are running fairly smoothly in the main campaign, but in Awakening the abilities don't even appear. Its like the game doesn't recognize that the mod is there.

I've seen lots of threads listing which mods are compatable with Awakening, but so far none that say how you MAKE a mod that is compatible. Do I have to do something special to get the game to recognize my mod, or is some conflict causing it not to work?

Thanks in advance ^_^

#2
nezroy

nezroy
  • Members
  • 99 messages
If you followed any of the standard tutorials for creating your mod, you probably set it up to extend the "Single Player" campaign. This campaign is actually the Dragon Age: Origins story, and Dragon Age: Awakening is a different campaign. Since your mod extends Single Player (Origins) and not Awakening, it is not "active" when the player is using the Awakening campaign instead of the Origins one. That's why none of your stuff shows up in Awakening.

There are basically two options to "fix" this.

Option one is to create a second copy of your mod that extends the Awakening campaign instead of the Single Player (Origins) campaign. Since the toolset does not actually have any of the Awakening stuff yet (gee thanks BioWare, way to keep up with the mod community), you have to manually alter some of your mod files to do this. The wiki entry on compatibility explains how to do this (in the FAQ - "What if my mod extends both Single Player and
Awakening?"). The benefit of this option is that it is simple and easy to do and will probably "just work". The downside is that the player has to decide which version to install based on whether they are playing Origins or Awakening, and having both installed at the same time is probably going to cause problems. Also, your mod won't work in any future campaigns that BioWare releases, or in any player-created campaigns.

Option two is to change your mod to extend "Core Game Resources". The mod is then always availabe in any campaign (so would also be available in player addon campaigns as well). Depending on the tutorial you used, some things may already have been created "in" the Core Game Resources module (but "owned" by your custom module). This is particularly common for items (due to the item tutorial typically used), so many custom items, when created, were flagged as being "core" rather than belonging to the specifc module, and therefore transferred just fine into Awakening (though often scripts and other associated stuff wasn't, and so stops working). If you change EVERYTHING in your mod to be "in" the Core Game Resources module (but "owned" by your module), then all of that stuff will always be loaded in any campaign, and will be available in Awakening. The benefit is your stuff "works" (is available and loaded) everywhere (including future BioWare campaigns and player made campaigns) . The downsides: you increase the risk of compatibility conflicts; you have to convert your mod to extend core and not single player, which may be a little or a lot of work; for some mods it is simply impossible, because they use/need resources from Single Player; and lastly, some things just don't seem to work when you extend core. For example, I have never gotten the module script to work when extending core. PRCSCR scripts seem to work OK, as do engineevent overrides, but the module core script does not seem to ever run, so no MODULE_LOAD events, etc. For item mods in particular this isn't a problem at all, but for other things it could be a deal-breaker. (It's possible that this isn't an actual limitation with extending core, and I was just doing something wrong... since I didn't need it, however, I did not try very hard to get it working).

Modifié par nezroy, 12 mai 2010 - 06:50 .


#3
Captain Digby

Captain Digby
  • Members
  • 5 messages
Thank you very much Nezroy for your answer. I tried method two but it screwed up a few things - namely my talk tables. Method one seems to be working alright so far though. :)

#4
ladydesire

ladydesire
  • Members
  • 1 928 messages
Actually, you can't truly extend Core Game Resources, as it's not a true module; it's simply resources that are shared by all modules. Setting scripts and items as Core owned by your module and placing the gda files in the add in's core/override folder (the Origins version) and exporting the tlk file for the Awakening version should be all you need to do.

#5
Proleric

Proleric
  • Members
  • 2 350 messages
As Nezroy explained, putting things in core is not ideal, because it will cause compatibility issues.

In the OP's example (changing abilities), the risk is low, but in general if people are only trying to change DAO and Awakening it would be safer to use the first method IMO.

#6
nezroy

nezroy
  • Members
  • 99 messages
Yeah all the strings for stuff that you change to be in core need to go in your module's core talk table rather than the module one (the one in [addin]/core/data/[addin]_c-en.tlk)

I would disagree with Proleric1 about putting things in core being non-ideal as a rule. It's a judgement call based on what your module does. For item mods in particular it makes a lot of sense, actually. For other things, maybe not so much.

Modifié par nezroy, 15 mai 2010 - 02:24 .


#7
Proleric

Proleric
  • Members
  • 2 350 messages

nezroy wrote...

I would disagree with Proleric1 about putting things in core being non-ideal as a rule. It's a judgement call based on what your module does. For item mods in particular it makes a lot of sense, actually. For other things, maybe not so much.

I don't necessarily disagree with that, but it's a fairly sophisticated point of view.

We know that incompatible mods are already causing grief.

To counteract that, I'd suggest that the simple message should be "don't make the scope of a resource wider than it needs to be".

It's similar to discouraging global variables, which has been the conventional wisdom in programming for decades - only here the universe is everything the player has enabled, not simply one mod.

All rules are there to be broken on the basis of a judgement call, of course.

As it happens, I believe the ground has shifted on item mods, too. Originally, Bioware recommended making items core if they were required for multiple mods, but after Awakening launched, there was a discussion in which we agreed that method 1 was viable, too. Having said that, item mods are not as intrusive as (say) script mods, so making them core isn't especially harmful.

#8
ladydesire

ladydesire
  • Members
  • 1 928 messages
A lot of the incompatibilities could be modder induced, in that they may not be giving items unique names, or not sharing changes they make to files that should be shared with other modders. There is also the issue where modders say not to use mods with their modules and the end user refuses to follow that directive; as this has been happening since Neverwinter Nights mods were released, it's not a matter of end users not knowing the module designer's wishes so much as them ignoring them.

#9
tmp7704

tmp7704
  • Members
  • 11 156 messages

nezroy wrote...

Yeah all the strings for stuff that you change to be in core need to go in your module's core talk table rather than the module one (the one in [addin]/core/data/[addin]_c-en.tlk)

How exactly would i go about doing that? I've tried to mark the strings in my module talk table as owned by "Core Game Resources" but that just seems to prevent them from being exported at all -- they are no longer put in the module's private talk table, and the _c.tlk file exports pretty much empty, still. The end effect being the strings disappear even from the Single Player games, rather than become available in both... Posted Image

Should it be done the other way around, i.e. added manually to the core table and marked as owned by my module, instead?

edit: nevermind me, doing the latter indeed does seem to work, the strings show now in both the standard campaign and the Awakening.

Modifié par tmp7704, 24 mai 2010 - 01:55 .