18 réponses à ce sujet

[Maverick827]

Edit: Since these forums are terrible the code is almost illegible.  Sorry.


With the recent release of Golems of Amgarrak, I felt a two-handed powerhouse would be a nice character to play, but I've read that Shattering Blows does not work.  

I found the following code regarding Shattering Blows:

if (HasAbility(oAttacker, ABILITY_TALENT_SHATTERING_BLOWS))    {        if (IsObjectValid(oDefender))        {            if (GetCreatureAppearanceFlag(oDefender, APR_RULES_FLAG_CONSTRUCT))            {                if ( IsUsingMeleeWeapon(oAttacker, oWeapon) &&  IsMeleeWeapon2Handed(oWeapon))                {                    fBase += (GetAttributeModifier(oAttacker, PROPERTY_ATTRIBUTE_STRENGTH) * 0.5f);                }            }        }    }

The only suspect line is the call to GetCreatureAppearanceFlag(); it would make sense that this would be where the function falters.  GetCreatureAppearanceFlag() is the following:

int GetCreatureAppearanceFlag(object oCreature, int nFlag){    int nVal  = GetM2DAInt(TABLE_APPEARANCE,"AprRulesFlags", GetAppearanceType(oCreature));    return ( (nVal  & nFlag ) == nFlag);}

I am unable to find GetM2DAInt, so I cannot proceed from here.  Does anyone have any ideas?  If the check is broken, then it would have to take place in GetM2DAInt (or yet another function called within) as it sets nVal, which is checked against the passed APR_RULES_FLAG_CONSTRUCT constant, which is set to 0x00000002.

Modifié par Maverick827, 11 août 2010 - 11:12 .

[Maverick827]

And I would just like to add that I am not very interested in the various mods that alter the talent itself; not only do they typically change much more than this specific talent, but I like to play the game as originally intended. Using anything but aesthetic or convenience mods kind of spoils things for me.

[beancounter501]

This is the code I use. Lifted it from the Combat Tweaks mod


if (HasAbility(oAttacker, ABILITY_TALENT_SHATTERING_BLOWS))
{
if (IsObjectValid(oDefender))
{
if (GetCreatureAppearanceFlag(oDefender, 0x1))
{
if ( IsUsingMeleeWeapon(oAttacker, oWeapon) && IsMeleeWeapon2Handed(oWeapon))
{
fBase += (GetAttributeModifier(oAttacker, PROPERTY_ATTRIBUTE_STRENGTH) * 0.5f);
}
}
}
}

It is OK in Orgins - but since it is a rules_core compile you risk breaking something in Awakening.


Edit: Or you can do what I did which was only recompile talent_single_target and talent_multi_target and then the fix will work with Talents.  But not auto attacks.  But is is safer code wise in Awakening.  Or just turn the mod off in Awakening.

Modifié par beancounter501, 11 août 2010 - 11:40 .

[Maverick827]

So switching the flag from 0x2 to 0x1 works? My guess would be that there is just some lucky bitwise math going on there.

Do you not own Awakenings or just haven't played a 2h warrior through it yet? Exactly how would it break? A crash, or just odd in-game combat results?

[Last Darkness]

Bean I would love to see your combat tweaks mod/

[beancounter501]

LOL, no luck at all. You just have to understand a few things.

GetM2DAInt just means the script is reading in a 2DA file. A lot of the "static variables" are pulled in through 2DA. It gives the devs a way to easily change core data without hard coding it and having to search through code. Everything from weapon damage to talent costs are defined in the 2DA files. You should check the builder Wiki if you are really interested and want to extract them. Bioware has been using 2DA files for a LONG time. Dating to Baldurs Gate.  And I have moded them for a long time

So the command GetM2DAInt(TABLE_APPEARANCE,"AprRulesFlags" is reading the field "AprRulesFlags out of the 2DA Appearance.


If you extract all the 2DA files you will want to check the master 2DA reference table. It indexs which 2DA "tables" are stored in certain workbooks. The reference 2DA table is 2DA_base. If you look up "Appearance" in there you will see that the file is called "APR_". So go open that 2DA and then do a search for the field "AprRulesFlags". Best if you open the 2DA in Excel so you can read read the Developer comments. If you check the comment (in the title column) for "AprRulesFlags" you will see: "georg: 0x1 Count as a construct (for damage)".

Since the variable APR_RULES_FLAG_CONSTRUCT is defined as 0x2(Dooh - wrong one. Nothing has that value in the 2DA) the script does not work. Yet ANOTHER friggin example of a beyond retard Bioware bug fix. Why they have not fixed it is beyond me. But 0x1 does work.

As for what breaks in Awakening. I admit I have been a lazy and never bothered to look if they included a new rules_core.ncs in the awakening folder. If there is no rules_core then it breaks nothing. Sigh, I guess I should check that out. If they did modify rules_core then your game would still work. But some changes may not come through.

Edit: @Last Darkness - I gave up public modding - just do not have the time anymore to support it.  LOL, the wife *delights* in joking the nerd talk as she calls it.  However, in your Dog mod I would be happy to help out with any scripting you need.

Modifié par beancounter501, 12 août 2010 - 01:29 .

[Maverick827]

beancounter501 wrote...

Since the variable APR_RULES_FLAG_CONSTRUCT is defined as 0x2(Dooh - wrong one. Nothing has that value in the 2DA) the script does not work. Yet ANOTHER friggin example of a beyond retard Bioware bug fix. Why they have not fixed it is beyond me. But 0x1 does work.

I find it difficult to truly be upset with BioWare considering all of the rookie mistakes and lazy concessions I have had to make with this Java character planner I'm building.  Every problem feels like fixing a sinking boat with duct tape.

I've made the change and I won't be hitting Awakenings with that character for a while, but if I notice some issues I can just edit back the original.

For a random DA scripting question: when you told me how to fix the momentum + haste bug, you told me to check out Rules_Core and add //This is mine to the top: why is that?  How does adding a short comment change anything?

I didn't do this with this recent fix (I just "checked out" the file, edited the call to GetCreatureAppearanceFlag, and checked it back in).

[beancounter501]

The scripts core_h, combat_damage_h and combat_h are what you would call "include" files in programming. If you are in the toolset you will see they all fall under the category "core includes".

The include files in Dragon Age(and most program languages) are mostly a collection of functions. They include things like CalculateAttackTiming, CalculateDamage - they all sound important - and they are. But changing one has no impact on anything. That is because they are include files. These programs do not run at all directly. Instead, other programs call the functions out. By using include files you can reuse the code - and insure consistenty between programs. Afterall, you do not want to recode the attack calculation for every single talent that makes an attack role! That is asking for trouble. Instead you make an attack function and call that code out through in an include. Hence, whether you are auto attacking or using a Mighty Blow they are all using the same code. But several programs all use the same code.


So, go open Rules_Core and look right at the top and look for the lines # include "rules_h". That one lines of code basically means insert the entire program file rules_h right here into the code. But, if you open Rules_h you will see it calls several other include files - especially the one combat_h. So at compile time, every single include file linked gets pulled into one master file and saved out. A .nss file is source code, and is not run by the game. A .ncs file is what the game actually runs. And that is what is generated when you compile. It is the compiled code the game reads. The game could care less what you did to the source - until you compile it.

The key is to identify what programs are calling out what include files and force the game to recompile the main script to take into account your changes. Rules_Core covers a lot of things - including auto attacks. However the script talent_singletarget covers all of the single target special attacks like Sunder Arms, and Flurry.

When you change the include file, check out one of the main programs like talent_singletarget, adding the line of code "This is mine" makes the compiler think you have change the main program code. The whole point is to force a recompile of the entire script.

But remember changes to the includes are completely independent - until you force a recompile of the main scripts that are actually using them. So it is easy to go MOD shattering blows - but it does nothing until you recompile the scripts that call that function out.

There are three of them:
1. rules_core - Auto Attack
2. talent_singletarget - Covers Sunder Arms, Mighty Blow - all of the single target attacks
3. talent_aoeinstant - Covers 2 hand sweep.

So you can make Shattering Blows work all the time, or only on single target talents.

I hope that helps!

Edit - as someone who programs for a living - it is really hard to understand why they are not fixed.  Other then it is not a game breaking bug - so why bother?  Bioware has a long history of not fixing bugs.  If I was on the QA team, why not go for the "low hanging friut" and fix some easy ones?  This is a really easy fix.  Like the haste bug.  And the haste bug on Bow Attack Speed.  And the bug on Overpower.  And on and on...

Modifié par beancounter501, 12 août 2010 - 03:31 .

[Last Darkness]

I still say you need to make a Mod Bean

[Maverick827]

Thanks for the lengthy reply. My academic background is in C systems programming, so this syntax (especially #include) is very familiar. The only really confusing aspect is working within the toolset itself. From my perspective, a recompile is only one make away, so having to find such a way to force the unwieldy toolset to recompile is odd.

I have yet to work in the industry, so I guess I'm just not as fed up with poor programing habits as you are. =P

Modifié par Maverick827, 12 août 2010 - 03:58 .

[killermadman]

In my experience recompiles due to an include change aren't difficult, but they often carry over into other peoples projects making a simple change difficult to push through.  This is especially true if you have a longstanding code base that has been in use for the past 30 years (cobol).

The whole reason includes exist is to simplify program creation and upkeep (no need to reinvent the wheel or make the same change x number times in z number of programs).

Changing them however calls for a recompile of every program that "includes" them to insert the new code.  Since as someone already noted adding an include to a program simply tells the compiler to insert the include's data in this spot when the code is complied into a program.

As to why various game breaking bugs don't get fixed by bioware I can't say other than its a video game who's bugs are of no "real" consequence.  I assume projects for completed games are assigned a very low priority (if they get assigned at all) and projects for games in production take precedence.

Its not that the programmers don't want to address the issues, but rather fixing the issue only costs the developer time/money presumably better spent on a new project since the games once purchased cease generating revenue.

This is not the case with DragonAge and maybe someone should bring it up to the powers that be that continuing development on DragonAge will increase DLC profit and projected sells of the DA franchise (it takes money to make money).  Gamers dissatisfied by a product are less likey to invest in games offered by the same developer (SOE is never getting another penny from me...true story).

I can't believe that four major patches in there are still abilites that essentially do nothing and have descriptions that tell you nothing about what they do do or how they actually work.  Cause players like things that are vague and shrouded in mystery..no we don't.

Enter the toolset where players/programmers can address everything but executable issues which are a priority for development patches i.e. the crash to desktops and memory leaks which incidentally still exist.

If you are interested in entering the programming career field all I can say is good luck.  It can be fun.  It can also make you wish you never touched a single line of code (well not really but it can be troublesome).

[rayzorium]

I'm usually not one to use anecdotal evidence, and I'm loath to even mention this, but earlier today, my 2H warrior was consistently doing increased damage to golems the Fade - which is a pretty big deal considering how much armor they have. Are you 100% sure that it's still broken?

Modifié par rayzorium, 13 août 2010 - 07:59 .

[Maverick827]

killermadman wrote...
As to why various game breaking bugs don't get fixed by bioware I can't say other than its a video game who's bugs are of no "real" consequence.

I had a professor who would always go off on tangents about how negligent the software community is.  He would always say that software developers are, for whatever reason, allowed by consumers to release shoddy products, but if a piece of hardware is released faulty there is a public outcry for recalls.
I just hope BioWare gets better at patching/QA in DA2 if we aren't given a toolset...

rayzorium wrote...

I'm usually not one to use anecdotal evidence, and I'm loath to even mention this, but earlier today, my 2H warrior was consistently doing increased damage to golems the Fade - which is a pretty big deal considering how much armor they have. Are you 100% sure that it's still broken?

It's difficult to say if it is broken or not.  There's nothing blatantly wrong with the code, we're just assuming that the part of the code that checks if you're attacking a "construct" always says "no you are not, no damage bonus for you!"  Because of this, the only way to truly know if it was fixed in, say, 1.04, would be to test it in game.

If it were working, however, you would be seeing a (Strength - 10) * 0.5 damage increase when attacking undead, skeletons, and golems.  Seeing as primary stats can easily reach 100 base, this could easily be +50 damage a swing, making it pretty noticeable.  I guess the best way to test it would be to attack a non-construct with fully debuffed armor and then a construct with fully debuffed armor.

Modifié par Maverick827, 13 août 2010 - 09:40 .

[beancounter501]

@Maverick - since you are already taking a stab at coding try inserting this line of code in the shattering blows script:

if ( IsUsingMeleeWeapon(oAttacker, oWeapon) && IsMeleeWeapon2Handed(oWeapon))
{
fBase += (GetAttributeModifier(oAttacker, PROPERTY_ATTRIBUTE_STRENGTH) * 0.5f);
//Insert This
PrintToLog("OMG Shattering Blows Works. I hit for " + ToString(fBase));
}

Now go fight some Golems! But, that line of text never shows up in the script

Now mod the script to read

if (HasAbility(oAttacker, ABILITY_TALENT_SHATTERING_BLOWS))
{
if (IsObjectValid(oDefender))
{
PrintToLog ("Please work!");

if (GetCreatureAppearanceFlag(oDefender, CORRECT_CONSTRUCT_FLAG))
{
if ( IsUsingMeleeWeapon(oAttacker, oWeapon) && IsMeleeWeapon2Handed(oWeapon))
{
fBase += (GetAttributeModifier(oAttacker, PROPERTY_ATTRIBUTE_STRENGTH) * 0.5f);
}
}
}

You will see "Please work" all over the place in the log! Hence - it is bugged with a two keystroke fix - delete the 2 and make it 1.

Then Mod the script the exact way I said to fix it and add the whole PrintToLog("OMG Shattering Blows Works. I hit for " + ToString(fBase));

Fight some Golems and Constructs and you will see that message in the script log.

You can pretty much debug any segment of code using the PrintToLog function.  Don't bother trying to test it out in game.  There is too much variation.  Better to go straight to the source!

Modifié par beancounter501, 14 août 2010 - 12:46 .

[Maverick827]

Hah! I always use debuggers sparingly (gdb...ugh) and typically my code will be littered with printf("DOES THIS WORK?");

I didn't even think to try it here because I did not know about the PrintToLog function.

As long as this current fix is working, it doesn't matter so much right now, but I'm sure I'll be taking a peek into some code later on.

Modifié par Maverick827, 14 août 2010 - 12:56 .

[Wullack]

I've read through the thread but I find myself in a bit of a loss as to where to edit what to fix the shattering blows talent. Could you give me a hint in which file I have to change the 2 into a 1. I took a look at some of the scripts (rules_core etc.) but couldn't find the spot.

Modifié par Wullack, 02 septembre 2010 - 03:15 .

[beancounter501]

Look at the seventh post down. But to make the fix it several easy steps:



1. find the script combat_damage_h in the editor. Right click on the file and select check out

2. Do a search for the word ABILITY_TALENT_SHATTERING_BLOWS

3. Make the change.

4. Click save. It is going to complain that it did not compile. But don't worry about that

5. Right click on the file name again and click check in

6. Now find the following three scripts: rules_core, talent_singletarget , talent_aoeinstant

7. Check each one out individualy

8. Add the following line at the top of each one //This mine. The double // are critical

9. Save each file and check it back in

10. They should compile correctly. If they don't then you have a problem somewhere.

11. Go find some Golems or Skeletons and hit them. You should see higher damage.



If you are unsure your change is not working then make this change in combat_damage_h

Find the line:

fBase += (GetAttributeModifier(oAttacker, PROPERTY_ATTRIBUTE_STRENGTH) * 0.5f);



Change the 0.5f to 10.0f. You should see a huge difference in damage. Since it now does 10 times your strength mod.

You should see

[Maverick827]

I'm pretty sure this doesn't work in Awakenings after bringing my 2H Warrior over. That plus the Vigilance bug killed the fun of my 2H Warrior. =(

[Wullack]

@beancounter501: Thank you for your help! Now I have to get the talent and find some skeletons to hit. It's a shame they didn't fix those tiny bugs in one of the various patches.