[IfritnoItazura]

Was hoping to S-E would have fixed it as soon as they found the problem, but I suppose it's better they do more testing (this time) before releasing it.

[Brayden]

Originally Posted by Lmnop

For the record, as a level 75 elvaan war/nin, my DEX is 68 before gear. That means I got +34 free acc just from this update.

In late with comments, but I was under the impression that the 1 dex = 1 acc was for armor boosts only, not base stats.

[Armando]

No, it's any and all DEX. Not sure how the rumor that it affected DEX from armor only came about. Oh, and...

Originally Posted by Amele

again, it's hard to characterize how the function is behaving in the range above 1.667 and below ~2.3 we *don't really know* what's going on because no one has made a rigorous test of it yet (to my knowledge)

I did some tests on Sunday. It was exactly as you said - the PDIF functions from before the patch are being used to determine the min/max PDIF ranges, numbers are being picked evenly within the range, and any values that exceed 2 are being capped at 2. I can post my numbers and stuff if you want.

[Amele]

armando; yes please.

ifritnoitazura: you're making the assumption that the issue players are seeing is because SE introduced something unbalanced that hadn't been tested thoroughly; it's entirely possible the problems are from an incomplete compile or a relink that didn't go correctly and the application is otherwise as intended.

SE took alot of time to roll out these changes and warned us pretty far in advance; alot of it (STR=ATT DEX=ACC etc.) can't be anything *but* intentional, so it'll be interesting to see where things end up.

for all we know, SE is moving crit cap on 2h to 4.0 and leaving the regular cap at 3.0

[Armando]

Here you go, Amele.

Fights 1-3

Target: Lv.48 Demon Pawns (47 VIT, 177 Defense according to Studio Gobli's formulas, confirmed through /check.)
Weapon: Save the Queen (DMG: 40)
Attack: 312
STR: 69+8
fSTR: 9

Damage ranges
#1: 65-98
#2: 66-98
#3: 62-98

cRatio: 1.76
Max PDIF: 2.11 (capped at 2.0)
Min PDIF: 1.31
Expected damage range: 64-98

Fights 4-6

Target: Lv.48 Demon Pawns w/ Dia II (158 Defense)
Attack: 320
All other conditions are the same as before.

Damage ranges:
#4: 78-98
#5: 78-98
#6: 78-98

cRatio: 2.02
Max PDIF: 2.43 (capped at 2.0)
Min PDIF: 1.62
Expected damage range: 79-98

Fight 7

Target: Lv.48 Demon Pawns, normal Defense
Weapon: Warp Cudgel (DMG: 15)
Attack: 134-139 (got skill-ups)
STR: 69+7
fSTR: 9

Damage range:
#7: 12-24

cRatio: 0.75-0.78
Min PDIF : 0.40-0.43
Max PDIF: 1.0

Expected damage range: 9/10 - 24

*Note: This fight was cut short because I linked a bunch of demons and had to pull out Save the Queen. Might not have reached lowest possible PDIF.

Fights 8-10

Save the Queen
Meat Mithkabob
Attack: 383
STR: 69+13
fSTR: 10

Damage ranges:
#8: 89-100
#9: 91-100
#10: 87-100

cRatio: 2.16
Max PDIF: 2.59 (capped at 2.0)
Min PDIF: 1.79

Expected damage range: 89-100

*Note: Significantly more 100's (i.e. PDIF = 2.0) than previous fights.

Fights 11-12

Dia II
All other conditions same as before

#11: 100-100
#12: 100-100

cRatio: 2.42
Max PDIF: 2.9 (capped at 2.0)
Min PDIF: 2.1 (capped at 2.0)

Expected damage range: 100-100

Fight 13

Dia I (New Defense: 167)
All other conditions the same

#13: 98 (one hit), 100-100; one crit for 148, all others 150

cRatio: 2.29
Max PDIF: 2.74 (capped at 2.0)
Min PDIF: 1.94

Expected damage range: 97-100

*Notes: As stated above, could only get two hits to not hit the 2.0 cap, one of which was a crit.

[IfritnoItazura]

Originally Posted by Amele

ifritnoitazura: you're making the assumption that the issue players are seeing is because SE introduced something unbalanced that hadn't been tested thoroughly; it's entirely possible the problems are from an incomplete compile or a relink that didn't go correctly and the application is otherwise as intended.

The application is not working as intended, per S-E's own words. I don't see how an "incomplete compile" can possibly run and not crash, and version control and software testing is supposed to prevent and catch "linking" problem such as having the wrong library, etc. (And, yes, QA definitely should catch "incomplete compile".)

You are giving S-E's QA team too much credit.

(By the way, I used to work in software quality assurance; it really doesn't matter why things are wrong, but if customer sees problems, the QA team screwed up.)

[Amele]

Originally Posted by IfritnoItazura

The application is not working as intended, per S-E's own words. I don't see how an "incomplete compile" can possibly run and not crash, and version control and software testing is supposed to prevent and catch "linking" problem such as having the wrong library, etc. (And, yes, QA definitely should catch "incomplete compile".)
You are giving S-E's QA team too much credit.
(By the way, I used to work in software quality assurance; it really doesn't matter why things are wrong, but if customer sees problems, the QA team screwed up.)

right but QA is not necessarily feature function test. I misunderstood which aspect of testing you were referring to. (thinking you meant feature function test.)

incomplete compiles run but don't crash when you have multiple files to compile, not all of them are compiled, but the necessary functions still exist in the older files (just in their unchanged forms)

likewise, linking problems can result in new code being attached to old code or being attached to old methods in new code etc etc.

both of these things Should have been caught by QA yes; but depending on the workflow that SE uses before publishing, it's entirely possible that QA never actually tests the version that goes live, just all the code compiled with debug features, then trusts that the makefile (or substitute) for a release compile is identical less the debug enable switch.

[IfritnoItazura]

Originally Posted by Amele

incomplete compiles run but don't crash when you have multiple files to compile, not all of them are compiled, but the necessary functions still exist in the older files (just in their unchanged forms)

Huh? I don't remember the technical phrasing, but if a compile did not complete, then some symbols/tables won't be generated, and the whole thing probably shouldn't even link.

Originally Posted by Amele

likewise, linking problems can result in new code being attached to old code or being attached to old methods in new code etc etc.

both of these things Should have been caught by QA yes; but depending on the workflow that SE uses before publishing, it's entirely possible that QA never actually tests the version that goes live, just all the code compiled with debug features, then trusts that the makefile (or substitute) for a release compile is identical less the debug enable switch.

Sorry, but that's just B.S.

If I don't see the in the QA plan something on verifying live version's binary/data/etc. is the same as the tested version, I'd ask the QA manager to be fired--even if the manager is in the room. It's not a matter of "workflow", it's something every QA person should know to test.

It really is QA's fault we got a broken version update. (Dev may also be at fault, but QA cannot be excused.)

[Olorin401]

Originally Posted by Mhurron

I probably forgot a decimal in there, damnit, I always do that.

Yeah I know I'm a bit late.. I was busy assaulting a fax machine in the parking lot.

[Lunaryn]

Originally Posted by IfritnoItazura

Huh? I don't remember the technical phrasing, but if a compile did not complete, then some symbols/tables won't be generated, and the whole thing probably shouldn't even link.

I believe what Amele is referring to is a dependency error where not all objects are being rebuilt. Each object that compiles being compiled completely, but some dependent objects go uncompiled and are linked against the old version. I suspect that's not what happened here but it's possible, if the relevant change was in a header file. (If I had to venture a guess, either a line of code that should have been deleted was not, or someone changed a header constant without realizing it was used in a particular line of code, or the wrong constant was referenced in a particular line of code, or at some point someone put in a literal constant instead of a header-defined constant...)

[IfritnoItazura]

I suppose it can link if the old object files are somehow in the path, but wouldn't it takes a pretty poor build system/build engineer to let that happen? In years of QA work, I've never seen anything remotely close to that happened after a project hit Alpha.

Heck, QA doesn't even perform build acceptance test if something didn't compile--whether it linked or not, the compile error will be in the logs, and the mess is sent straight back to the the Devs.

[Callisto]

Originally Posted by Olorin401

Yeah I know I'm a bit late.. I was busy sexually assaulting a fax machine in the parking lot.

FTFY bud!

[Amele]

ifritnoitazura, you're right! I don't disagree.

but you have to admit it happens all the time.


-> and incomplete compiles happen when you make without cleaning the intermediate files first, something will just get touched rather than recompiled and sometimes a mistake will be made either in the new makefile or by the compiler itself and something will get touched instead of recompiled, then the linker will still work because the object file exists and all the necessary public functions are exposed so it'll run, if wrongly.

it's rather complicated and can be avoided with super strict makefile control and mandatory clean makes, but debugging is rarely (if ever) done this way because of how much additional time it would take to recompile from scratch every time you fixed a mistake in the debug code.

edit:
and for sufficiently complex makefiles, it's not uncommon to see most of the 'final' make copy/pasted from the debug make - which can result in touches instead of compiles.

and touches don't generally generate compile errors/warnings (the do generate a message other than 'compiled foo.o' but if your SOP says to touch rather than recompile existing unchanged code, that won't look out of the ordinary to QA.

[Lmnop]

I had a big monotonous post about things that happen, but I'll just say this instead:

Developers are often lazy and incredibly unorganized. It's not too far out of the question that they grabbed the first version of their 2 handed changes, from 3 months ago just before they decided to go through and revise it. And since they've already thoroughly tested the revised version, they compile the new code and send it off to the people to implement on the live servers, "knowing" that it's good to go.

[IfritnoItazura]

Originally Posted by Amele

it's rather complicated and can be avoided with super strict makefile control and mandatory clean makes, but debugging is rarely (if ever) done this way because of how much additional time it would take to recompile from scratch every time you fixed a mistake in the debug code.

This is the way I've always seen it:

Official builds (the binaries the QA normally receive):
1. Strict version control on source code.
2. Build system/build engineer do its magic; only what's checked in is built.
3. Partial builds accepted under special cases only, and only with negotiation between Dev and QA.
4. Dev and QA engineers both isolate changes and problem area for focused testing; QA is responsible to verify only the portions Dev said were changed indeed were changed.

Debug builds:
1. Usually build at engineer's desk/laptop; sometimes (but rarely) go through the official system.
2. Major debug builds are archived for reproducibility, but usually if the fixes are that risky/involved, they just fire off an official build.
3. Dev give QA debug version of certain module/library from time to time for extended testing, but they are supposed to be (and usually are) clearly marked as debug version.
4. New defects are not filed against debug builds, and existing defects cannot be mark "fixed" based on those testing.

The point is QA does not alter official records from debug builds, and in fact spends majority of its time with official builds--while that is not a "full" build, but is "clean" enough for the purpose of this discussion.

Really, build issues should have been ironed by by Alpha (feature freeze).

Originally Posted by Amele

and for sufficiently complex makefiles, it's not uncommon to see most of the 'final' make copy/pasted from the debug make - which can result in touches instead of compiles.

I don't know, never been involved with build system at that level of detail. All I can say is that post-Alpha, I can only count a handful of times build system/engineer said "OK, good to go to QA", then came back later saying "It's been build wrong--stop testing."

For problem in release software systems, it's a lot easier for me to imagine
1. QA dropping the ball.
2. Management overruling QA objections. (50%-80% of time? lol)

Than to blame the build system.

Heck, most of the trouble with build servers I've seen are storage related than makefile related. "What do you mean we can't have all the builds online on the normal server? Why don't we have room? Can't you kick other teams off that server or stick another hard drive in there?"