|
Post by ryanfenton on May 2, 2017 17:36:08 GMT
When any opponent is removed (killed) during gameplay, there appears to be a synchronization issue with the line:
if (targets == null || targets.TargetTransform == null)
...which is at line 770 of the latest Unity updated version of ProCamera2d.cs, in the function GetTargetsWeightedMidPoint.
Basically, the size is of the Targets List<> changing between the start of the loop, and this line, which happens to be the first use of the targets list triggers an exception when that happens.
I was able to 'fix' it by adding a line:
if (totalTargets != targets.Count) break;
so it looks like this:
for (int i = 0; i < totalTargets; i++) { if (totalTargets != targets.Count) break; if (targets[i] == null || targets[i].TargetTransform == null) { targets.RemoveAt(i); continue; } ... But that's just kind of a bandaid fix, not fully addressing the larger fact that The size of Targets can change in the middle of this code as deeply as perhaps needed with this hacky check/bail line.
In any case, if it helps, that at least allows the demo to run a bit more consistently. Before this line, I was having this demo freeze in the UI around half the time I was killing an enemy, which decreased the size of the list, throwing off the indexing in this code (which was usually in that loop at that moment), resulting in an Out of Range exception.
Ryan Fenton
|
|
|
Post by ryanfenton on May 2, 2017 17:48:07 GMT
Ah, looks like a simpler fix:
for (int i = 0; i < targets.Count; i++) { if (targets[i] == null || targets[i].TargetTransform == null) { targets.RemoveAt(i); continue; }
Just get rid of totalTargets, and index on targets.Count - then the indexing would very rarely get out of pace. The performance loss from doing the List.Count check isn't worth worrying about in context, compared to any synchronization fixes you'd need to do on the other side of the logic. From testing, I haven't encountered any size mismatches with this fix.
Ryan Fenton
|
|
|
Post by ryanfenton on May 2, 2017 18:31:41 GMT
Incidentally, the systems I'm running on are Windows 10. I've seen these same out-of-range exceptions for several months, whenever I went back to anything that removed targets, like the third room of the TopDownShooter example.
If you've never encountered this bug, likely Unity on Windows is doing some extra parellel processing, which may be why targets gets updated in sync with this check on some systems, but inconsistently when I'm testing. Can't tell from my end.
Ryan Fenton
|
|
|
Post by Luís Pedro Fonseca on May 2, 2017 21:26:45 GMT
Thanks for posting this Ryan!
Although it was never reported before (after almost 2 years and hundreds of customers) I can see why it could happen. My guess is that something has recently changed on the Windows Unity version that made this possible.
Any how, your fix makes total sense and will be part of the next release (v2.4.2).
Cheers!
|
|