Dragon Age Toolset Wiki - User contributions [en]

Talk:Lighting

2010-02-11T04:33:27Z

ThebigMuh: /* Processing Time */

== Article Updates ==
Writing here as a scratch pad for topics that could probably go into the main page.
:Trying to answer a few of those topics here. Posted on the forums that I want to write a nice big lighting article, but so far no additional hours between the standard 24 have materialized in my days :P [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)

=== Character and level lights ===

There doesn't seem to be a strong emphasis about character vs. level lights. Reading it the first time it sounds like the difference might be between baked and static lights, but apparently there's a property field "Affects Characters" in the light's property sheet.
:Characters can't be affected by baked lights (that one should be obvious). Static and Dynamic lights can affect characters (and area placeables) by setting the "Affects Characters" true. Should only be done fore extremely prominent light sources for in-level lights, light for huge bonfires or similar stuff, all other character lighting should be done with separate character lighting rooms (see below) [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)
::Yep, baked lights I understood not affecting the character. It's just the wiki description might make it seem like a static light should. Dedicated character-lighting rooms is an interesting design... probably worthy of a proper write up in the main article or an article of its own even. --[[User:FollowTheGourd|FollowTheGourd]] 14:55, 10 February 2010 (UTC)

Looking at some of the Orzammar level layouts, it seems that the designers made some of the character lights have an incredibly large point radius for point static-lights to assumably light most of the level (100,000 in Orz000d.lvl to even the lava's 5,000,000 in Orz100d.lvl). I suppose the performance for doing that is OK and what matters is how many lights are overlapping or maybe other considerations...? These huge ones are also placed far out of the level, but that might just be for organization reasons given how large they are anyway.
:Bioware seems to have handled their character lighting as follows, which works really well, is light on processing power, and very customizible:
:The lights in all their rooms are set to only light the level (the default setting). Only exemption are extremely prominent lights - huge fires, a fat ray of sunlight in a dark cavern, similar stuff. To get character lights, they created new empty rooms with a few lights in them, usually a three point setup. Those three are set to light characters only, not the level. Then, through the room properties, the add all affected rooms to the "These rooms are LIT by lights from the currently selected room:" list. Example: Orz700d.lvl, Caridin's Cross. Consists of 12 "normal" rooms, and 4 character lighting rooms. The lighting rooms only contain static lights that affect several other rooms, with each lighting room giving a certain lighting "mood". [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)
::Interesting. The main wiki article makes it less than clear about how rooms are affected by other rooms. In one paragraph it says it needs to be added to a list, while in another it just talks about "visibility". I suspect it still needs to be added to the list though - of course I could just experiment more. --[[User:FollowTheGourd|FollowTheGourd]] 14:55, 10 February 2010 (UTC)

=== Light Probes ===

Besides water, is there any easy way to know when you should place a light probe? In the Orzammar levels, they seem to be around lava, but that doesn't appear to be reflective. Armour doesn't seem to reflect things, so I'm not sure what they're being used for here.
:Always use lightprobes. And armor actually does reflect things (but only lightprobes), as do stone, wood, snow and pretty much all surfaces in the game. As here: [http://social.bioware.com/forum/1/topic/74/index/1106677] [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)

::Unfortunately there's currently a bug involving multiple light probes: [[Bug: multiple light probes all generate the same reflection]]. If there's a workaround, we don't know it. :( [[User:BryanDerksen|BryanDerksen]] 17:21, 10 February 2010 (UTC)
:::Hah, no kidding - just checked my level and all light probes show exactly the same reflection map. I didn't notice it because the reflections work nicely for each room in my cave system :) It seems the last probe being rendered gets used, so it's easy to pick one reasonably representative location and make that THE probe for the level. [[User:ThebigMuh|ThebigMuh]] 19:05, 10 February 2010 (UTC)

=== Pointers for Num Samples ===

It seems some of the fires and other baked lights usually have about 20 for ''Num Samples'', where the main article says that should make the shadows crisper. I'll have to play around with that to see the different results, but the levels have so-called "bounce lights" which might be worth writing about if they're a useful design concept.
:First of all - I'm 99.98% certain that BioWare used a different rendering engine for calculating their lightmaps than the Yafray thing included with the toolset. Since they are 3DS MAX users, my bet is on mental ray or something similar. There are several options and settings that do not currently get exported to eclipseray via the lightmapper script, most notably normals (horrible!!!), but also other stuff. Num Samples is a candidate for such a non-exported thing. In a normal rendering context I'd say the num samples parameter sets the number of shadow map samples that are taken (which would also fit the description here on the lighting page). Since it's in the "Soft Shadows" category on the light, I'd rather think that it sets the number of sample rays to get soft shadows from are light sources. Doesn't work, btw., and neither does creating an area light source via the Light Size parameter. [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)

=== Processing Time ===

There doesn't seem to be a ''lot'' of feedback from the toolset when it's still generating your lightmaps. If you get impatient and toggle showing them, then you might run into an error with temporary directories. For some bigger levels it takes my system about 6 minutes to finish them... I'm sure that'll will vary wildly. In the meantime, I've just opened the windows task manager as an assurance that the process is still running.
:6 minutes? Do you have a render farm or something? Calculating a single room can take more than 20 minutes in the level I'm working on, and it has 6 rooms so far :P [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)
::Well... I think that was for the Orzammar Hall of Heroes and maybe some others (can't recall why I wrote "bigger" anymore). It took me about 2h 40m to do the Orzmmar Commons, and that while doing other stuff on the machine as well. --[[User:FollowTheGourd|FollowTheGourd]] 15:01, 10 February 2010 (UTC)
:::Here's a way to get a bit more feedback from the lightmapper: Go to Tools->Options, select Level Editor, and in the Lightmapper Command field remove the "--terse" part from the command line. You'll now get a log entry for each unwrapped surface that is being rendered. [[User:ThebigMuh|ThebigMuh]] 04:33, 11 February 2010 (UTC)

== Lighting Bugs ==
OK, lighting is borked for creating new levels. Lets get some conversation going that doesn't get buried under endless posts about making characters bi and taking their clothes off :p I'll start by listing the bugs we have found so far.

# The lightmap 'cracks' along chunk boundaries in terrain levels, producing unexplained shadows.
# Sunlight doesn't work in terrain levels. An ambient light must be added
# Water is broken in game. Looks fine in editor, but non-existent in game.

Reproduction Steps: All steps assume starting with a clean terrain level built with these options:

[[File:ExtLevelOptions.png|thumb|none]]

=== Base Steps ===

And all have the following basic steps:

# Save the level
# Add export area
# Define area - set the green square to cover the entire mesh
# Add a start point roughly in the center - Possible bug? If I add the start point before the area, path finding will not recognize it.
# Set start point in export area
# Click Render Lightmaps
# Toggle Lightmap on and Fully Lit off to verify there is no light. This confirms bug 2, no sunlight. Unless I've missed where it says sunlight doesn't act like, well, sunlight.
# Add a light roughly in center. Change type to Ambient, Postion.Z to 25
# Toggle Lightmap off
# Hit the Render Lightmap button
# Toggle Lightmap back on to verify ambient is working. I have never seen lightmap cracking at this point.

Phew. And I don't really want to admit how many times I've gone through this.

=== Lightmap Cracking ===
This one is beating me. I cannot come up with a 100% sure-fire way to force cracking. This time it happened when I did a full local post for the second time. If someone can come up with repro steps, it would be much appreciated. Here's a screen shot of the cracked level. Edit: Messing around and noticed that the cracking happened again on the second Do All Local Posts. However it's 1am so further testing will have to wait.

Edit from [[User:Languard|Languard]]:Dug a hole and placed three baked point lights to light it up. After rendering lightmaps and before posting, the lightmaps cracked. Tried to reproduce but on the second time instead of cracking, one chunk became fully lit and completely unaffected by baked point lights.

Edit from [[User:Ainiana|Ainiana]]:In my experience the 'cracked' light map appears to occur when multiple baked lights are applied to the same exterior area. I have also have experienced the 'one chunk unaffected by baked point lights' on another occasion (this only took 1 baked light to reproduce). On all occasions water was not visible in game when testing (using the steps outlined below).

An example of a 'cracked' lightmap.
[[File:lightmapCrack.png|thumb|none]]

:We've seen this internally as well, there appears to be a bug with how sunlight is handled. Our lightmapper guru has had the bug passed on to him so hopefully a fix will come along soon but at this point we don't know exactly what's wrong so we can't give any sort of estimate. [[User:BryanDerksen|BryanDerksen]] 17:49, 16 November 2009 (UTC)

Lightmapping guru here: If anyone sees this happening, please send me the level via our support email. I have played around with sunlight with the lightmapper on my own machine and can not repro it here, so I need your help.

Update 11/24/09: Bug squashed! Head on over to http://social.bioware.com/social.bioware.com/project/717/ to get the new files (you will need the new eclipseray.exe binary)

=== No Water ===
# Use the deform tool to dig a hole
# Right-Click->Insert->New Water Mesh
# Drag it over to the hole
# Make it large enough to cover the hole
# Right-Click->Insert->New Light Probe
# Drag light probe so that is roughly centered on the water and slightly above it
# Place some small oaks around for reflection
# Render Lightmaps
# Render Light Probes
# Verify that yes, it looks correct [[File:levelWater.png|thumb|none]]
# Do All Local Posts
# Save and close level
# Create new area, set level as layout
# Add a waypoint
# Override Export starting area
# Get into game, verify that water is...missing
[[File:ingameNoWater.png|thumb|none]]

Please, if anyone else has anything to add to this, do so. The more info we can concentrate here, the easier it will be for BioWare to fix this :)

:The missing water planes actually doesn't have anything to do with the light mapper, it's a separate system. We've got someone looking at that to see what's going on. [[User:BryanDerksen|BryanDerksen]] 23:51, 24 November 2009 (UTC)

:Found a workaround: [[Bug: Water plane missing in-game]] [[User:BryanDerksen|BryanDerksen]] 23:37, 25 November 2009 (UTC)

=== Lightmapper Glitch ===

This glitch appears to be something to do with the configuration of the lightmapper or the script itself.

[[File:Chantry2.JPG|thumb|none]]

It was tested on a BioWare computer in an attempt to figure it out and appeared to work fine there. It may be packaged incorrectly, or there may of been a fault with the installation.

Compiling lightmaps appears to work before a certain amount of props have been added, after which this bug begins to appear. At first, I installed Python 2.6, after which I uninstalled that and installed 2.5. Could this of caused any problems?

~ Shadow180

== New lightmapper ==

We've got a new lightmapper going up at the [http://social.bioware.com/project/717/ lightmapper project] shortly that should hopefully fix a lot of the issues that have been reported above. Check it out and see if it solves things for you. (It won't solve the missing water plane issue, that's something separate that we're still investigating). [[User:BryanDerksen|BryanDerksen]] 23:51, 24 November 2009 (UTC)

Talk:Lighting

2010-02-10T19:05:15Z

ThebigMuh: /* Light Probes */

== Article Updates ==
Writing here as a scratch pad for topics that could probably go into the main page.
:Trying to answer a few of those topics here. Posted on the forums that I want to write a nice big lighting article, but so far no additional hours between the standard 24 have materialized in my days :P [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)

=== Character and level lights ===

There doesn't seem to be a strong emphasis about character vs. level lights. Reading it the first time it sounds like the difference might be between baked and static lights, but apparently there's a property field "Affects Characters" in the light's property sheet.
:Characters can't be affected by baked lights (that one should be obvious). Static and Dynamic lights can affect characters (and area placeables) by setting the "Affects Characters" true. Should only be done fore extremely prominent light sources for in-level lights, light for huge bonfires or similar stuff, all other character lighting should be done with separate character lighting rooms (see below) [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)
::Yep, baked lights I understood not affecting the character. It's just the wiki description might make it seem like a static light should. Dedicated character-lighting rooms is an interesting design... probably worthy of a proper write up in the main article or an article of its own even. --[[User:FollowTheGourd|FollowTheGourd]] 14:55, 10 February 2010 (UTC)

Looking at some of the Orzammar level layouts, it seems that the designers made some of the character lights have an incredibly large point radius for point static-lights to assumably light most of the level (100,000 in Orz000d.lvl to even the lava's 5,000,000 in Orz100d.lvl). I suppose the performance for doing that is OK and what matters is how many lights are overlapping or maybe other considerations...? These huge ones are also placed far out of the level, but that might just be for organization reasons given how large they are anyway.
:Bioware seems to have handled their character lighting as follows, which works really well, is light on processing power, and very customizible:
:The lights in all their rooms are set to only light the level (the default setting). Only exemption are extremely prominent lights - huge fires, a fat ray of sunlight in a dark cavern, similar stuff. To get character lights, they created new empty rooms with a few lights in them, usually a three point setup. Those three are set to light characters only, not the level. Then, through the room properties, the add all affected rooms to the "These rooms are LIT by lights from the currently selected room:" list. Example: Orz700d.lvl, Caridin's Cross. Consists of 12 "normal" rooms, and 4 character lighting rooms. The lighting rooms only contain static lights that affect several other rooms, with each lighting room giving a certain lighting "mood". [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)
::Interesting. The main wiki article makes it less than clear about how rooms are affected by other rooms. In one paragraph it says it needs to be added to a list, while in another it just talks about "visibility". I suspect it still needs to be added to the list though - of course I could just experiment more. --[[User:FollowTheGourd|FollowTheGourd]] 14:55, 10 February 2010 (UTC)

=== Light Probes ===

Besides water, is there any easy way to know when you should place a light probe? In the Orzammar levels, they seem to be around lava, but that doesn't appear to be reflective. Armour doesn't seem to reflect things, so I'm not sure what they're being used for here.
:Always use lightprobes. And armor actually does reflect things (but only lightprobes), as do stone, wood, snow and pretty much all surfaces in the game. As here: [http://social.bioware.com/forum/1/topic/74/index/1106677] [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)

::Unfortunately there's currently a bug involving multiple light probes: [[Bug: multiple light probes all generate the same reflection]]. If there's a workaround, we don't know it. :( [[User:BryanDerksen|BryanDerksen]] 17:21, 10 February 2010 (UTC)
:::Hah, no kidding - just checked my level and all light probes show exactly the same reflection map. I didn't notice it because the reflections work nicely for each room in my cave system :) It seems the last probe being rendered gets used, so it's easy to pick one reasonably representative location and make that THE probe for the level. [[User:ThebigMuh|ThebigMuh]] 19:05, 10 February 2010 (UTC)

=== Pointers for Num Samples ===

It seems some of the fires and other baked lights usually have about 20 for ''Num Samples'', where the main article says that should make the shadows crisper. I'll have to play around with that to see the different results, but the levels have so-called "bounce lights" which might be worth writing about if they're a useful design concept.
:First of all - I'm 99.98% certain that BioWare used a different rendering engine for calculating their lightmaps than the Yafray thing included with the toolset. Since they are 3DS MAX users, my bet is on mental ray or something similar. There are several options and settings that do not currently get exported to eclipseray via the lightmapper script, most notably normals (horrible!!!), but also other stuff. Num Samples is a candidate for such a non-exported thing. In a normal rendering context I'd say the num samples parameter sets the number of shadow map samples that are taken (which would also fit the description here on the lighting page). Since it's in the "Soft Shadows" category on the light, I'd rather think that it sets the number of sample rays to get soft shadows from are light sources. Doesn't work, btw., and neither does creating an area light source via the Light Size parameter. [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)

=== Processing Time ===

There doesn't seem to be a ''lot'' of feedback from the toolset when it's still generating your lightmaps. If you get impatient and toggle showing them, then you might run into an error with temporary directories. For some bigger levels it takes my system about 6 minutes to finish them... I'm sure that'll will vary wildly. In the meantime, I've just opened the windows task manager as an assurance that the process is still running.
:6 minutes? Do you have a render farm or something? Calculating a single room can take more than 20 minutes in the level I'm working on, and it has 6 rooms so far :P [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)
::Well... I think that was for the Orzammar Hall of Heroes and maybe some others (can't recall why I wrote "bigger" anymore). It took me about 2h 40m to do the Orzmmar Commons, and that while doing other stuff on the machine as well. --[[User:FollowTheGourd|FollowTheGourd]] 15:01, 10 February 2010 (UTC)

== Lighting Bugs ==
OK, lighting is borked for creating new levels. Lets get some conversation going that doesn't get buried under endless posts about making characters bi and taking their clothes off :p I'll start by listing the bugs we have found so far.

# The lightmap 'cracks' along chunk boundaries in terrain levels, producing unexplained shadows.
# Sunlight doesn't work in terrain levels. An ambient light must be added
# Water is broken in game. Looks fine in editor, but non-existent in game.

Reproduction Steps: All steps assume starting with a clean terrain level built with these options:

[[File:ExtLevelOptions.png|thumb|none]]

=== Base Steps ===

And all have the following basic steps:

# Save the level
# Add export area
# Define area - set the green square to cover the entire mesh
# Add a start point roughly in the center - Possible bug? If I add the start point before the area, path finding will not recognize it.
# Set start point in export area
# Click Render Lightmaps
# Toggle Lightmap on and Fully Lit off to verify there is no light. This confirms bug 2, no sunlight. Unless I've missed where it says sunlight doesn't act like, well, sunlight.
# Add a light roughly in center. Change type to Ambient, Postion.Z to 25
# Toggle Lightmap off
# Hit the Render Lightmap button
# Toggle Lightmap back on to verify ambient is working. I have never seen lightmap cracking at this point.

Phew. And I don't really want to admit how many times I've gone through this.

=== Lightmap Cracking ===
This one is beating me. I cannot come up with a 100% sure-fire way to force cracking. This time it happened when I did a full local post for the second time. If someone can come up with repro steps, it would be much appreciated. Here's a screen shot of the cracked level. Edit: Messing around and noticed that the cracking happened again on the second Do All Local Posts. However it's 1am so further testing will have to wait.

Edit from [[User:Languard|Languard]]:Dug a hole and placed three baked point lights to light it up. After rendering lightmaps and before posting, the lightmaps cracked. Tried to reproduce but on the second time instead of cracking, one chunk became fully lit and completely unaffected by baked point lights.

Edit from [[User:Ainiana|Ainiana]]:In my experience the 'cracked' light map appears to occur when multiple baked lights are applied to the same exterior area. I have also have experienced the 'one chunk unaffected by baked point lights' on another occasion (this only took 1 baked light to reproduce). On all occasions water was not visible in game when testing (using the steps outlined below).

An example of a 'cracked' lightmap.
[[File:lightmapCrack.png|thumb|none]]

:We've seen this internally as well, there appears to be a bug with how sunlight is handled. Our lightmapper guru has had the bug passed on to him so hopefully a fix will come along soon but at this point we don't know exactly what's wrong so we can't give any sort of estimate. [[User:BryanDerksen|BryanDerksen]] 17:49, 16 November 2009 (UTC)

Lightmapping guru here: If anyone sees this happening, please send me the level via our support email. I have played around with sunlight with the lightmapper on my own machine and can not repro it here, so I need your help.

Update 11/24/09: Bug squashed! Head on over to http://social.bioware.com/social.bioware.com/project/717/ to get the new files (you will need the new eclipseray.exe binary)

=== No Water ===
# Use the deform tool to dig a hole
# Right-Click->Insert->New Water Mesh
# Drag it over to the hole
# Make it large enough to cover the hole
# Right-Click->Insert->New Light Probe
# Drag light probe so that is roughly centered on the water and slightly above it
# Place some small oaks around for reflection
# Render Lightmaps
# Render Light Probes
# Verify that yes, it looks correct [[File:levelWater.png|thumb|none]]
# Do All Local Posts
# Save and close level
# Create new area, set level as layout
# Add a waypoint
# Override Export starting area
# Get into game, verify that water is...missing
[[File:ingameNoWater.png|thumb|none]]

Please, if anyone else has anything to add to this, do so. The more info we can concentrate here, the easier it will be for BioWare to fix this :)

:The missing water planes actually doesn't have anything to do with the light mapper, it's a separate system. We've got someone looking at that to see what's going on. [[User:BryanDerksen|BryanDerksen]] 23:51, 24 November 2009 (UTC)

:Found a workaround: [[Bug: Water plane missing in-game]] [[User:BryanDerksen|BryanDerksen]] 23:37, 25 November 2009 (UTC)

=== Lightmapper Glitch ===

This glitch appears to be something to do with the configuration of the lightmapper or the script itself.

[[File:Chantry2.JPG|thumb|none]]

It was tested on a BioWare computer in an attempt to figure it out and appeared to work fine there. It may be packaged incorrectly, or there may of been a fault with the installation.

Compiling lightmaps appears to work before a certain amount of props have been added, after which this bug begins to appear. At first, I installed Python 2.6, after which I uninstalled that and installed 2.5. Could this of caused any problems?

~ Shadow180

== New lightmapper ==

We've got a new lightmapper going up at the [http://social.bioware.com/project/717/ lightmapper project] shortly that should hopefully fix a lot of the issues that have been reported above. Check it out and see if it solves things for you. (It won't solve the missing water plane issue, that's something separate that we're still investigating). [[User:BryanDerksen|BryanDerksen]] 23:51, 24 November 2009 (UTC)

Talk:Lighting

2010-02-10T03:26:57Z

ThebigMuh:

== Article Updates ==
Writing here as a scratch pad for topics that could probably go into the main page.
:Trying to answer a few of those topics here. Posted on the forums that I want to write a nice big lighting article, but so far no additional hours between the standard 24 have materialized in my days :P [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)

=== Character and level lights ===

There doesn't seem to be a strong emphasis about character vs. level lights. Reading it the first time it sounds like the difference might be between baked and static lights, but apparently there's a property field "Affects Characters" in the light's property sheet.
:Characters can't be affected by baked lights (that one should be obvious). Static and Dynamic lights can affect characters (and area placeables) by setting the "Affects Characters" true. Should only be done fore extremely prominent light sources for in-level lights, light for huge bonfires or similar stuff, all other character lighting should be done with separate character lighting rooms (see below) [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)

Looking at some of the Orzammar level layouts, it seems that the designers made some of the character lights have an incredibly large point radius for point static-lights to assumably light most of the level (100,000 in Orz000d.lvl to even the lava's 5,000,000 in Orz100d.lvl). I suppose the performance for doing that is OK and what matters is how many lights are overlapping or maybe other considerations...? These huge ones are also placed far out of the level, but that might just be for organization reasons given how large they are anyway.
:Bioware seems to have handled their character lighting as follows, which works really well, is light on processing power, and very customizible:
:The lights in all their rooms are set to only light the level (the default setting). Only exemption are extremely prominent lights - huge fires, a fat ray of sunlight in a dark cavern, similar stuff. To get character lights, they created new empty rooms with a few lights in them, usually a three point setup. Those three are set to light characters only, not the level. Then, through the room properties, the add all affected rooms to the "These rooms are LIT by lights from the currently selected room:" list. Example: Orz700d.lvl, Caridin's Cross. Consists of 12 "normal" rooms, and 4 character lighting rooms. The lighting rooms only contain static lights that affect several other rooms, with each lighting room giving a certain lighting "mood". [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)

=== Light Probes ===

Besides water, is there any easy way to know when you should place a light probe? In the Orzammar levels, they seem to be around lava, but that doesn't appear to be reflective. Armour doesn't seem to reflect things, so I'm not sure what they're being used for here.
:Always use lightprobes. And armor actually does reflect things (but only lightprobes), as do stone, wood, snow and pretty much all surfaces in the game. As here: [http://social.bioware.com/forum/1/topic/74/index/1106677] [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)

=== Pointers for Num Samples ===

It seems some of the fires and other baked lights usually have about 20 for ''Num Samples'', where the main article says that should make the shadows crisper. I'll have to play around with that to see the different results, but the levels have so-called "bounce lights" which might be worth writing about if they're a useful design concept.
:First of all - I'm 99.98% certain that BioWare used a different rendering engine for calculating their lightmaps than the Yafray thing included with the toolset. Since they are 3DS MAX users, my bet is on mental ray or something similar. There are several options and settings that do not currently get exported to eclipseray via the lightmapper script, most notably normals (horrible!!!), but also other stuff. Num Samples is a candidate for such a non-exported thing. In a normal rendering context I'd say the num samples parameter sets the number of shadow map samples that are taken (which would also fit the description here on the lighting page). Since it's in the "Soft Shadows" category on the light, I'd rather think that it sets the number of sample rays to get soft shadows from are light sources. Doesn't work, btw., and neither does creating an area light source via the Light Size parameter. [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)

=== Processing Time ===

There doesn't seem to be a ''lot'' of feedback from the toolset when it's still generating your lightmaps. If you get impatient and toggle showing them, then you might run into an error with temporary directories. For some bigger levels it takes my system about 6 minutes to finish them... I'm sure that'll will vary wildly. In the meantime, I've just opened the windows task manager as an assurance that the process is still running.
:6 minutes? Do you have a render farm or something? Calculating a single room can take more than 20 minutes in the level I'm working on, and it has 6 rooms so far :P [[User:ThebigMuh|ThebigMuh]] 03:26, 10 February 2010 (UTC)

== Lighting Bugs ==
OK, lighting is borked for creating new levels. Lets get some conversation going that doesn't get buried under endless posts about making characters bi and taking their clothes off :p I'll start by listing the bugs we have found so far.

# The lightmap 'cracks' along chunk boundaries in terrain levels, producing unexplained shadows.
# Sunlight doesn't work in terrain levels. An ambient light must be added
# Water is broken in game. Looks fine in editor, but non-existent in game.

Reproduction Steps: All steps assume starting with a clean terrain level built with these options:

[[File:ExtLevelOptions.png|thumb|none]]

=== Base Steps ===

And all have the following basic steps:

# Save the level
# Add export area
# Define area - set the green square to cover the entire mesh
# Add a start point roughly in the center - Possible bug? If I add the start point before the area, path finding will not recognize it.
# Set start point in export area
# Click Render Lightmaps
# Toggle Lightmap on and Fully Lit off to verify there is no light. This confirms bug 2, no sunlight. Unless I've missed where it says sunlight doesn't act like, well, sunlight.
# Add a light roughly in center. Change type to Ambient, Postion.Z to 25
# Toggle Lightmap off
# Hit the Render Lightmap button
# Toggle Lightmap back on to verify ambient is working. I have never seen lightmap cracking at this point.

Phew. And I don't really want to admit how many times I've gone through this.

=== Lightmap Cracking ===
This one is beating me. I cannot come up with a 100% sure-fire way to force cracking. This time it happened when I did a full local post for the second time. If someone can come up with repro steps, it would be much appreciated. Here's a screen shot of the cracked level. Edit: Messing around and noticed that the cracking happened again on the second Do All Local Posts. However it's 1am so further testing will have to wait.

Edit from [[User:Languard|Languard]]:Dug a hole and placed three baked point lights to light it up. After rendering lightmaps and before posting, the lightmaps cracked. Tried to reproduce but on the second time instead of cracking, one chunk became fully lit and completely unaffected by baked point lights.

Edit from [[User:Ainiana|Ainiana]]:In my experience the 'cracked' light map appears to occur when multiple baked lights are applied to the same exterior area. I have also have experienced the 'one chunk unaffected by baked point lights' on another occasion (this only took 1 baked light to reproduce). On all occasions water was not visible in game when testing (using the steps outlined below).

An example of a 'cracked' lightmap.
[[File:lightmapCrack.png|thumb|none]]

:We've seen this internally as well, there appears to be a bug with how sunlight is handled. Our lightmapper guru has had the bug passed on to him so hopefully a fix will come along soon but at this point we don't know exactly what's wrong so we can't give any sort of estimate. [[User:BryanDerksen|BryanDerksen]] 17:49, 16 November 2009 (UTC)

Lightmapping guru here: If anyone sees this happening, please send me the level via our support email. I have played around with sunlight with the lightmapper on my own machine and can not repro it here, so I need your help.

Update 11/24/09: Bug squashed! Head on over to http://social.bioware.com/social.bioware.com/project/717/ to get the new files (you will need the new eclipseray.exe binary)

=== No Water ===
# Use the deform tool to dig a hole
# Right-Click->Insert->New Water Mesh
# Drag it over to the hole
# Make it large enough to cover the hole
# Right-Click->Insert->New Light Probe
# Drag light probe so that is roughly centered on the water and slightly above it
# Place some small oaks around for reflection
# Render Lightmaps
# Render Light Probes
# Verify that yes, it looks correct [[File:levelWater.png|thumb|none]]
# Do All Local Posts
# Save and close level
# Create new area, set level as layout
# Add a waypoint
# Override Export starting area
# Get into game, verify that water is...missing
[[File:ingameNoWater.png|thumb|none]]

Please, if anyone else has anything to add to this, do so. The more info we can concentrate here, the easier it will be for BioWare to fix this :)

:The missing water planes actually doesn't have anything to do with the light mapper, it's a separate system. We've got someone looking at that to see what's going on. [[User:BryanDerksen|BryanDerksen]] 23:51, 24 November 2009 (UTC)

:Found a workaround: [[Level editor#Water tools]] [[User:BryanDerksen|BryanDerksen]] 23:37, 25 November 2009 (UTC)

=== Lightmapper Glitch ===

This glitch appears to be something to do with the configuration of the lightmapper or the script itself.

[[File:Chantry2.JPG|thumb|none]]

It was tested on a BioWare computer in an attempt to figure it out and appeared to work fine there. It may be packaged incorrectly, or there may of been a fault with the installation.

Compiling lightmaps appears to work before a certain amount of props have been added, after which this bug begins to appear. At first, I installed Python 2.6, after which I uninstalled that and installed 2.5. Could this of caused any problems?

~ Shadow180

== New lightmapper ==

We've got a new lightmapper going up at the [http://social.bioware.com/project/717/ lightmapper project] shortly that should hopefully fix a lot of the issues that have been reported above. Check it out and see if it solves things for you. (It won't solve the missing water plane issue, that's something separate that we're still investigating). [[User:BryanDerksen|BryanDerksen]] 23:51, 24 November 2009 (UTC)

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

2010-01-25T18:18:26Z

ThebigMuh:

*'''Version found:''' 1.0.1008.0
*'''Status:''' Open

{{EV|213544|[[User:BryanDerksen|BryanDerksen]]}}

== Description ==

=== Synopsis ===

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.

=== Details ===

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.

=== Example: ===

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:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 141
| Knight Champion Armor
| rob
| arc
| h
|
| 2
| 13
|}

will work, while:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 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:

{| class="wikitable" border="1"
|-
! 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
|-
| 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:

[http://social.bioware.com/forum/1/topic/72/index/508080/1 SOLVED Assigning VFX to a creature]

[http://social.bioware.com/forum/1/topic/74/index/498205/1 Did toolset update break m2da process? (was placeables showing up in area editor but not game)]

== Reproduction ==

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:
{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMaterial
|-
| 20
| Massive Armor X
| arm
| max
| a
|
| 2
| 13
|}
(I used GDApp for this, [http://social.bioware.com/project/755/] )
* 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.

Now:

* 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.

== Workarounds ==
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.

== UPDATE ==

Seems like Eshme found the reason, at least for items affected by this [http://social.bioware.com/forum/1/topic/72/index/722622/1]:

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.

[[Category:Toolset bugs]]
[[Category:2DAs]]

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

2010-01-25T18:17:35Z

ThebigMuh:

*'''Version found:''' 1.0.1008.0
*'''Status:''' Open

{{EV|213544|[[User:BryanDerksen|BryanDerksen]]}}

== Description ==

=== Synopsis ===

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.

=== Details ===

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.

=== Example: ===

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:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 141
| Knight Champion Armor
| rob
| arc
| h
|
| 2
| 13
|}

will work, while:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 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:

{| class="wikitable" border="1"
|-
! 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
|-
| 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:

[http://social.bioware.com/forum/1/topic/72/index/508080/1 SOLVED Assigning VFX to a creature]

[http://social.bioware.com/forum/1/topic/74/index/498205/1 Did toolset update break m2da process? (was placeables showing up in area editor but not game)]

== Reproduction ==

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:
{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMaterial
|-
| 20
| Massive Armor X
| arm
| max
| a
|
| 2
| 13
|}
(I used GDApp for this, [http://social.bioware.com/project/755/] )
* 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.

Now:

* 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.

== Workarounds ==
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.

== UPDATE ==

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

[[http://social.bioware.com/forum/1/topic/72/index/722622/1]]

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.

[[Category:Toolset bugs]]
[[Category:2DAs]]

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

2010-01-25T18:17:10Z

ThebigMuh:

*'''Version found:''' 1.0.1008.0
*'''Status:''' Open

{{EV|213544|[[User:BryanDerksen|BryanDerksen]]}}

== Description ==

=== Synopsis ===

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.

=== Details ===

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.

=== Example: ===

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:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 141
| Knight Champion Armor
| rob
| arc
| h
|
| 2
| 13
|}

will work, while:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 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:

{| class="wikitable" border="1"
|-
! 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
|-
| 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:

[http://social.bioware.com/forum/1/topic/72/index/508080/1 SOLVED Assigning VFX to a creature]

[http://social.bioware.com/forum/1/topic/74/index/498205/1 Did toolset update break m2da process? (was placeables showing up in area editor but not game)]

== Reproduction ==

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:
{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMaterial
|-
| 20
| Massive Armor X
| arm
| max
| a
|
| 2
| 13
|}
(I used GDApp for this, [http://social.bioware.com/project/755/] )
* 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.

Now:

* 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.

== Workarounds ==
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.

== UPDATE ==

Seems like Eshme found the reason, at least for items affected by this:
[[http://social.bioware.com/forum/1/topic/72/index/722622/1]]
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.

[[Category:Toolset bugs]]
[[Category:2DAs]]

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

2010-01-25T14:15:10Z

ThebigMuh:

Feature Request: Normals for Lightmapping

2010-01-23T06:56:48Z

ThebigMuh:

== Synopsis ==
Please modify the lightmapping script and/or associated binaries to get normals correctly to the lightmapper.

== Description ==
As taken from LightMapper.py:
<dascript>
# TODO: Normals are not currently getting to Yafray. Lightmaps would look much better with them, though
</dascript>
There's not a whole lot to add to that, really. Especially caves and similar environments with lots of round shapes suffer horribly from being flat shaded. Getting the normals into Yafray would mean a huge leap in lighting quality - getting a cave level to look similar to the levels that ship with the game is almost impossible right now, since the flat shading means "sharp corners everywhere!".

[[Category:Feature requests]]

Feature Request: Normals for Lightmapping

2010-01-23T04:18:45Z

ThebigMuh: Created page with '== Synopsis == Please modify the lightmapping script and/or associated binaries to get normals correctly to the lightmapper. == Description == As taken from LightMapper.py: <das...'

== Synopsis ==
Please modify the lightmapping script and/or associated binaries to get normals correctly to the lightmapper.

== Description ==
As taken from LightMapper.py:
<dascript>
# TODO: Normals are not currently getting to Yafray. Lightmaps would look much better with them, though
</dascript>
There's not a whole lot to add to that, really. Especially caves and similar environments with lots of round shapes suffer horribly from being flat shaded. Getting the normals into Yafray would mean a huge leap in lighting quality - getting a cave level to look similar to the levels that ship with the game is almost impossible, since the flat shading means "sharp corners everywhere!".

[[Category:Feature requests]]

Item set

2010-01-19T00:30:05Z

ThebigMuh:

An item set is a collection of one or more items that bestow additional bonuses if all are equipped at the same time. The item set system is implemented through scripts and 2da tables, and is very flexible.

Examples of item sets include:

* All armor sets (Leather, Chain Mail, Heavy Plate, ...)
* Imperium Rings (two rings)
* Juggernaut (full body armor with helmet)

and many more.

The set bonus of an item set is not explicitly shown on the items themselves, but rather has to be included in the individual item's description.

=== item_sets.gda ===
----

All sets the game recognizes are defined in [[GDA|item_sets.gda]]. The table has the following structure:

{{2da start|item_sets}}
{{2da column| Label | string | Label for the set, never seen in game }}
{{2da column| namestrref | int | Appears to have been a string reference at some point, but only contains a copy of the Slots column at the moment. Not used. }}
{{2da column| Slots | int | A bit mask identifying which slots are occupied by the items in the set. See below for description. }}
{{2da column| Prop1 | int | The ID of the first set bonus property. "Increases Strength", "Increases Armor", etc..., see below for valid values. }}
{{2da column| Prop1Value | float | Value for the first set bonus property. +5 Strength, or -12.5% fatigue, etc...}}
{{2da column| Prop2 | int | Second set bonus property. }}
{{2da column| Prop2Value | float | Magnitude of the second set bonus. }}
{{2da end}}

The data in item_sets.gda is referenced by sys_itemsets_h to check for equipped sets and apply the corresponding bonuses.

==== Slots ====

The '''Slots field''' contains a bit field that specifies which equipment slots are occupied by the set. These are the individual slot IDs:

{| class="wikitable" border="1"
|-
! Slot !! ID
|-
| Main Hand || 1
|-
| Off Hand || 2
|-
| Chest || 4
|-
| Head || 8
|-
| Gloves || 16
|-
| Boots || 32
|-
| Belt || 64
|-
| Ring 1 || 128
|-
| Ring 2 || 256
|-
| Neck || 512
|-
| Ammo || 1024
|-
| Dog Collar || 2048
|-
| Dog Paint || 4096
|}

To get the value you have to enter into your own set's '''Slots''' field in item_sets.gda, simply add the individual slot IDs together. For example:

Neck + Ring1 + Ring2 = 512 + 128 + 256 = 896

Chest + Helmet + Gloves + Boots = 4 + 8 + 16 + 32 = 60

==== Set Properties ====

Each item set can have up to two separate set bonuses. The type of bonus is determined by the '''Prop1''' and '''Prop2''' fields in the item_sets row. If the corresponding value field ('''Prop1Value''' for '''Prop1''', '''Prop2Value''' for '''Prop2''') is NOT 0.0, then a property modifier will be constructed from the '''PropX''' entry. These directly correspond to the [[Creature Properties]]. Here are a few examples:

{| class="wikitable" border="1"
|-
! Prop1 !! Prop1Value !! Description
|-
| 1 || 5.0 || Increases Strength by 5
|-
| 41 || -15.0 || Reduces Fatigue by 15%
|-
| 22 || 7.5 || Increases chance to avoid missiles by 7.5%
|}

If the value field to a '''PropX''' field is 0.0, an effect from [[effects.xls]] will be applied. The only instance of this in the default game is the Griffon set, which uses a '''Prop1''' value of 1050, which corresponds to EFFECT_TYPE_FLANK_IMMUNITY. In theory you could make item sets that petrify their wearer, give them transparency or a permanent mana shield.

=== Item Properties ===
----

In addition to defining the properties of the set as mentioned above, each individual item in a set also has to be flagged as belonging to that set. This is done by entering the set's ID into the ITEM_SET field on each item's [[Item#Variables|variables]] list.

=== Example Set ===
----

Here is an example entry from item_sets.gda for a custom set. '''Please do not reuse the ID!'''

{| class="wikitable" border="1"
|-
! ID !! Label !! namestrref !! Slots !! Prop1 !! Prop1Value !! Prop2 !! Prop2Value
|-
| 10121480 || Knight Champion's Aegis || 60 || 60 || 3 || 5 || 41 || -20
|}

This set uses all four armor slots (head, chest, gloves and boots). It has two set bonuses, increasing Willpower by 5 and reducing Fatigue by 20% while wearing it. The four armor items would also have to get the value 10121480 inserted into their ITEM_SET variable field.

[[Category: Items]]

Item set

2010-01-19T00:27:40Z

ThebigMuh: Created page with 'An item set is a collection of one or more items that bestow additional bonuses if all are equipped at the same time. The item set system is implemented through scripts and 2da t...'

An item set is a collection of one or more items that bestow additional bonuses if all are equipped at the same time. The item set system is implemented through scripts and 2da tables, and is very flexible.

Examples of item sets include:

* All armor sets (Leather, Chain Mail, Heavy Plate, ...)
* Imperium Rings (two rings)
* Juggernaut (full body armor with helmet)

and many more.

The set bonus of an item set is not explicitly shown on the items themselves, but rather has to be included in the individual item's description.

=== item_sets.gda ===

All sets the game recognizes are defined in [[GDA|item_sets.gda]]. The table has the following structure:

{{2da start|item_sets}}
{{2da column| Label | string | Label for the set, never seen in game }}
{{2da column| namestrref | int | Appears to have been a string reference at some point, but only contains a copy of the Slots column at the moment. Not used. }}
{{2da column| Slots | int | A bit mask identifying which slots are occupied by the items in the set. See below for description. }}
{{2da column| Prop1 | int | The ID of the first set bonus property. "Increases Strength", "Increases Armor", etc..., see below for valid values. }}
{{2da column| Prop1Value | float | Value for the first set bonus property. +5 Strength, or -12.5% fatigue, etc...}}
{{2da column| Prop2 | int | Second set bonus property. }}
{{2da column| Prop2Value | float | Magnitude of the second set bonus. }}
{{2da end}}

The data in item_sets.gda is referenced by sys_itemsets_h to check for equipped sets and apply the corresponding bonuses.

==== Slots ====

The '''Slots field''' contains a bit field that specifies which equipment slots are occupied by the set. These are the individual slot IDs:

{| class="wikitable" border="1"
|-
! Slot !! ID
|-
| Main Hand || 1
|-
| Off Hand || 2
|-
| Chest || 4
|-
| Head || 8
|-
| Gloves || 16
|-
| Boots || 32
|-
| Belt || 64
|-
| Ring 1 || 128
|-
| Ring 2 || 256
|-
| Neck || 512
|-
| Ammo || 1024
|-
| Dog Collar || 2048
|-
| Dog Paint || 4096
|}

To get the value you have to enter into your own set's '''Slots''' field in item_sets.gda, simply add the individual slot IDs together. For example:

Neck + Ring1 + Ring2 = 512 + 128 + 256 = 896

Chest + Helmet + Gloves + Boots = 4 + 8 + 16 + 32 = 60

==== Set Properties ====

Each item set can have up to two separate set bonuses. The type of bonus is determined by the '''Prop1''' and '''Prop2''' fields in the item_sets row. If the corresponding value field ('''Prop1Value''' for '''Prop1''', '''Prop2Value''' for '''Prop2''') is NOT 0.0, then a property modifier will be constructed from the '''PropX''' entry. These directly correspond to the [[Creature Properties]]. Here are a few examples:

{| class="wikitable" border="1"
|-
! Prop1 !! Prop1Value !! Description
|-
| 1 || 5.0 || Increases Strength by 5
|-
| 41 || -15.0 || Reduces Fatigue by 15%
|-
| 22 || 7.5 || Increases chance to avoid missiles by 7.5%
|}

If the value field to a '''PropX''' field is 0.0, an effect from [[effects.xls]] will be applied. The only instance of this in the default game is the Griffon set, which uses a '''Prop1''' value of 1050, which corresponds to EFFECT_TYPE_FLANK_IMMUNITY. In theory you could make item sets that petrify their wearer, give them transparency or a permanent mana shield.

=== Item Properties ===

In addition to defining the properties of the set as mentioned above, each individual item in a set also has to be flagged as belonging to that set. This is done by entering the set's ID into the ITEM_SET field on each item's [[Item#Variables|variables]] list.

=== Example Set ===

Here is an example entry from item_sets.gda for a custom set. '''Please do not reuse the ID!'''

{| class="wikitable" border="1"
|-
! ID !! Label !! namestrref !! Slots !! Prop1 !! Prop1Value !! Prop2 !! Prop2Value
|-
| 10121480 || Knight Champion's Aegis || 60 || 60 || 3 || 5 || 41 || -20
|}

This set uses all four armor slots (head, chest, gloves and boots). It has two set bonuses, increasing Willpower by 5 and reducing Fatigue by 20% while wearing it. The four armor items would also have to get the value 10121480 inserted into their ITEM_SET variable field.

[[Category: Items]]

Feature Request: Keeping Ambient Occlusion step separate

2010-01-17T19:55:20Z

ThebigMuh: Created page with '== Synopsis == The suggestion is to keep the ambient occlusion maps separate from the other lightmapping maps, and only merge them together once a Post is being done. Since ambi...'

== Synopsis ==

The suggestion is to keep the ambient occlusion maps separate from the other lightmapping maps, and only merge them together once a Post is being done. Since ambient occlusion only depends on level geometry, but not on the lighting, that would greatly speed up relighting a level.

== Description ==

Currently, the lightmapper creates one "layer" of light maps, with everything baked into it. If you move one light and want to update the lighting info, you have to recalculate lightmapping + shadow maps + ambient occlusion.

Ambient occlusion doesn't depent on the lights in the level, however, only the geometry influences the result, so recalculating AO is superfluous if only lighting changes.

A lot of time could be saved, if ambient occlusion maps were only regenerated when models are moved around, but not if only lights get changed (either position or settings). The lightmapper could cache the separate ambient occlusion maps and only merge them with the other lightmapping results when a Post is being done.

Generation of the AO maps / light maps could either be tracked automagically (with dirty flags on geometry and lights), or manually, by adding "Render AO", "Render Lightmaps" and "Render AO + Lightmaps" buttons.

[[Category:Feature requests]]

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

2010-01-16T00:30:23Z

ThebigMuh: wiki editing noob :P

*'''Version found:''' 1.0.1008.0
*'''Status:''' Open

{{EV|213544|[[User:BryanDerksen|BryanDerksen]]}}

== Description ==

=== Synopsis ===

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.

=== Details ===

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.

=== Example: ===

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:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 141
| Knight Champion Armor
| rob
| arc
| h
|
| 2
| 13
|}

will work, while:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 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:

{| class="wikitable" border="1"
|-
! 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
|-
| 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:

[http://social.bioware.com/forum/1/topic/72/index/508080/1 SOLVED Assigning VFX to a creature]

[http://social.bioware.com/forum/1/topic/74/index/498205/1 Did toolset update break m2da process? (was placeables showing up in area editor but not game)]

== Reproduction ==

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:
{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMaterial
|-
| 20
| Massive Armor X
| arm
| max
| a
|
| 2
| 13
|}
(I used GDApp for this, [http://social.bioware.com/project/755/] )
* 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.

Now:

* 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.

== Workarounds ==
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.

[[Category:Toolset bugs]]

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

2010-01-16T00:28:57Z

ThebigMuh: Added reproduction steps

*'''Version found:''' 1.0.1008.0
*'''Status:''' Open

{{EV|213544|[[User:BryanDerksen|BryanDerksen]]}}

== Description ==

=== Synopsis ===

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.

=== Details ===

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.

=== Example: ===

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:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 141
| Knight Champion Armor
| rob
| arc
| h
|
| 2
| 13
|}

will work, while:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 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:

{| class="wikitable" border="1"
|-
! 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
|-
| 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:

[http://social.bioware.com/forum/1/topic/72/index/508080/1 SOLVED Assigning VFX to a creature]

[http://social.bioware.com/forum/1/topic/74/index/498205/1 Did toolset update break m2da process? (was placeables showing up in area editor but not game)]

== Reproduction ==

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:
{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMaterial
|-
| 20
| Massive Armor X
| arm
| max
| a
|
| 2
| 13
|}
(I used GDApp for this, [http://social.bioware.com/project/755/] )
# 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.

Now:

# 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.

== Workarounds ==
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.

[[Category:Toolset bugs]]

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

2010-01-15T23:21:03Z

ThebigMuh: more detailed version number

*'''Version found:''' 1.0.1008.0
*'''Status:''' Open

== Description ==

=== Synopsis ===

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.

=== Details ===

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.

=== Example: ===

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:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 141
| Knight Champion Armor
| rob
| arc
| h
|
| 2
| 13
|}

will work, while:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 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:

{| class="wikitable" border="1"
|-
! 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
|-
| 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:

[http://social.bioware.com/forum/1/topic/72/index/508080/1 SOLVED Assigning VFX to a creature]

[http://social.bioware.com/forum/1/topic/74/index/498205/1 Did toolset update break m2da process? (was placeables showing up in area editor but not game)]

== Workarounds ==
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.

[[Category:Toolset bugs]]

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

2010-01-15T23:10:29Z

ThebigMuh:

*'''Version found:''' 1.01
*'''Status:''' Open

== Description ==

=== Synopsis ===

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.

=== Details ===

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.

=== Example: ===

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:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 141
| Knight Champion Armor
| rob
| arc
| h
|
| 2
| 13
|}

will work, while:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 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:

{| class="wikitable" border="1"
|-
! 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
|-
| 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:

[http://social.bioware.com/forum/1/topic/72/index/508080/1 SOLVED Assigning VFX to a creature]

[http://social.bioware.com/forum/1/topic/74/index/498205/1 Did toolset update break m2da process? (was placeables showing up in area editor but not game)]

== Workarounds ==
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.

[[Category:Toolset bugs]]

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

2010-01-15T23:10:10Z

ThebigMuh:

*'''Version found:''' 1.01
*'''Status:''' Open

== Description ==

=== Synopsis ===

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.

=== Details ===

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.

=== Example: ===

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:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 141
| Knight Champion Armor
| rob
| arc
| h
|
| 2
| 13
|}

will work, while:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 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:

{| class="wikitable" border="1"
|-
! 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
|-
| 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:

[http://social.bioware.com/forum/1/topic/72/index/508080/1 SOLVED Assigning VFX to a creature]
[http://social.bioware.com/forum/1/topic/74/index/498205/1 Did toolset update break m2da process? (was placeables showing up in area editor but not game)]

== Workarounds ==
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.

[[Category:Toolset bugs]]

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

2010-01-15T23:04:25Z

ThebigMuh: Fixed small error in the example tables ~~~~

*'''Version found:''' 1.01
*'''Status:''' Open

== Description ==

=== Synopsis ===

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.

=== Details ===

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.

=== Example: ===

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:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 141
| Knight Champion Armor
| rob
| arc
| h
|
| 2
| 13
|}

will work, while:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELSUBTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 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:

{| class="wikitable" border="1"
|-
! 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
|-
| materialrules.gda
| Y
| 80141200
|-
| materialtypes.gda
| Y
| 80141200
|-
| screenshake.gda
| Y
| 80141200
|-
| ts_material.gda
| Y
| 80141200
|}

== Workarounds ==
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.

[[Category:Toolset bugs]]

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

2010-01-15T23:02:36Z

ThebigMuh: Created page with '*'''Version found:''' 1.01 *'''Status:''' Open == Description == === Synopsis === High values for the ID field in various M2DA tables will appear to work correctly while test...'

*'''Version found:''' 1.01
*'''Status:''' Open

== Description ==

=== Synopsis ===

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.

=== Details ===

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.

=== Example: ===

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:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 141
| Knight Champion Armor
| rob
| arc
| h
|
| 2
| 13
|}

will work, while:

{| class="wikitable" border="1"
|-
! ID
! Label
! MODELTYPE
! MODELVARIATION
! ICONNAME
! DefaultMaterial
! SoundMatType
|-
| 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:

{| class="wikitable" border="1"
|-
! 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
|-
| materialrules.gda
| Y
| 80141200
|-
| materialtypes.gda
| Y
| 80141200
|-
| screenshake.gda
| Y
| 80141200
|-
| ts_material.gda
| Y
| 80141200
|}

== Workarounds ==
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.

[[Category:Toolset bugs]]