Loren Tyr

As a rule, whenever you see an "X over Y seconds" effect, this X refers to the total endurance gained / damage dealt / whatever. See for example also Envenomed Strike and Necrotic Lance. So for Consecrated Ground the +9.3 Endurance is the (base) total amount healed (per CG pulse). These pulses happen every three seconds. To be honest I'm not sure why the healing effect itself has a duration at all, rather than just being applied immediately. It's so short it hardly matters much, and it does make the math a bit less intuitive. It's actually just a reverse ApplyOnTick DoT, which works as follows: the effect is defined as a PerTick value and a duration. Ticks occur every three seconds, starting at zero and with an additional fractional tick at the end (unless the duration is an exact multiple of 3); the effect for this fractional tick is proportional to the remaining duration. So for example if you have a damage DoT of 15 Raw damage per tick and 5 second duration, it will do 15 damage on the 0 second and 3 second mark, and then at the 5 second mark will do a final 2/3 x 15 = 10 damage. So the total damage is (PerTick value) x (Duration/3 + 1) = 15 x 2.67 = 40 ( = 15 + 15 + 10). Getting back to Consegrated Ground, this has a base duration of 1 second and a base PerTick value of 7, resulting in +7 Endurance at 0s and +2.33 Endurance after 1s, so a total of 7 x (0.33 + 1) = +9.33 Endurance overall. Might will act as a bonus on the PerTick value, INT increases the duration. In this case your character seems to have 24 INT to get the +70% duration, calculating backwards thus gives an adjusted PerTick value of 8.68 = 7 x 1.24, so presumably your priest has 18 Might.

It does: public static void GetEnemiesInRange(GameObject owner, AIController aiController, float range, List<GameObject> enemiesInRange) Which does look rather weird to me. But that's just because of the whole "objects are really just object references" thing that C# has going on, it's not specific to this function. The function itself is primarily used to populate existing lists (and not necessarily perception distance), so it does make sense to do it this way. Even where a newly created list is passed, it's still to subsequently iterate through the enemy list. There are several instances where just a count is needed, but in those cases that is implemented directly rather than by calling the GetEnemiesInRange function (or its brethren); those tend to check some specific additional condition as well, I suspect there was never much use for a generic 'count' function in the way I'm using it here. So if they do make my suggested change it'd indeed be more efficient to create a public static int CountEnemiesInRange(GameObject owner, AIController aiController, float range) function, just a matter of copy-pasting the GetEnemiesInRange function with some minor changes.

Right, and C# will just magic up the corresponding GetEnemiesInRange function? Because I'm thinking the compiler will just throw a hissy fit about there being no such function and quit on you. Maybe it's just my old-fashioned C++ mind-set, but I prefer writing code that actually compiles.

I'm essentially doing that already, though . Anyway, I just enjoy a good puzzle now and then. On the Iconic Projection bypassing DR listed in the OP by the way, that looks to be primarily a GUI issue. The ApplyDamageDirectly function IP ends up using does do DR reduction, though only at 25% DR (would be quite involved to change that to 100% for Iconic Projection specifically, as far as I can see). The floating damage number on screen correctly reflects the reduced number, it's the tool tip in the combat log that's wrong; down the line it uses the StatusEffectParams.GetString function, which cannot incorporate DR reduction.

I suspect that it's not really a bug (now, or at the time of saving), but actually just a save game incompatibility. The saves are from 6th of April 2015, so that's all the way back to v1.03. With the many changes since then, the structure of the same games in general or serialized objects in particular likely have changed such that they are not loaded correctly anymore. Or stats and temporary effects are added and removed differently, leading to incorrect values. Running your saves, I also get quite a few messages in the output_log.txt file that point to the game having a bit of trouble generally with these saves (and Eternity Keeper is simply refusing to load them at all). Presumably, at the time in Save B the base accuracy for Aloth was still fine, but is now loaded incorrectly. There's something odd going on there anyway: Aloth is Maimed yet his Health is at 100%, a combination that cannot really occur naturally. It's also not the Maimed affliction itself in some way. If I load save C and Maim Aloth, he still retains the correct 20 base accuracy. I fear it is probably not going to be possible to fix the incorrect values (respeccing does nothing for it, in any case). You could try going on from a save game where all the base accuracies are as they're supposed to, but there's obviously no guarantee that there still isn't something off with the base accuracy or other stats that could manifest later. I think you're better off starting a new game instead; aside from avoiding this issue, there have also been quite a few changes in terms of balancing and abilities and such, which you could then take into account for your characters from the start.

California is a tad far from here though

A very small thing by the way, but the Binding Rope gets an "[CHARACTER] affects [TARGET] with *EffectError*". Probably missing a string somewhere.

I have looked into the issue of Charmed/Dominated characters turning hostile again too easily a bit as well. I think it should be relatively easy to fix so they behave more naturally, ending the Charmed/Dominated effect only if they can't see any enemies anymore (and doing so one by one, in multi-charm situations) rather than just when they're not targetting anyone at the moment. See details here: http://forums.obsidian.net/topic/88493-charm-confuse-and-dominate-cancelled-prematurely-303/?p=1840154

Just wanted to bump this a bit. I checked into the code that ends the effect, at the end of the StatusEffect.UpdateHelper function. What is does is simply to check every two seconds whether it has a current target, and if it does not (and is not Confused) the effect is ended. Obviously there are plenty of reasons why the character might not (currently) have a target, other than there not being any at all. The previous target may have expired but no new one selected yet, or there may be enemies in sight but outside the movement range the AI for that character allows. Even if in the latter case the Charmed character would stay put rather than engaging out of range enemies (but visible), that still seems preferable than the Charm effect ending with visible enemies in range. That a character sticks to his "I'm defending this spot, not moving an inch" AI mind set is fine (and makes sense, conceptually), but that shouldn't make him inherently less susceptible to being charmed. My suggestion would be to add an additional check for enemies in visible range, if there is no current target. At present the relevant bit of code looks as follows (modulo having been run through a disassembler, and slightly formatted for space): if (aIController != null && aIController.CurrentTarget == null && !aIController.IsConfused) { if (this.AfflictionOrigin != null) { this.m_targetStats.ClearEffectFromAffliction(this.AfflictionOrigin); } else { this.ClearEffect(this.m_target); } } I would think changing it to something like the following would result in much more intuitive Charm/Domination: if (aIController != null && aIController.CurrentTarget == null && !aIController.IsConfused) { List<GameObject> enemies = new List<GameObject>(); float range = aiController.PerceptionDistance; GameUtilities.GetEnemiesInRange(this.m_target, aiController, range, enemies); if (enemies.Count == 0) { if (this.AfflictionOrigin != null) { this.m_targetStats.ClearEffectFromAffliction(this.AfflictionOrigin); } else { this.ClearEffect(this.m_target); } } } This should result in the character staying Charmed/Dominated if it can still see any enemies; arguably the range could be extended somewhat beyond the PerceptionDistance to have some more margin (the TargetScanners tend to use PerceptionDistance * 2, though that seems a bit much here). Having this in place should also stop groups of Charmed/Dominated enemies all turning hostile again at the same time if no actually hostile enemies are left (which at present also essentially forces you to try to deliberately miss at least one enemy with any group Charm effect, since if you hit everyone they almost instantly all turn hostile again for lack of viable targets). UpdateHelper calls on the SwapFaction StatusEffects on different Charmed/Dominated enemies in a single update step are (presumably) sequential, so even if the first to be evaluated would find no enemies and turn hostile, the second Charmed/Dominated character would then see that first now hostile enemy and stay Charmed/Dominated (likely selecting it as a Target in the next AI update).

It is a bit over the top though. I'm fine with paying for a useful service, but not to download this one file; and especially when they're being this obnoxious about it.

As reported by Asdu (http://forums.obsidian.net/topic/83388-class-build-the-leech-barbarian-time-bandit-tank/?p=1839742), there is also an issue with Spelltongue often given permanent duration bonuses to abilities that carry over to later activations. I have traced the bug, it has a very simple fix; details can be found here http://forums.obsidian.net/topic/88918-303-spelltongue-permanent-duration-bonus/?p=1840003 Edit: just noticed Wall of Draining listed in the OP list, this is the same issue.

Summary: Spelltongue gives permanent duration bonuses to many abilities if they are active when the Spelltongue effect is resolved. Can be fixed by setting the SkipOverride flag to true on the call to AdjustStatusEffectDuration from SpreadBeneficialEffectTime. As brought up by Asdu in another thread (http://forums.obsidian.net/topic/83388-class-build-the-leech-barbarian-time-bandit-tank/?p=1839742), when using Spelltongue the duration of many (Frenzy, Unbending, Vigorous Defense, Disciplined Barrage, ...) though not all (Savage Defiance, Veteran's Recovery, non-ability effects) abilities is permanently increased. Some further testing shows that this happens in particular when those abilities are active at the time Spelltongue hits. The issue can easily be reproduced by using an ally as a target. Have character A wield Spelltongue, and character B serve as target. Have B consume some food and/or drugs to have beneficial effect time to steal, and have a third character attack some NPCs to enter combat mode so you can activate abilities. Have A activate an ability like Disciplined Barrage, and start attacking B. After a couple of hits, right-click on the ability's icon to see its description, and note the duration having (significantly) increased. This increase carries over to subsequent combats, though it does seem to disappear when reloading (I cannot be sure that always happens, however). The Spelltongue effect is processed by the StatusEffect.ApplyEffectHelper (ModifiedStat.TransferBeneficialTime). This first calls CharacterStats.AdjustBeneficialEffectTime to reduce the duration of beneficial effects on the target, then calls CharacterStats.SpreadBeneficialEffectTime to add the stolen duration to the wielder's beneficial effects. Both these functions end up calling the CharacterStats.AdjustStatusEffectDuration function, but a key difference is that for this function SkipOverride is set to true when reducing on the target but set to false when adding to the wielder. This coincides with the fact that the reduction on the target is not permanent, the issue manifests due to SkipOverride being set to false. When SkipOverride is true, only the Duration parameter on the StatusEffect is modified. If it is set to false, the DurationOverride is modified as well (unless it was zero to begin with), which is what causes the problem. For GenericAbility's, the StatusEffect objects are created when the ability is first initialized (when gaining it, when loading the game). At this point the DurationOverride of the StatusEffect is set to the DurationOverride value of the GenericAbility. When the ability is activated the StatusEffect is applied, and its Duration is computed from either its DurationOverride (if it is non-zero, eg. Frenzy, Disciplined Barrage) or otherwise its StatusEffectParams.Duration value (eg. Savage Defiance, which has a DurationOverride of zero). When the StatusEffect ends it is removed, but is not destroyed; a second activation of the same ability uses the same StatusEffect object. The DurationOverride value is never reset in between, which means that changes to it are permanent and stick around until the StatusEffect is destroyed (on reload, respec, console-removing the ability). In summary, therefore, the DurationOverride on ability StatusEffects should never be modified; the SkipOverride=false setting on the AdjustStatusEffectDuration is only intended for StatusEffects that are destroyed after a single use, such as for afflictions (other than the SpreadBeneficialEffectTime function, that's what it is used for). The solution would therefore be to simply change this.AdjustStatusEffectDuration(current2, durationAdj); in the CharacterStats.SpreadBeneficialEffectTime function to this.AdjustStatusEffectDuration(current2, durationAdj, true); as is also used when first reducing the durations on the Spelltongue victim.

I certainly concur with the latter sentiment, though in this case setting "Immune == Infinite DT" is not unreasonable. The alternative would be to set an additional vector of "is immune" flags by damage type, and check those separately. You'd still want to do that at the DT/DR computation and/or reduction stage, rather than at initial damage computation, since that's a nice funnel where anything damage-y ends up.

I've experimented with it a bit, I can easily reproduce the issue so it is indeed clearly not specific to your installation or savegame (so never mind uploading your savegame). Fortunately it also works when stealing duration from allies, so I just have to dump some food into Eder and stab him a bit with Spelltongue for it to manifest. What I've learned so far is that an ability needs to be active when the Spelltongue effect is applied; as long as Frenzy is off, you can attack with Spelltongue as much you want but the duration stays exactly as it's supposed to be. Which makes sense, since Spelltongue only modifies duration of active effects, for Frenzy it just seems to affect the base duration (or maybe a DurationOverride, not sure yet), rather than (just) the current duration. Why this happens to Frenzy but not other effects (not Savage Defiance, as you said, and so far not Veteran's Recovery either) I'm not sure. I'll do some more testing and checking of code later to see if I can find a meaningful pattern, see what differentiates affected and unaffected abilities (and whether it is Barbarian-specific, but I very much doubt that). Edit: Hmm, it's becoming more of a question why Veteran's Recovery and Savage Defiance aren't affected, really (maybe because they affect Endurance, though I haven't seen an obvious reason in the code so far as to why that would matter). Outlander's Frenzy, Unbending, Vigorous Defense and Disciplined Barrage all are affected as well (and it's not Barbarian-specific, obviously). Also of note, the target doesn't get his Frenzy duration (or whatever) permanently reduced. Both the reduction on the target and the increase on the wielder use the same AdjustStatusEffectDuration function, though the SkipOverride flag is set to true for the reduction but to false for the increase. If set to true only the Duration parameter is modified, but if set to false the DurationOverride value is changed as well... ... and as it turns out the GenericAbility of Savage Defiance has its DurationOverride set to zero and its Duration set directly on the StatusEffect, whereas for example Disciplined Barrage has the duration in the DurationOverride of the GenericAbility. Starting to make sense now... ... sense-making complete. Just adding ", true" in the appropriate spot should do the trick. I'll dump one of my characteristically long-winded write-ups in the Tech forum tonight/tomorrow, with link to it from the 3.04 patch thread.

You can still just make free new account actually, you don't need to get a subscription for it. When registering an account, just scroll past all the payment packages and click 'Create Account', essentially all you need is an email address.

Which abilities have you found to be affected by it, and which not? (beyond the ones you already mentioned) And could you upload a savegame where your Barbarian is exhibiting this (using SendSpace or something)? Then I can dig through the code and might be able to figure out what's going on; as Jojobobo says there is still one patch coming, and if I can provide the devs with details on the underlying cause that would considerably improve the chances of it getting fixed (also, I like the challenge ).

To my knowledge the issue with Torments Reach is just that is has a goofy int scale ratio? Am I missing something? - Sking Actually, it seems to be triggering recursively, with the Torment's Reach cone AOE effect being applied to the victims in the original cone AOE. I just tried it again with a newly minted 10 INT hireling monk, who hit a column of about 5 meters (there wasn't any target beyond that). Moreover, some targets were also hit multiple times. In a way it is similar to eg. the Consecrated Ground + Knockdown / Black Path + Envenomed Strike. A StatusEffect (TR cone, Knockdown, Envenomed Strike) is active to modify an initial attack, but is still active when subsequent (TR, BP) or concurrent AOE (CG) hits are processed so those get modified as well. Carnage actually has its own implementation and an explicit toggle to ensure it doesn't trigger recursively.

Hmm, I'm inclined to think it is a glitch of some kind specific to your save. Trying it out for a bit, Spelltongue does seem to work normally for me, subsequent effects have the duration they should have. The effect should affect only effects active when it hits anyway, not anything that's activated afterwards.

I don't know, 'cause I still have half a battle to go and I like winning them? Not sure what game you are playing, but in mine Paralyzing enemies is very useful all the way through the fight. Also, stop exaggerating; in the bigger fights, you can start casting invocations far before you hit the halfway point. Anyway, I would suggest (along with everyone else) that you actually play the class before complaining about bad design. Grab Kana if you don't want a main character Chanter.

Solve what? I still don't see the problem. In my experience Chanters work fine (and no, not just on PotD and/or on level 16). Sure, in short fights they're not going to be doing much Invoking. But then again, if they're over that quickly then apparently there was no need for it. It's not as if a Wizard is going to waste any of his spells on a fight like that either. And conversely, Monks and Ciphers also need some time to build up the resources for their more powerful abilities, they can't use those at the beginning of combat either. Besides, you're acting like Chanters are just about the Invocations, where they're just as much about the chanting. It also doesn't make sense to have BR have its full effect immediately. That's just lowering the overal recitation duration, there'd be no reason to give a separate talent for that.

Being wildly unscientific, how would you draw any kind of conclusions from it though? Of the various potential issues (and good polling is exceedingly difficult, so there are many), the most important sticking point here would be that the poll respondents is inherently restricted to people visiting this forum, and therefore (almost certainly) not representative of the general population of PoE players. Also, without data from a meaningful reference population (All PC gamers? All RPG players? ...?) there is nothing to compare it to even if it were a representative sample.

I disagree with it only being useful on PotD. I only ever play on Hard and get plenty of use out Kana, both in terms of Chants as well as Invocations (emphasis on the latter, as I tend to go for the fast-chant type of build). It certainly needs no redesign. Given that along with the Cipher it is one of the most distinctively PoE-specific classes, I would be deeply surprised if they significantly changed the core mechanics of the class, let alone dropped the class altogether (here's hoping for a big Wizard/Druid/Priest overhaul, though...).

Food, drugs, spells and many abilities all fall in the same category, actually. In practice, it boils down to the following: - From non-weapon/shield items: the best bonus and worst penalty apply - From active/modal effects (consumables, spells, afflictions, many abilities (see their description), etc.): the best bonus and worst penalty apply - From everything else (resting, weapon/shield, passive abilities, etc.): everything applies For abilities the active/passive/modal qualifier should be listed in the description; passives are generally ones that are always on, though some are conditional/triggered. For example Bloodlust is a passive ability that triggers a temporary speed bonus when you kill two enemies, but this bonus still counts as 'passive' and will stack with everything. Also keep in mind that this applies per stat, which can be quite narrowly defined. For example, 'Accuracy' and 'Melee Accuracy' count as different stats, so bonuses to those won't suppress each other even if both are from eg. an active effect.

I traced the bug and posted an easy fix in the linked thread.

I've poked through it a bit, can confirm that it is definitely related to Triggered Immunity (and Immunity in general). I could easily reproduce it with Esajin's save: gave the three Fighters Triggered Immunity, charged into the Adragan + Adra Beetle cluster in front of the Hylea temple and had them stand there doing nothing getting hit, continuously checking the character sheet page. A big Shocking Blast from one Adra Beetle to get Triggered Immunity: Shock, followed by a second Shocking Blast from another Adra Beetle was enough to get 'Damage Taken' to -Infinity. The problem seems to originate in the CharacterStats.AdjustDamageByDTDR_Helper() function. Among other things this calls the CalcDT() function to compute the damage reduction; key is that this function will return +Infinity if the character is immune to the damage type in question. A couple of lines later the damage amount X is reduced by the DT value, and thus X will become -Infinity if the character is immune to the damage type. The function does check whether DT is +Infinity and sets the IsMin flag and triggers the "Enemy is immune" notice, but it leaves X at -Infinity. At the adjusted damage X is returned to the calling function, to do with it as they will. Clearly most functions that use this value do check whether it is negative and set it to zero if so (you don't see +Infinity Endurance as a result, and the combat log also shows the damage amount being done as 0.0 when immune). But apparently the character sheet logging function doesn't, resulting in this bug. My suggestion would be to either a) set X to zero if DT is found to be +Infinity or b) check whether X is smaller than zero right before the return statement, and set it to zero if it is (or equivalently, just do "return max(X, 0);"). Option a) would be sufficient though, since the minimum damage value cannot become negative, and will replace any negative X if the DT is not +Infinity.