Bug: High M2DA ID ranges might work in the toolset, but not in game

From Dragon Age Toolset Wiki
Jump to: navigation, search
  • Version found: 1.0.1008.0
  • Status: Open

BioWare BWIcon rgb.png
This issue has been recorded in BioWare's internal tracking system.

Reference number: 213544 -BryanDerksen



High values for the ID field in various M2DA tables will appear to work correctly while testing in the toolset, but will cause various issues in the game, like missing meshes. The limit for when an ID is "low enough" to work changes depending on the M2DA being used.


Dragon Age allows to extend the built-in data tables through the M2DA process. A new .gda file is created with the same name as the original, plus an extra suffix, and it contains the data for the additional table rows. To facilitate merging this data with the native 2DA files, a unique ID must be chosen for the additional rows. If two M2DAs with identical IDs get merged, they will overwrite each other.

The valid range for this ID is at least 1 - 2 billion (2^31), with 0 - 1000000 reserved for Bioware's own use. Therefore, picking a random high number should ensure that no two addons ever have ID collisions.

The bug now appears to be, that depending on the tables that get M2DA'd, only very low ID values work correctly in game. They appear to be working as expected in the toolset, but as soon as the mod is tested, issues surface. After further trying, it seems that the affected tables only allow IDs in the 0-255 range.


Extending materialrules.gda, materialtypes.gda and ts_material.gda seems to work fine in the toolset and in game as well, values at least as high as 80000000 work perfectly well. Extending armor_massive_variation.gda does NOT work as expected. picking 1500 as ID, for example, will work in the toolset, but as soon as an armor using this variation is equipped in game, the body mesh will disappear, leaving only floating hands, feet and a head.

Using a file named "armor_massive_variation_ar.gda" with the contents:

141 Knight Champion Armor rob arc h 2 13

will work, while:

1412 Knight Champion Armor rob arc h 2 13

will not work and produce the behaviour described above.

Table Listing

This is a list of all .gda files that can be M2DA'd and whether they show this problem, and at which ranges:

Name Appears to work? (y/n) Highest tested working ID
areadata.gda Y 80141200
armor_massive_variation.gda N 141
item_sets.gda Y 80141200
Heraldry.gda Y 203
materialrules.gda Y 80141200
materialtypes.gda Y 80141200
screenshake.gda Y 80141200
ts_material.gda Y 80141200

Forum Posts

Some of the forum posts about this behaviour:

SOLVED Assigning VFX to a creature

Did toolset update break m2da process? (was placeables showing up in area editor but not game)


Steps to reproduce this behaviour:

  • Create a test module
    • Name -> M2DATest
    • UID -> m2datest
    • Extend -> Single Player
    • Module Hierarchy -> Check Single Player
  • Either copy, create or generate an armor_massive_variation M2DA in AddIns\m2datest\core\data, containing the following data:
20 Massive Armor X arm max a 2 13

(I used GDApp for this, [1] )

  • Restart the toolset
  • Create a new massive armor, by duplicating an existing one (gen_im_arm_cht_mas_hpl for example), naming it m2daarm.uti
  • Change the Item Variation to the new Massive Armor X
  • Create a script to give the armor to you, containing something like "CreateItemOnObject(R"m2daarm.uti", GetHero());"
  • Save, export

At this point you should be able to spawn the armor in game and equip it, and it should work as expected.


  • Edit the armor_massive_variation_x.gda, changing the ID field to 2000000 (two million)
  • Restart the toolset
  • Edit m2daarm.uti again, setting the Item Variation back to Massive Armor X
  • Save, export

At this point when you spawn and equip the armor, the game will either crash or the body of the character will vanish.


Only known workaround right now is to use a very very low ID, most likely in the range reserved for Bioware. This is NOT A LONG TERM OPTION, as addon collisions WILL happen.


Seems like Eshme found the reason, at least for items affected by this [2]:

The variation field in .uti files seems to be only 1 byte instead of 4 bytes, only allowing IDs 0-255 to be stored correctly.

See also