Hard patched CB crashes after loading certain .part files.

[GoogleCodeExporter]

What steps will reproduce the problem?
Using a hard patched CB version 1.1.2, trying to use certain .part files will 
cause CB to crash during the loading stage.  CBLoader itself shows no errors 
other than the permanently remaining 'Pipeline is not debugging.  Waiting for a 
debug event will hang.' error.  Removing the .part in question allows the CB to 
work fine again.

The specific file cannot be shared here for copyright reasons, but can be found 
for testing purposes if you know where to look on SA ;) The bug seems to be 
down to the changes involved in attempting to make the Hexblade implements 
work, I believe. Unfortunately, I can't currently provide any more data than 
that - the error message provided by the CB is singularly uninformative, simply 
telling me to contact Customer Help.

This does seem to be directly related to the hard patched CB, though, since the 
relevant .part is functional in a CB used without needing the hard patch.

I hope there is enough here to find a solution.  I'll try to do some more 
in-depth bug-hunting tomorrow.

Original issue reported on code.google.com by iamthesp...@gmail.com on 10 Dec 2010 at 11:41

[GoogleCodeExporter]

To give a little more information, the file in question adds a property called 
"offhand implement bonus" equal to the enhancement bonus to every rod and wand, 
which is referenced by the hexblade to add to weapon attacks.  The file also 
includes a couple of lines on every rod to cause the "rod expertise" feat to 
work correctly (adding shield effects).

Original comment by brown...@gmail.com on 11 Dec 2010 at 1:03

[GoogleCodeExporter]

Could either of you create a non infringing. Part file that reproduces this 
issue so I can use it in testing. Perhaps try reecreating the structure of the 
problem item but changing its properties and flavor.

Original comment by jeff.h...@gmail.com on 11 Dec 2010 at 2:39

[GoogleCodeExporter]

I'll have to leave that to spaceinvader as I am unable to determine if any 
files I create will still have the error.

Original comment by brown...@gmail.com on 11 Dec 2010 at 2:41

[GoogleCodeExporter]

Without infringing, I think I can post what was added to rods and wands in one 
of the two files involved.  If removing the feat name isn't enough, let me know 
and I'll delete this comment.  For rods:
<rules>
<statadd name="Offhand Implement Bonus" value="+1" />
<statadd name="AC" type="Shield" value="+1" requires="Some Feat"/>
<statadd name="Reflex" type="Shield" value="+1" requires="Some Feat"/>
<statadd name="SomeFeat" value="+1" />
<statadd name="SomeFeat" value="+1" requires="Paragon Tier" />
<statadd name="SomeFeat" value="+1" requires="Epic Tier" />
<statadd name="implement:attack" value="+SomeFeat" type="Feat" requires="Some 
Feat"/>
<statadd name="weapon:attack" value="+SomeFeat" type="Feat" 
requires="FancyClass,Some Feat"/>
</rules>

Wands got the Offhand Implement Bonus lines, but not the feat stuff.  Oh, and I 
know the implement attack bonus could have been handled in the feat itself, but 
once I was putting some of its benefits in each rod, I wanted to keep them all 
together.

The main file references these changes as such:

<statadd name="ID_FMP_WEAPON_666666:attack" value="+Offhand Implement Bonus"  />
<statadd name="ID_FMP_WEAPON_666666:damage" value="+Offhand Implement Bonus" />

Of course, it's a 8200 line file, the problem may be somewhere else completely 
unrelated.  The weird thing is that it works fine for some people, but 
apparently not for people in hard patch mode.

Original comment by brown...@gmail.com on 11 Dec 2010 at 3:03

[GoogleCodeExporter]

Yeah - I'm going on a bug hunt today, starting with a single implement and 
working up from there, but hopefully the above might be enough.

Original comment by iamthesp...@gmail.com on 11 Dec 2010 at 8:30

[GoogleCodeExporter]

I've checked - it's definitely NOT the file with changes only to the items that 
causes the problem.  The issue is somewhere within the 8000-odd lines of the 
newly-released book's code.  Going on a bug hunt now...

Original comment by iamthesp...@gmail.com on 11 Dec 2010 at 9:45

[GoogleCodeExporter]

To further update (and sorry for the inbox spam is anyone else has starred this 
topic):

I've isolated the class that is causing the bug.  Which takes me down to 74 
rules elements rather than 471.  I'm going to continue on and see if I can 
narrow it down further.

Original comment by iamthesp...@gmail.com on 11 Dec 2010 at 10:30

[GoogleCodeExporter]

I have it narrowed down to one specific power, with the id 
ID_FMP_POWER_11122213 in the relevant file.  I'm going to see if I can narrow 
it down further.

Original comment by iamthesp...@gmail.com on 11 Dec 2010 at 11:36

[GoogleCodeExporter]

Aaaand I've worked it out.  The issue would seem to be caused by the fact that 
the power in question was identical to an existing power of the same level and 
type from PHB1 - the CB crapped out (only in Hard Patch mode, apparently), at 
having one power with two different ids.  I don't know how this looked in the 
merged file though.  I'll replicate the bug and check.

Original comment by iamthesp...@gmail.com on 11 Dec 2010 at 11:53

[GoogleCodeExporter]

In the merged file, it appears as two separate instances of the power, with 
different IDs, but the same name.  This would appear to be the cause of the 
problem - but I don't know whether it's specific to one of them being a native 
power and one being an added power.  Replicating it shouldn't be too much of an 
issue, but now I know the cause, avoiding it is easy enough.

Original comment by iamthesp...@gmail.com on 11 Dec 2010 at 11:58

[GoogleCodeExporter]

I know that when implementing Arcane Defiling, the existance of an existing 
element with the name "arcane defiling" caused issues with the capitalization 
of the newly implemented power.  This may be a similar problem?

Original comment by YeOldeSt...@gmail.com on 11 Dec 2010 at 12:56

• Changed state: Accepted

[GoogleCodeExporter]

Ok, in further possible exposition,  I believe it may be linked to the way 
Character Builder attempts to handle people getting ahead of the updates.

For Example:
Using the normal method of creating homebrew content (Using the H triangle, 
selecting "Create Custom Element"), create a new element.  Then save your 
character, add an element with the same name to a .part, and reload your 
character.  Character Builder sees that it has an INTERNAL with the same name 
as a POWER, and changes your custom element for the proper one.  Note that if 
you were to delete the part, it would show the original custom element, so it 
is not replacing, but occluding the first element with the second.

I think that this could be the basis of the bug.  I shall continue to 
investigate.

Original comment by YeOldeSt...@gmail.com on 11 Dec 2010 at 10:52

[GoogleCodeExporter]

Is this still an issue?

Original comment by YeOldeSt...@gmail.com on 21 Dec 2010 at 11:44