[2020] @Mark_GGG Questions about Return changes

The description of current behaviour in the manifesto was incorrect - some inaccuracies were introduced while trying to shorten it from the longer description Nick and I worked out for the patch notes.

Previously, projectiles could only move forward through the list of behaviours (with some exceptions for pierce because that's handled a bit differently - it has to intercept before the projectile is stopped, not react to it). If it hit a target and was currently in the "chain" behaviour, and had chains left, it would try to chain. If it failed to chain (due to no valid target), it would move on to return and do that. Because it moved on to the returning, it could no longer chain (the remaining chains were "wasted"). If it hit something while returning, it would already have

Now, it checks the full list of behaviours to see if any are left on each target, so in that situation it would return after failing to chain, and then when hitting something else on the way back, it would see that it has a remaining chain and do that.

It returns in both cases, the change is that previously moving on from chaining to returning was a one-way state change, where now it just has a list of things to try, and tries each one it hasn't used up in order until something works, for each target.

The rule is technically universal over all behaviours, but chain is the only one it can happen for in "normal" circumstances - Splitting, forking, and piercing can't "fail" like chain because they can all happen regardless of whether there's anything else in range - they don't have a requirement like that to fulfil. Also, both splitting and returning can only happen once. So the only non-chain cases where it really matters are where specific modifiers prevent one of the other behaviours from happening on a given target (e.g. a specific monster that can't be pierced for some reason), or for other, more obscure behaviours on specific skills.

No. This changes the order certain checks are done in, and the structre of the code around them. There is no signficant difference to performance, and what there is, would technically be expected to be an incredibly minor performance improvement, because it's actually doing less stuff now - it no longer has to set stuff to remember it can't chain again after failing.

Yes, if you have a source of returning that doesn't require hitting a target (in which case the pierce/fork would have happened on that target)