Talk:Compatibility
What if my mod extends both Single Player and Awakening?
I moved this section here because it's under discussion. Proleric1 08:27, 21 July 2010 (UTC)
NOTE:
There is an easier way than creating two scripts. Just put the information for both in the manifest.xml file. For one of my mods, the manifest file looked like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Manifest Type="AddIn"> <AddInsList> <AddInItem UID="elf_cat_pet" Name="ELF the pet cat for DAO and Awakening" ExtendedModuleUID="Single Player" Priority="100" Enabled="1" State="2" Format="1"> <Title DefaultText="ELF the pet cat for DAO and Awakening"></Title> <Description DefaultText="ELF the pet cat adds a 'Cat Toy' to the players inventory (rest of text deleted for brevity) ((This package will work in both DAO and Awakening!))"></Description> <Image>ico_elf_cat_sleep</Image> <Rating DefaultText="10"></Rating> <RatingDescription DefaultText=""></RatingDescription> <URL DefaultText="www.ELFpath.com"></URL> <ReleaseDate>6 April 2010</ReleaseDate> <Version>2.0</Version> <GameVersion/> <Type>1</Type> <Publisher DefaultText="Angel == monkeysnest@yahoo.com"></Publisher> <PrereqList/> <FileList> <Folder src="packages/" Type="package"/> <Folder src="addins/" Type="addin"/> </FileList> </AddInItem> <AddInItem UID="elf_cat_pet" Name="ELF the pet cat for DAO and Awakening" ExtendedModuleUID="DAO_PRC_EP_1" Priority="100" Enabled="1" State="2" Format="1"> <Title DefaultText="ELF the pet cat"></Title> <Image>ico_elf_cat_sleep</Image> <Rating DefaultText=""></Rating> <RatingDescription DefaultText=""></RatingDescription> <URL DefaultText="www.ELFpath.com"></URL> <ReleaseDate>6 April 2010</ReleaseDate> <Version>2.0</Version> <GameVersion/> <Type>1</Type> <Publisher DefaultText="Angel == monkeysnest@yahoo.com"></Publisher> <PrereqList/> <FileList> <Folder src="addins/" Type="addin"/> </FileList> </AddInItem> </AddInsList> </Manifest>
doing this allowed users to install one package (using DAModder) which worked for both awakening and DAO.
============== ++ Angel
@monkeysnest - good to have the update concerning the manifest. A few queries:
- Perhaps the article would be clearer if you explained which line has to change, rather than reproduce the entire manifest here?
- Would DAUpdater work? I don't see DAModder listed as a project download on the Bioware social site.
- We don't normally leave our signatures on the content pages of a wiki.
Thanks.
Proleric1 05:47, 8 April 2010 (UTC)
I don't think the "dual entry, single manifest" approach should be followed or encouraged. Creating two separate .dazip installations as mentioned in Compatibility: What if my mod extends both Single Player and Awakening? is IMHO the preferred approach.
--Nukenin 00:24, 24 April 2010 (UTC)
I'll have to agree with Nukenin here, especially since using the "dual entry, single manifest" approach will cause DAUpdater to crash and would unnecessarily force players to use third-party apps. Moreover, it's perfectly possible to include several addons (each one with its own manifest entry) in a single dazip package :
- Package root
- Manifest including several AddInItem elements
- Contents
- addins
- addin_uid1
- addin_uid2
- addin_uid3
- etc
- packages
- addins
--Phaenan 06:45, 21 July 2010 (UTC)
I find myself agreeing with Phaenan and Nukenin on this; end users should only use community created tools if they want a specific function that's only available to them that way (like the ability to uninstall a dazip). Ladydesire 18:40, 25 December 2010 (UTC)
Override Events while minimizing compat issues..
I believe this may be useful to others - through trial and error, and with some help, I have figured out a way to override events only when my module is running - I had to add a variable to var_module.xls/gda (which is probably where the only potential compatibility issue will arise via string ID, though I am not sure what would happen if someone tried to override the same events - depends on which engineevents get's loaded last I suppose...).
The variable is defaulted to a 0....in my modules properties, I set the variable to a 1. My event overrides check for this variable to be == 1, if not, send it off the proper handler.
See the following post where I came to this 'workaround'...would love to know if there is a better way:
http://social.bioware.com/forum/1/topic/8/index/2371093/1#2531362
Resource scope edit
I have removed the reference to tint maps following the discussion at http://social.bioware.com/group/2937/discussion/12738/ .
Also beefed up the recommendations about not putting files into packages --Gaxkang55 12:43, 30 December 2010 (UTC)
Good update! I'm very much on the same wavelength. I have one question, though, concerning the Talk Table. Normally, the best way to change a core string is to make a new one, then point the appropriate 2DA at it. However, there are cases where no such mechanism exists. For example, if you want to make a module that isn't set in the Ferelden gameworld, you need to change the gender descriptions, replace all instances of "marabi" with "dog" and so on. To the best of my knowledge, this can't be done without an override - see String_editor. If there's a better solution, I'd be keen to hear it. Proleric1 08:50, 31 December 2010 (UTC)
As it happens, I had to do exactly that for the campaign I have in development, where I wanted to override the gender description. Create the string but make the Owner Module your module. This will be exported to the talktable placed in your core, and will overwrite the core string as long as your module is enabled. Also tested the head morph stuff, and that doesn't need to be in packages either, so will make a further update. --Gaxkang55 04:28, 3 January 2011 (UTC)
Have you tried to reproduce this bug for the specific string mentioned there? I double-checked that the Owner Module is set correctly. It isn't exported to the talk table in core (which seems to be empty), nor does it work if the talk table in packages override is moved to any of the add-in folders.
A couple of other issues:
You recommend moving content from the override folders before B2P packaging. Is there any technical reason for that? I haven't heard this from Bioware. "If it ain't bust, don't fix it" might apply here?
You've added some strong words about mods that use packages override. My heart is with you, but my head says the tone could be counter-productive. We seem to be making some progress with persuading the community that compatibility is important, but the "package overriders" are still in the majority. IMO we need to convince them to change their approach voluntarily, not antagonise them. After all, none of us has the power to deprecate anything (nor would we wish to have it). What do you think? Proleric1 08:27, 3 January 2011 (UTC)
Moving the compiled scripts and exported plots out of the toolsetexport folder into the override folder is a good idea, since when doing an "empty export directories", you could accidently delete files needed for the builder to player package. I'm not sure why it would be necessary to move files out of the override folder.
As far as the "package overriders" go, some may never change, no matter what we do; I have even seen people that were doing it basically the right way change because they weren't wanting to build multiple packages for their mods. Ladydesire 00:03, 4 January 2011 (UTC)
1. I have deleted the sentence about DAZIPs. On re-reading it actually compresses together two different ideas, and in any case doesn't really belong there. I will have a rethink about this when I have a bit more time on the weekend :-)
2. Proleric, the string I override is the gender description string 377283. I export the talktable (which creates the three files) and delete the one in packages, core_en-us.tlk, together with everything else there). Start my game and the string in overwritten correctly by the <uid>_c_en-us.tlk table.
3. On the issue of packages override, the issue is whether or not this wiki contains correct information and procedures. If someone disagrees that this is the correct procedure (particularly in terms of mod inter-compatibility), I am more than happy to have the discussion. I suspect real change is only going to happen if the end-users start complaining in the comments sections of the download pages, but that's another story. In the meantime, the wiki should stick to the straight and narrow of providing the best information we can assemble --Gaxkang55 04:37, 4 January 2011 (UTC)
1. Thanks.
2. Issue closed. EDIT Proleric1 17:16, 4 January 2011 (UTC) It is not necessary to put a talk table in packages override. Instead of changing core strings, it's better to refer to new strings in the 2DA files (even though finding them is a lot of work when making a global change, such as "Marabi" to "Dog". The gender description string does have to be overridden, but since it's only used in character generation, it's not affected by the save-load bug.
3. Agreed. However, the wiki is about practical advice. The section in question talks about deprecating other people's stuff, which is beyond the reader's control! Instead, I suggest a two-pronged approach. Firstly, we already have the Disclaimer section of this article. Secondly, contribute to the project which is developing an FAQ for players. Just my 2 cents. Proleric1 08:33, 4 January 2011 (UTC)
On 3, since most players assume that the modder knows best, or are from a game where adding mods can only be done in a specific directory (TES III and TES IV, Fallot 3 and Fallout: New Vegas, just for a few examples), they won't be the ones to complain about having to do that. We should be suggesting the use of modules/Single Player/override for Origins content, addins/<uid>/module/override for things for DLCs (where uid is the folder name of the specific DLC (I listed several of them in the Module Priority tutorial) instead of packages/core/override if a mod must use the override. The only mods that need to be done this way are compatibility files for various mods that might be editing the same files, at least as far as I'm concerned; everything else should be done as dazips. Ladydesire 23:26, 6 January 2011 (UTC)
Just on the term "deprecated", this is really a technical term in software development and deployment, and does not carry a value judgement. It simply means a superseded method that should no longer be used. This is a developer not a player wiki, and the use of the term is entirely appropriate, imho --Gaxkang55 07:56, 8 January 2011 (UTC)
OK I had a go at rewording, to emphasise that it is the technique which is deprecated, not the mods. Only players have the power to deprecate (i.e. cease using and/or archive) mods, which I've reiterated in the form of a link to the Disclaimer section. What do you think?
@ladydesire : you might want to do an edit to capture your thoughts above. I don't disagree, but you know a lot more than I about how to mod the OC. Proleric1 11:43, 8 January 2011 (UTC)
That edit looks fine to me.
On the separate issue of what should be in the core and what in the module folders of you <uid> folder, I am actually scheduled to do some testing on this very question for my own campaign (in dev), and will return to this issue for this page in a week or two --Gaxkang55 08:26, 10 January 2011 (UTC)
