Compatibility - Revision history

Sunjammer: Reverted edits by Kelamor (talk) to last revision by Proleric1

2011-10-23T12:26:14Z

Reverted edits by Kelamor (talk) to last revision by Proleric1

Kelamor: Add in category "Need translate"

2011-02-15T06:09:19Z

Add in category "Need translate"

Proleric1: /* Open Source */

2011-01-21T01:36:46Z

‎Open Source

Proleric1: /* Resource Scope */

2011-01-08T11:34:04Z

‎Resource Scope

Proleric1: /* Resource Scope */

2011-01-08T11:33:23Z

‎Resource Scope

Proleric1: /* Resource Scope */

2011-01-08T11:32:33Z

‎Resource Scope

Gaxkang55: /* Resource Scope */ deleted sentence pending further discussion

2011-01-04T04:08:32Z

‎Resource Scope: deleted sentence pending further discussion

Gaxkang55: /* Resource Scope */

2011-01-03T04:40:51Z

‎Resource Scope

Gaxkang55: /* Tutorial to ensure your Awakening mod will not break Origins and vice versa!!! (includes screenshots and script code) */

2010-12-30T12:57:14Z

‎Tutorial to ensure your Awakening mod will not break Origins and vice versa!!! (includes screenshots and script code)

Gaxkang55: cleaned up text. this is not a discussion page, we should just provide the best advice available not have a debate.

2010-12-30T12:53:50Z

cleaned up text. this is not a discussion page, we should just provide the best advice available not have a debate.

← Older revision		Revision as of 12:26, 23 October 2011
Line 189:		Line 189:

	If you decide to do this, it's a good idea to warn players, so that they understand what's happening.		If you decide to do this, it's a good idea to warn players, so that they understand what's happening.
−
−	~~[[Category:Требуется перевод]]~~

← Older revision		Revision as of 06:09, 15 February 2011
Line 189:		Line 189:

	If you decide to do this, it's a good idea to warn players, so that they understand what's happening.		If you decide to do this, it's a good idea to warn players, so that they understand what's happening.
		+
		+	[[Category:Требуется перевод]]

← Older revision		Revision as of 01:36, 21 January 2011
Line 155:		Line 155:

	This technical wiki is not the place to discuss any legal or ethical considerations.		This technical wiki is not the place to discuss any legal or ethical considerations.
		+
		+	== Official DLC conflicts ==
		+
		+	There is a [[Bug: DLC conflicts with standalone campaigns\|bug report]] which gives the latest information on known conflicts between official DLC and standalone campaigns.

	== FAQ ==		== FAQ ==

@@ Line 98: / Line 98: @@
 Art resources posted to local are always sent to the module's core override folder. Fortunately, the core override folder only affects the campaign extended (if any), the addin and any that extend it. Most of those resources can, and should be, moved to the module folder and still work. The only exceptions are resources intended to overwrite a core game resouce.
-There are a large number of mods available that use the packages folder, creating headaches for other modders and players since such overwrites cannot be turned off in the game GUI. This technique is deprecated - mods should be distributed in the approved .dazip format without using the packages folder. See also [[#Disable_Add-Ins_:_Suggested_Disclaimer Suggested Disclaimer]].
+There are a large number of mods available that use the packages folder, creating headaches for other modders and players since such overwrites cannot be turned off in the game GUI. This technique is deprecated - mods should be distributed in the approved .dazip format without using the packages folder. See also [[#Disable_Add-Ins_:_Suggested_Disclaimer | Suggested Disclaimer]].
 == Resource Conflict ==

@@ Line 98: / Line 98: @@
 Art resources posted to local are always sent to the module's core override folder. Fortunately, the core override folder only affects the campaign extended (if any), the addin and any that extend it. Most of those resources can, and should be, moved to the module folder and still work. The only exceptions are resources intended to overwrite a core game resouce.
-There are a large number of mods available that use the packages folder, creating headaches for other modders and players since such overwrites cannot be turned off in the game GUI. This technique is deprecated - mods should be distributed in the approved .dazip format without using the packages folder. See also Disclaimer.
+There are a large number of mods available that use the packages folder, creating headaches for other modders and players since such overwrites cannot be turned off in the game GUI. This technique is deprecated - mods should be distributed in the approved .dazip format without using the packages folder. See also [[#Disable_Add-Ins_:_Suggested_Disclaimer Suggested Disclaimer]].
 == Resource Conflict ==

← Older revision		Revision as of 04:08, 4 January 2011
Line 91:		Line 91:

	By default, the toolset exports design resources to your addin's module override folder. That's a good thing, because it ensures that the scope of the resources is confined to your addin (and any that extend it). There's less risk of corrupting other people's work that way.		By default, the toolset exports design resources to your addin's module override folder. That's a good thing, because it ensures that the scope of the resources is confined to your addin (and any that extend it). There's less risk of corrupting other people's work that way.
−
−	When creating the player DAZIP, these resources should be taken out of override and put in the appropriate subfolders in your module folder. The module's override folders should only be used for changes and bug fixes, ie for overriding your own module after it has been distributed and installed.

	Never put resources in the packages folder, because that impacts every campaign. Also, once a player has installed resources there, they persist, even when your add-in is disabled. There are currently no resources known which need to be in the packages folder in order to work.		Never put resources in the packages folder, because that impacts every campaign. Also, once a player has installed resources there, they persist, even when your add-in is disabled. There are currently no resources known which need to be in the packages folder in order to work.

@@ Line 92: / Line 92: @@
 By default, the toolset exports design resources to your addin's module override folder. That's a good thing, because it ensures that the scope of the resources is confined to your addin (and any that extend it). There's less risk of corrupting other people's work that way.
-Never put resources in the packages folder, because that impacts every campaign. Also, once a player has installed resources there, they persist, even when your add-in is disabled.
+When creating the player DAZIP, these resources should be taken out of override and put in the appropriate subfolders in your module folder. The module's override folders should only be used for changes and bug fixes, ie for overriding your own module after it has been distributed and installed.
-It appears the packages folder has to be used for resources that won't load from the addins folder, namely
+Never put resources in the packages folder, because that impacts every campaign. Also, once a player has installed resources there, they persist, even when your add-in is disabled. There are currently no resources known which need to be in the packages folder in order to work.
-* The Talk Table (see [[Bug:_Talk_table_exported_to_packages_override | bug]]) that overrides existing game strings. Best practice is to avoid doing this in the first place.
+Normally, it's not a good idea to make new core resources. It's easy to make a new core resource accidentally when duplicating an official core resource, because the Owner Module defaults to core. This isn't obvious, but the resource will export to your addin's core override folder. Exception : items cannot be imported to a new campaign with the player character unless the template is included in both campaigns. One way of doing that is to make it a core resource.
-* The chargenmorphcfg.xml file, which can be used to add new morph presets for character generation.
-It was reported that tint maps needed to be in packages, but this was based on a misunderstanding.
+Art resources posted to local are always sent to the module's core override folder. Fortunately, the core override folder only affects the campaign extended (if any), the addin and any that extend it. Most of those resources can, and should be, moved to the module folder and still work. The only exceptions are resources intended to overwrite a core game resouce.
-−
-Normally, it's not a good idea to make new core resources. It's easy to make a new core resource accidentally when duplicating an official core resource, because the Owner Module defaults to core. This isn't obvious, but the resource will export to your addin's core override folder.
-−
-Exception : items cannot be imported to a new campaign with the player character unless the template is included in both campaigns. One way of doing that is to make it a core resource.
-−
-Art resources posted to local are always sent to the module's core override folder. Fortunately, the core override folder only affects the campaign extended (if any), the addin and any that extend it. Many of those resources can in any case be moved to the module folder and still work.
 There are a large number of mods available that use the packages folder, creating headaches for other modders and often users since such overwrites cannot be turned off in the game GUI. Users should be told to avoid mods whose method of installation is "place this folder in packages\override" and to delete any content that is currently in that folder. Mods not properly organised into dazips and installed with the Bioware supplied daupdater should also be deprecated, unless a good reason is given why they are being distributed that way.

@@ Line 59: / Line 59: @@
 This means that your Awakening mod will interfere with Origins and will break the game.
-Use IsUsingEP1Resources() [returns TRUE or FALSE] as the preferred of ensuring your scripts apply to the correct campaign. Origins code itself has a lot of code that was written for Awakening and in all cases, Bioware uses this function to check if Awakening is being used or not.
+Use IsUsingEP1Resources() [returns TRUE or FALSE] as the preferred method of ensuring your scripts apply to the correct campaign. Origins code itself has a lot of code that was written for Awakening and in all cases, Bioware uses this function to check if Awakening is being used or not.
 '''Addendum:''' If you have copy-pasted scripts, for example your follower join script, it can still mess your Origins mod, even with the checks implemented!!!

@@ Line 59: / Line 59: @@
 This means that your Awakening mod will interfere with Origins and will break the game.
-We will use a plot flag check to ensure that your module core script and handling scripts only trigger in Awakening.
+Use IsUsingEP1Resources() [returns TRUE or FALSE] as the preferred of ensuring your scripts apply to the correct campaign. Origins code itself has a lot of code that was written for Awakening and in all cases, Bioware uses this function to check if Awakening is being used or not.
-−
-You should insert this code in all your handling scripts:
-−
-−
-−
- if(!WR_GetPlotFlag("C0B7199C74CA4B67B143ACA8CDCFCF9D",0, TRUE))
- return;
-−
-Where "C0B7199C74CA4B67B143ACA8CDCFCF9D" is actually gxa000pt_awakening,plo, and "0", is "GXA_AWAKENING_START", but you can use any other Awakening plot that you may need.
-−
-Please read this tutorial to learn how to mod using Awakening's plot flags: http://social.bioware.com/53295/blog/10881/
-(For for people who don't know how to script, like me, this tells the game not to run the script unless GXA_AWAKENING_START is true.)
-−
-−
-Screenshots of my Awakening handling scripts with the code inserted:
-[[image:Awakening1.jpg]] [[image:Awakening2.jpg]]
-−
-'''OR'''
-−
-(From TimelordDC)
-−
-Use IsUsingEP1Resources() [returns TRUE or FALSE] instead of that plot flag check.
-−
-Origins code itself has a lot of code that was written for Awakening and in all cases, they use this function to check if Awakening is being used or not.
-−
-−
-Immortality's editor note: Instead of my code, you can use '''IsUsingEP1Resources()''', which is probably safer. :-)
-−
-And as always... BE CAREFUL! :-)
-−
-−
 '''Addendum:''' If you have copy-pasted scripts, for example your follower join script, it can still mess your Origins mod, even with the checks implemented!!!