Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
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
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
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
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
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
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
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
Is this still an issue?
Original comment by YeOldeSt...@gmail.com
on 21 Dec 2010 at 11:44
Original issue reported on code.google.com by
iamthesp...@gmail.com
on 10 Dec 2010 at 11:41