Difference between revisions of "Talk:Compatibility"

Revision as of 01:03, 4 January 2011

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

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