"
"
I want to know whether their current implementation has any noticeable effects on performance. Because, if it does, sure sounds a lot better to have the game drastically reduce the calcs required. Currently, there's no PC on the market that we can buy that can run certain builds at a stable framerate. Doesn't matter if you have the latest hardware, the game engine will bottleneck you anyway.
The game is server-authoritative.
The tracking that does or does not get performed server-side has no relevance to your client's FPS.
Gameplay progression is gated by the server tick rate. If the server can’t process simulation ticks fast enough because of heavy calculations, complex builds, or CPU bottlenecks the authoritative game state updates stall.
The client continues rendering, but literally no one care about that because the game is effectively paused for no reason on the client view.
"
Mark_GGG wrote:
check if their id is even or odd to determine whether that action uses the main or off hand.
Did someone say spaghetti?
|
Posted byxiaoxiao921#3803on Feb 20, 2026, 9:52:53 AM
|
"
If the server can’t process simulation ticks fast enough because of heavy calculations, complex builds, or CPU bottlenecks the authoritative game state updates stall.
What a strange thing to say...
1. "heavy calculations, complex builds, or CPU bottlenecks" - While I'm always happy to see someone using the Oxford comma, listing two examples of CPU bottlenecks immediately before the words "or CPU bottlenecks" is very weird.
2. "If the server can’t process simulation ticks fast enough [...] the authoritative game state updates stall." - I posted about a server incrementing a number. Just how many milliseconds of work are you attributing to that?
If you want to post about something other than what I myself have commented on, feel free - but next time please don't quote me when doing so. Baumi asked about how tracking is performed while expressing misgivings about performance and what any "PC on the market" can accomplish - therefore clearly talking about client-side performance. I responded to that, and I stand by that response. I didn't put words in anyone's mouth - please don't do that to me.
Having spent thousands of euros on Path of Exile over the years, I will not be further supporting it financially until and unless GGG resumes offering Technical Support.
|
Posted bySarno#0493on Feb 20, 2026, 10:19:10 AM
|
"
Baumi asked about how tracking is performed while expressing misgivings about performance and what any "PC on the market" can accomplish - therefore clearly talking about client-side performance.
Yes and no. I've been told before that Lockstep Mode doesn't affect performance. On a technical level, it shouldn't, but I proved that it did, and I've known this for years. You cannot play certain builds with Lockstep; first the network and FPS goes to shit, then the network is basically playing catch up and FPS goes stable until the game recovers. I've been dealing with this specific issue for years, as CWDT builds are like my thing, and it didn't improve with better internet or a better PC. Not even my 9800X3D can deal with this, the red bar (CPU) is consistently the longest.
GGG made the first huge change a couple years back with the fix to Ignite tracking, which vastly improved performance for builds applying tons of Ignites per second. If I had a time machine and could somehow port my build back over there, it would be literally unplayable, as even weaker/less spammy versions were already unplayable, regardless of which networking mode you used.
Hence my question on how this tracking works. Because if it's affecting performance, I wonder what reason they have to track all these individual spells as a separate action, not just as an entity. All of those stats they are tracking should be applicable to CWDT itself as the, let's call it, "parent operator". If you get what I'm trying to say.
Edit: For example, as I currently understand it, CWDT applies a global cooldown to each socketed spell, not itself. If GGG were to change this to instead apply to each CWDT gem itself, it could alleviate some of these extra calculations. Flipside being that this opens you up to using the same spells across several setups. And would that be so bad in current PoE? We already have cooldowns to balance things out.
[0.4] Pyro Ward: https://youtu.be/E-8P4XfDHJw
[0.4] Caltrops Build: https://youtu.be/TlKk95y57hk
[0.4] Candle Runner: https://youtu.be/h0F-0EgS5J8
[3.27] Poor Man's Ward Loop: https://youtu.be/p5NA_Rf2TJU
[3.26] Shaper Beam Totems: https://youtu.be/soG0-Y2pDDo Last edited by BaumisMagicalWorld#0673 on Feb 20, 2026, 12:08:24 PM
|
|
"
"
If the server can’t process simulation ticks fast enough because of heavy calculations, complex builds, or CPU bottlenecks the authoritative game state updates stall.
What a strange thing to say...
1. "heavy calculations, complex builds, or CPU bottlenecks" - While I'm always happy to see someone using the Oxford comma, listing two examples of CPU bottlenecks immediately before the words "or CPU bottlenecks" is very weird.
Client's cpu vs server's cpu.
|
Posted byOminarous#1072on Feb 20, 2026, 3:20:41 PM
|
|
Thanks Mark,
why don't you guys document more like this? I would love if you would create the content for "the wiki" ...
Leaving room for exploration as someone once said, is nothing I personally like too much.
|
Posted byS1nister#3313on Feb 20, 2026, 7:03:54 PM
|
"
I already did, and my question is not clearly answered there. Unseen Strike is a single skill from a single trigger and is its own skill. CWDT can have multiple spells attached. He does mention Mjölner in his example, but doing so he refers to attacking and triggering:
"
Back when Mjolnir was first implemented, if you had 1 or 3 lightning spells socketed for it to trigger, it would stop your attacks from alternating. You make a main-hand attack with Mjolnir, and lets say that attack has id 2. If it triggers 1 spell, that spell has id 3, and then when you go to attack again, that attack action gets id 4 - which is even, making it another main-hand attack. The same principle applies with 3 triggered spells because that's also an odd number of triggers happening.
This clarification may also be relevant for the trigger order we supposedly know about. As neither of those trigger conditions - attack, main hand, off-hand etc. - apply here, but simply damage taken thresholds being met, this could be relevant in breaking down performance optimizations for trigger builds.
If it currently tracks every single spell triggered as its own action with its own action ID, then you'd have SO MUCH MORE calculation steps to do, or so it appears, than having each CWDT/trigger setup assign their own action ID for each trigger event. Unless, of course, that is their way of tracking entities. I have no idea how this is done.
For example:
CWDT 1 triggers Spell A, B, C and D. CWDT 2 triggers Spell E, F, G and H. Each of those gets their own action ID. That's 8 separate IDs being assigned and tracked. Edit: Correction. That might actually be 10, if it treats CWDT as its own action.
I wanna know if that is the case and whether we can reduce that to simply 2 actions by making the entire CWDT setup a single action being taken. Get what I'm saying?
OR
CWDT 1 triggers Spell A, B, C and D. CWDT 2 triggers Spell E, F, G and H. That's 2 separate IDs being assigned and tracked.
I want to know whether their current implementation has any noticeable effects on performance. Because, if it does, sure sounds a lot better to have the game drastically reduce the calcs required. Currently, there's no PC on the market that we can buy that can run certain builds at a stable framerate. Doesn't matter if you have the latest hardware, the game engine will bottleneck you anyway.
You might have misunderstood mark there. When he mentioned mjölner, he clearly was mentioning the triggered spell skills, that's how you force the mjölner hand to be the one alternating the attack all the time, by having odd spells in there. CWDT is not a skill, the skills happening are the ones increasing the counter. Ex:
mjolner in mainhand.
using default attack id: 10, mainhand, mjolner hits.
triggered spell 1: id 11.
default attack id: 12, mainhand, mjolner hits.
same with 3 spells:
using default attack id: 10, mainhand, mjolner hits.
triggered spell 1: id 11.
triggered spell 1: id 12.
triggered spell 1: id 13.
default attack id: 14, mainhand, mjolner hits.
the fix was that all skills triggered from a source would add two instead of one to the id counter, so you would always add odd values to the counter, thus forcing alternation regardless of triggered skills:
using default attack id: 10, mainhand, mjolner hits.
triggered spell 1: id 12.
triggered spell 1: id 14.
triggered spell 1: id 16.
default attack id: 17, offhand, mjolner doesn't hit.
default attack id: 18, mainhand, mjolner hits.
That's it. In regards to your question about CWDT, following Mark's explanation, each spell would get their own ID, in the order in which they are triggered, and since they don't have a "source", they would only increase the counter by one.
"
such as things triggered by Cast on Stun (or Unseen Blade, but it didn't exist yet), had no need to do this - they were a new, independent action, so used up 1 action id like any other
However, after the triggerbots change, all triggered skills increase the counter by 2, so each spell from cwdt would increase it by two.
"
I want to know whether their current implementation has any noticeable effects on performance. Because, if it does, sure sounds a lot better to have the game drastically reduce the calcs required.
Also, you seem confused about what the server does. You say that tracking each spell of cwdt would be too taxing, but that's clearly already what the game does, and waaay more that that, since it needs to have separate identifiers to know which instance of each skill does what. For example, for shotgunning prevention the game already tracks separately each triggered "projectile skill". If for whatever reason you have a mod that gives you something every time you kill with a fire skill, you need to track separately each instance of each triggered spell. This is something expected of game engines tbh.
In summary, the server does a looot more than simply generating an ID for each instance of a skill use, for multiple purposes.
Last edited by fushuan#5703 on Feb 23, 2026, 11:01:14 AM
|
Posted byfushuan#5703on Feb 23, 2026, 11:00:15 AM
|
"
So after my latest set of investigations, I can confirm there is a bug, although it's not what a lot of people have claimed it is.
A lot of misinformation has been floating around about Unseen Strike, and several times people have reported things that are correct behaviour to me as being bugs.
The wiki used to claim that it always attacked with the main hand. This is not and has never been correct.
The wiki currently claims that it "locks in" one hand to use each time you gain phasing. That is not and has never been correct (and gaining/losing phasing does not itself have any influence on the hand chosen).
However, it is possible to engineer specific circumstances that would look like either of those behaviours, at least for a while.
The original design intent, for obvious thematic reasons, was that the triggered skill would attack with the Hidden Blade weapon. That weapon is literally the hidden blade that strikes out unexpectedly, represented by the triggered skill. But it has never actually worked that way. Right from the initial implementation, it has alternated hands if dual wielding - not because of any specific implementation in the skill, but because that's default behaviour for all attacks, and the skill has never had any override to that behaviour. While it had not been the original intent, and is thematically dubious, this behaviour was kept - a decision made before the item was ever released. There are comments in the original implementation ticket noting this behaviour and its consequences, both in terms of allowing the Unseen Strike skill to cause on-hit effects specific to the other weapon (such as Mjolnir) and allowing it benefit from weapons with high damage but low attack speed. The unique item, and the skill, were balanced around this behaviour before being released in 3.12.0.
However, alternating does not necessarily mean that each trigger of the skill will use a different hand from the previous trigger of the skill - the alternation occurs over all skills of the character, not just this one. Each action the character does gets a unique action id, which is 1 higher than the previous action's id. Attack actions that don't implement some more complicated handling for dual wielding simply check if their id is even or odd to determine whether that action uses the main or off hand. This means that whether a given trigger of Unseen Strike uses the same hand as the previous trigger, or the other hand, depends on how many actions the character does between the two. This has always been the case since before the item & skill went live, and is still true today.
Unfortunately that is not the end of the story. Technically-minded readers are no-doubt already composing replies pointing out that using action ids this way has a flaw when one attack that should alternate triggers another skill, and indeed this was once the case. Back when Mjolnir was first implemented, if you had 1 or 3 lightning spells socketed for it to trigger, it would stop your attacks from alternating. You make a main-hand attack with Mjolnir, and lets say that attack has id 2. If it triggers 1 spell, that spell has id 3, and then when you go to attack again, that attack action gets id 4 - which is even, making it another main-hand attack. The same principle applies with 3 triggered spells because that's also an odd number of triggers happening. That effect was real and was used by some players to trigger Mjolnir more while benefiting from global stats on an off-hand weapon that didn't get used. Even if moving around and doing other things made one of your attacks get an odd id, that wouldn't trigger anything, so it would alternate back to even on the next attack to restart the "every-attack-uses-Mjolnir" train. This was fixed back in 3.7.0 - a long time before Hidden Blade was even thought of - by having skills that are triggered from another action you perform cause an extra action id to be consumed, so that trigger didn't change whether the next action id would be even or odd. In contrast, triggered skills that were triggered from outside of the skills you were directly performing, such as things triggered by Cast on Stun (or Unseen Blade, but it didn't exist yet), had no need to do this - they were a new, independent action, so used up 1 action id like any other, and fit into the character's general alternation of hands.
This system worked well for a long time, both before and after the release of The Hidden Blade and its Unseen Strike skill. But was complicated in 3.21.0 by the release of Summon Triggerbots, which intercepted an event of triggering a spell to make it trigger twice instead, which of course messed with the number of ids consumed. This was quickly noticed and fixed in 3.21.1 - the patch note specifically mentioned Poet's Pen because that's what it was noticed with, but the bug and fix technically affected all triggered skills. However, that fix had an unintended consequence, which made all triggered skills, not just those being triggered from other skills, now consume an extra action id. This affected Unseen Strike, changing it from the correct behaviour, where it would alternate hands if an even number of actions (including zero) happened between triggers, and the same one otherwise, to the reverse - so if you do no other actions, Unseen Strike no longer alternates.
So Unseen Strike changing hands or using the same hand as the previous trigger is dependent on how many actions the character performs between triggers, as it always has been, but currently it is alternating for an odd number of other actions and keeping the same hand for an even number (including zero), when it should be the reverse. During frantic gameplay, where the character is doing a lot of things very quickly, the number of actions performed between triggers is fairly arbitrary and this is likely to be hard to distinguish from the correct behaviour for most players - especially when moving around, because when one move action transitions into the next - and thus how many action ids are used running around the place - depends on a bunch of internal factors. But in specific circumstances where the character is not doing much or anything else - such as when a player is trying to test this behaviour - it becomes easier to distinguish. A character doing nothing but triggering Unseen Strike will see it always use the same hand until they do another action, at which point it will swap to using the other hand, and this is clearly different from what it should be doing in that case, which is alternating with each trigger.
We are currently internally assessing the ways this bug could be fixed and what else might be impacted by doing so, and potential other improvements to Unseen Strike's handedness.
Great writeup, thanks for the insight.
I feel like the spirit of the dw skills is that they should alternate weapons per use, regardless of how many other skills you are using in between, so I would propose storing a boolean/bit in every skill that could alternate hands (so all attack to be sure), and changing the value in memory every time the skill is used. This is the safest choice in regards to bugs since nothing but the skill would modify the "state" of the skill, but it increases memory use and idk how taxing updating these values per skill use is in the context of PoE attack skill uses. You already are increasing a "skill ID" value every skill use, not just attacks, so I feel like the proposal has its worth.
The biggest issue probably as always is the time required to do such rewrite in code so I'm sure that whatever y'all choose will be best.
GL with the fix.
|
Posted byfushuan#5703on Feb 23, 2026, 11:04:43 AM
|
