29 replies to this topic

[agb1]

Are you sure you gave yourself MISC83.ITM?

[Roxanne]

Hey Gang,

 

[SPOILERS AHEAD]

 

I hadn't planned on making a second post so soon, but I'm at the Cloakwood Mine section of the game and I've been encountering some serious issues. Firstly, after killing Davaeorn his body did not have the key. I searched online and apparently this is a relatively common problem. No big deal, CLUA myself a key and we're good.

 

Except we're not...

 

I went back to the first level of the mine to talk to the slave right by the river plug, and he's stuck on his dialogue. I spoke to him earlier and he told me to to get the key. I get the key and go back to him and the only thing he says is "You shouldn't talk to me so much. The guards are going to get suspicious" over and over again. I'm stuck, and I can't flood the mine!

 

Anyone run into this before, and is there a solution?

 

Again, thanks everyone and any help is greatly appreciated!

Did you free the slaves on the level where you find Yeslick? (Rill is the name, I think)

[agb1]

If you are using BGT, try CLUAConsole:CreateItem("BGMISC83") instead.

[agb1]

Here's what I did:  I used Near Infinity to search first for Davaeorn.  I didn't remember the exact filename, but NI auto-suggests as you type in the search box, so when I typed in DAV it completed it to DAVAEO.CRE.  Then I looked at the inventory, and saw BGMISC83.ITM.  Then I double-clicked that item and clicked 'Edit' and then 'Find...' and 'references to this file'.  I chose to search only DLG (dialogue) files.  This led me to MINEC2.DLG (the dialogue for the miner near the river plug).  I looked at the 'Tree' view of the dialogue and the "state trigger" for the desired branch of the dialogue contains just one condition:  PartyHasItem("BGMISC83.ITM") ... so I knew that all you needed was this item.

 

Also, you can infer from this that BGT renames MISC83.ITM to BGMISC83.ITM.  The solutions you found elsewhere were correct for BGEE or vanilla BG1, but not for BGT.

Edited by agb1, 22 January 2016 - 10:25 AM.

[The Imp]

agb1, you work way too hard to upkeep these mods. No, don't stop... thank.
I suspect it would have been easier to find the item by searching the item with NI, with Search -> CRE/ITM/SPL/STO -> Items -> plug ...

[agb1]

I also wanted to see if it was missing from Davaeon's inventory.  It's there in my game, so I'm curious which mod removed it from Nobody's.

[Nobody83]

Hey Agb, do you remember that cool trick that you taught me that lets me check what mods are changing files? Well I used it on this one and found some interesting results. The log is attached if you're interested.

 

The last mod on the list was lolfixer, which specifically says it's messing around with the inventory, so that was the first thing I checked. Lolfixer backup revealed that Dav's river plug was already missing by the time we got there. Next on the list was aurora, which apparently is only supposed to change the amount of gold that NPC's carry, but in the Aurora backups I found a Davaeo.cre that had a river plug.

 

So Aurora is doing something to his river plug.

 

The one thing that I don't get, however, is that there's two dav files in the Aurora backups. One is at ..\aurora\backup\470 and the other is at ..\aurora\backup\0.

 

The one at 470 is already missing his river plug, but the one at 0 has it intact. I'm not sure why there are two backups, but looking at the log there are two Aurora installations. One is number 4 on the list, and the other is at number 10.

 

Not quite sure what to make of it, but that should be enough information for you to put together an idea. Seeing how you're all smart-like and such.

Attached Files

•  davchange.txt   2.01K   170 downloads

Edited by Nobody83, 22 January 2016 - 10:45 PM.

[Roxanne]

Hey Agb, do you remember that cool trick that you taught me that lets me check what mods are changing files? Well I used it on this one and found some interesting results. The log is attached if you're interested.

 

The last mod on the list was lolfixer, which specifically says it's messing around with the inventory, so that was the first thing I checked. Lolfixer backup revealed that Dav's river plug was already missing by the time we got there. Next on the list was aurora, which apparently is only supposed to change the amount of gold that NPC's carry, but in the Aurora backups I found a Davaeo.cre that had a river plug.

 

So Aurora is doing something to his river plug.

 

The one thing that I don't get, however, is that there's two dav files in the Aurora backups. One is at ..\aurora\backup\470 and the other is at ..\aurora\backup\0.

 

The one at 470 is already missing his river plug, but the one at 0 has it intact. I'm not sure why there are two backups, but looking at the log there are two Aurora installations. One is number 4 on the list, and the other is at number 10.

 

Not quite sure what to make of it, but that should be enough information for you to put together an idea. Seeing how you're all smart-like and such.

At a first quick glance this identifies Aurora component 0 as source of the problem and indeed this component according to the tp2 of the mod does something at Cloakwood Level 4 (i.e. the area Davaeorn is in) - however I was not able to figure out what exactly the mod does there - somebody else may want to take a look at that code in the tpa triggered there.

PS it must be something randomly or something in conjunction with other mods - I had aurora in my last 15+ installs and no problem ever with the plug. 

Edited by Roxanne, 22 January 2016 - 11:43 PM.

[agb1]

Nobody83, did you check if the plug is in Davaeon's inventory in the backup copies from SCS and unique containers?

 

The backup folders are modname\backup\component-num ... according to the change log, SCS and unique containers modified the file between Aurora #0 and Aurora #470.  After looking at the code, I suspect the problem is not in Aurora itself.

[Nobody83]

You're absolutely right. I guess it never occurred to me that the half-a-dozen mods in between aurora 0 and aurora 470 could be responsible.

 

I checked out containers, and he was missing his plug by then, so then I went back to stratagems. The backups weren't in ...\stratagems, but rather they were in ...\strategems-external\backups. I'm assuming that "strategems-external" isn't a separate component in and of itself because it doesn't have a corresponding setup file. Stratagems has 4 Davaeorn backups, and every single one of them has the river plug, and since the next mod after it (containers) is missing the plug, that means that stratagems has to be doing something.

 

The four backups are at /1901, /6000, /6032, and 6101. Assuming that the components install in order (is that a bad assumption?) then is it component 6101 that's doing it?

[agb1]

The order of the lines in the change-log is the order that they were installed.  In this case yes, 6101 seems to be the suspect now.

[Nobody83]

So I checked into 6101, which is "Potions for NPC's" (I'm assuming that the files are located in ..\stratagems\potion ) and took a look at the tp2 files. It looks like it's adding "random treasure" (listed as rndtreas in potion_shared.tph) to NPC inventories.

 

Indeed, when I open the davaeo.cre after 6101 installs, he has three random treasures in his inventory. RNDTRE14.ITM, RNDTRE26.ITM, and RNDTRE35.ITM. Considering that, prior to the installation, Davaeorn has 14 of his 16 inventory slots filled and 6101 is attempting to add 1 more item than he can carry, the question then becomes what happens when you call CRE_add_items on a full inventory?

 

I'm thinking the answer is that it overwrites an item, and in this case, the item happened to be the river plug.

 

Does that sound plausible?

[agb1]

http://www.weidu.org...ml#ADD_CRE_ITEM doesn't specify what happens if inventory is full OR if slot is zero.

 

Potions are type 0x0009.  http://gibberlings3....Header_ItemType

 

I think this section of CRE_add_items ...

 

Spoiler

          PATCH_IF ~%slot%~ STRING_EQUAL_CASE ~NONE~ BEGIN

                INNER_ACTION BEGIN

                   ACTION_IF FILE_EXISTS_IN_GAME ~%item%.itm~ BEGIN

                        COPY_EXISTING ~%item%.itm~ ~override~

                                      SPRINT ~ITM_file~ ~%SOURCE_RES%~

                                      TO_LOWER ~ITM_file~

                                      READ_SHORT 0x1c item_type_code

                                      PATCH_IF VARIABLE_IS_SET $item_location_map(~%item_type_code%~) BEGIN

                                               SPRINT ~slot~ $item_location_map(~%item_type_code%~)

                                               TO_UPPER ~slot~

                                      END ELSE BEGIN

                                               SPRINT ~slot~ INV

                                      END

                        BUT_ONLY

 

... would resolve ~slot~ to zero because 9 is not defined in the associative array $item_location_map (see stratagems\sfo\general\lib_macro.tpa).

[Nobody83]

I think this section of CRE_add_items ...

... would resolve ~slot~ to zero because 9 is not defined in the associative array $item_location_map (see stratagems\sfo\general\lib_macro.tpa).

 

The real question is what arguments are being passed to CRE_add_items?

 

From the documentation, it doesn't look like you can call CRE_add_items without arguments, and in potion_shared we find the following:

 

LPF CRE_add_items STR_VAR arguments= ~%item%~ END

So the best bet would be to find out the value of the variable "arguments" at runtime. Is there a way to print to console or something in weidu? That way we can just print the "arguments" variable right before it adds the items and see what the arguments are being set to.

 

That would let us know what is being passed for the slot argument.

Edited by Nobody83, 23 January 2016 - 08:47 PM.

[agb1]

I don't know, so I posted on the weidu forum at PPG asking for help with this.

[Roxanne]

I don't know, so I posted on the weidu forum at PPG asking for help with this.

Sounds like BWS needs a category soon to classify mods that even go beyond current *expert*, where you need a university degree in computer science to play your game if you install them.