Bug #31902

patch 2.x RNDTRES.2DA bugs/limitations

Added by swit swit almost 2 years ago. Updated 12 months ago.

Status:NewStart date:08/11/2017
Classification:Public ItemDue date:
Assignee:-% Done:


Target version:-
Found In Version:Public Bug Reports -


Different rows referencing (using dummy item resref to spawn items from another row) within RNDTRES.2DA doesn't work as expected.
1. Copy RNDTRE01.ITM into 2 new items called "RNDTEST1.ITM" and "RNDTEST2.ITM"
2. Add following rows to RNDTRES.2DA:


3. Start new BG:EE game with any character
4. Open clua console
5. C:CreateItem("RNDTEST1")
6. C:CreateItem("RNDTEST2")
7. Check your inventory

Referencing another row (step 5 in above repro steps) should spawn AMUL01. Currently only direct item reference works (step 6). Referencing another row results in dummy item being added to your inventory instead of being replaced using RNDTRES.2DA data.

Executing repro step 5 creates an invisible pseudo-item that can be moved around within the inventory, but not much else. If you drop it to the ground and pick it up again, it will become the intended regular but identified item.

I'm reporting it as a bug since another row referencing is actually possible with RNDTRES.2DA but has limitations:
1. Adding RNDTEST1 to ARE container via weidu (modifying ARE file during mod installation) results in the above mentioned problem (CreateItem console command was used in repo steps to make it easier to test, but the result is the same if you modify ARE containers)
2. Adding RNDTEST1 to CRE inventory via script (e.g. C:Eval'ActionOverride(Player1,CreateItem("RNDTEST1",0,0,0))') also results in the above mentioned problem.
3. Adding RNDTEST1 to CRE inventory via weidu (modifying CRE file during mod installation) works but the AMUL01 item spawned will be already identified.
4. Adding RNDTEST1 to ARE container via script (e.g. C:Eval'ActionOverride("Container 4",CreateItem("RNDTEST1",0,0,0))') works but as above spawned item will be already identified.

In other words it looks like there was an intention to make it work, but the implementation has not been finished/is buggy.


#1 Updated by Richard Hilton over 1 year ago

I think this works as below...
bear with me, taken a while to fiddle and need to recheck tomorrow / later today :(

  • Set the category to something that can be identifiable. e.g. necklaces, or belts and girdles
  • Set the lore to identify to a value other than 0. e.g. 1

n.b. I then tested with C:Eval('GiveItemCreate(...

Creating AMUL01 with category belt and lore 1 produced an unidentified amulet that resisted lore of 14 but was identifiable by a bard with 127 lore - I haven't dug around to check exact figures but that seems a reasonable test that the category and lore of RNDTEST2 may be ignored.

I suspect you'd need RNDTEST2 to have all items that are unidentified and if you want identified items then RNDTEST3 could be used for that purpose, and so on.

#2 Updated by Richard Hilton over 1 year ago

In BG:EE the item does not turn visible for me if dropped. It does in IWD:EE. Also, BG:EE doesn't have rndtres.2da. Could you confirm the same please to make sure we have consistent results.

The method I mentioned above looks to work for IWD:EE but not BG:EE. Was this working in 1.3 BG:EE (v2 of BG:EE will have picked up engine changes from v1.4 of IWD:EE which may be why there is a partial, and perhaps unintended, implementation).


#3 Updated by Richard Hilton over 1 year ago

  • Status changed from New to Needs More Info

#4 Updated by swit swit over 1 year ago

According to Avenger (I assume he is responsible for implementing this feature in EE engine) the bug is caused by lack of recursion which isn't done because it could create infinite loops. GemRB does have a loop limit to solve it. Here is the direct quote: http://gibberlings3.net/forums/index.php?showtopic=27199#entry255959
It may be a good idea to consult the problem with him since he probably already knows how to handle it to work as intended.

It will be easier to test it in BG2:EE (latest 2.5.10 beta patch) since it already has rndtres.2da but I can confirm the same problem also in BG:EE. In IWD:EE it probably works differently since that engine has modified code for random spawning (from what I remember it uses RNDTREAS.2DA in place of RNDTRES.2DA and in IWD:EE the vanilla engine 2DA item spawning method doesn’t have 10 rows limit - another thing that would be usefull for BG:EE and BG2:EE although not crucial considering there is RNDTRES.2DA available)

For following test I've done what you mentioned (assigned RNDTEST1.ITM and RNDTEST2.ITM "Amulet" cattegory and Lore to identify = 1). It fixes following problems:
- Adding RNDTEST1 to CRE inventory via weidu (modifying CRE file during mod installation)
- Adding RNDTEST1 to ARE container via C:Eval('ActionOverride("Jailkeep Table",CreateItem("RNDTEST1",1,0,0))')

Attached video showcases remaining problems:
- Adding RNDTEST1 to ARE container via weidu (modifying ARE file during mod installation) or providing pre-made ARE file creates dummy item that needs to be moved into "inventory" and then into "ground item slot" in order to be correctly replaced with intended item. This is the most problematic thing considering this feature is most useful for adding random stuff into ARE containers on pre-made files or via dynamic weidu patching. As you can see in the video this problem is solved after reloading the game, but it shows up the first time the area is loaded.
- Adding RNDTEST1 to CRE inventory via C:Eval('ActionOverride(Player1,CreateItem("RNDTEST1",1,0,0))') creates dummy item that needs to be moved into "ground item slot" in order to be correctly replaced with intended item.
- Adding RNDTEST1 to CRE inventory via C:Eval('GiveItemCreate("RNDTEST1",Player1,1,0,0)') replaces the item correctly but in this case the command shows string "The Party Has Gained An Item: Invalid: 9999999" (a name of the RNDTEST item instead of intended one) so ActionOverride(Player1,CreateItem(... is preferable method for adding random items into inventory via script unless this is fixed

As mentioned probably all the problems will be fixed once the recursion is implemented since Avenger was also the guy who implemented this feature in GemRB and it work correctly in that engine.

btw. if this problem will be fixed please also take a look at this feature request which is another thing that works in GemRB but not in BG2:EE https://support.baldursgate.com/issues/31903

#5 Updated by swit swit over 1 year ago

For some reason the video has not been attached to the previous post. If it's not visible for you please download mp4 file that showcases remaining problems from my dropbox: https://www.dropbox.com/s/00abpt5x2088iva/Baldur%27s%20Gate%20II%20-%20Enhanced%20Edition%20-%20v2.5.10.0%2008.12.2017%2001_03_26.mp4?dl=1

#6 Updated by swit swit 12 months ago

  • Found In Version changed from to

The bug described in the opening report still exists in latest BG2:EE patch. The ticket is still marked as "Needs More Info". If that's the case please let me know what info should be provided.

#7 Updated by Anders Svensson 12 months ago

  • Status changed from Needs More Info to New

Also available in: Atom PDF