Display MoreYes.
There are a few things I would nitpick, though broadly speaking, that's correct, according to the suggestions I made above. These are the things I would nitpick:
- If I was in charge, the first things to be lined up against the wall when the revolution came would be unnamed altVals and flags. Spare a thought for poor future you having to make sense of your code, and name your flags.
- As I mentioned, I'd prefer to see Fusion's native forEach loops, not the old 3rd-party ForEach extension. The native version is likely to be more optimised, and perhaps more reliable. Having said that, if the extension works, and it's what you're used to, it's probably not doing any harm.
- I guess events #4 & #5 no longer belong in the group called "Loops", since they no longer are part of the fastloop.
- If you wanted, you could combine events #4 & #5 into a single event, using an Or (logical) condition
Considering all the above, this is how I would arrange the code:
In case you're unsure, this is how you create a native forEach loop. The action to start it is found in "count", here:
And the condition to demarcate the forEach loop's contents is found here:
There's another thing I want to point out from earlier, though it's no longer relevant to this particular code. Action #2 in the below event (Stop loop "Move") serves no purpose.
Action #1 in this event (Start loop "Move" [Velocity] times) will jump over to the fast loop called "Move", and will run it as many times as commanded (ie. whatever the integer value of Velocity is). That is, it will run all events in the entire frame that contain the condition on loop "Move" in them, as many times as necessary. Once it completes all the required loops of those fastloop events, it will come back to this event and continue on from Action #2. Action #2 tells Fusion to stop the fastloop, but by the time Fusion gets here, the fastloop has already run its full course, so is already stopped.
Aha. Ok, now that I see this event, I realise why you were using a fastloop. I should have clicked earlier.
So, earlier, I talked you into moving the bullets in one single go, rather than increment by increment. So if velocity was 8, it would move them by XVel x8, instead of by XVel x1...XVel x1...XVel x1...XVel x1...XVel x1...XVel x1...XVel x1...XVel x1. However, what I didn't see (but should have guessed) was that you were checking for collisions during this loop. Because your bullets are so fast, if you move a bullet the full Xvel x8, it might skip over an enemy entirely before you have a chance to do a collision check. Which is why you were doing a collision check every XVel x1 increment, to make sure that you caught any collisions that occurred in the middle of the bullet's journey, and not just those at the end.
So, my advice to get rid of the fastloop was actually bad advice. You probably do need to check in XVel x1 increments. However, the same problem that I identified in your events #5 & #6 (where you were performing 1152 checks per frame) is also present in this event #1329. And because overlap checks are relatively expensive, it's likely to have an even greater affect on your lag.
Because you didn't add a Fixed Value of Group.Bullet = LoopFV, "Move" condition to event #1329, it was continually checking whether any bullet had collided with an enemy, instead of just whether the currently fired bullet had collided. So, when the code performed the "move" fastloop for bullet 1, it would check whether bullets 1-12 collided with an enemy. If it ran the fastloop 8 times, it would perform those 12 checks 8 times. And then it would move onto bullet 2 and repeat the whole process again, and then 10 more times for the remaining 12 bullets. So it'd be checking for overlaps 12*8*12 = 1152 times per frame. What you want is for it to check for overlaps 12*8 = 96 times (8 increments for each of the 12 bullets). Still a lot, but much less than 1152.
Here's the crux of the issue: forEach loops scope, while fastloops do not. So, when you do this:
Event #3 inherits scope from event #2 (it will only affect bullets with Flag 1 off). But when it jumps off into the "Move" fastloop, the scoping is abandoned. When Fusion gets to this point:
...there's absolutely no scoping any more. It's a clean slate.
Luckily, you re-introduce scoping with this condition, which seems to be a mechanism that your ForEach extension uses for this purpose:
So these actions will only affect the scoped bullet:
But then the fastloop moves onto here, and again there is no more scoping, and it's a clean slate. So when you ask Fusion to check whether a bullet is overlapping an enemy, it has to check all the bullets:
So, here is how I would do the code, amending my above changes to reintroduce the fastloop. When Fusion's native forEach loops are combined with fastloops as below (with the fastloop being the topmost action - the forEach condition will no longer be green), the fastloop will keep the scoping of the forEach loop. I've called the fastloop "MoveByIncrement" so that it has a different name to the forEach loop, to avoid confusion.
Notice that I've changed the order of these two conditions in event #5, compared to how you had them:
That's because overlap checks are relatively expensive, so you want to minimise them where possible. If Velocity=8 and an enemy's HP is 1, and a bullet hits and kills that enemy in the very first loop of the fastloop, you don't need the code to check for that enemy's overlap and its HP seven more times. You also don't need the 11 other bullets from the same shotgun spread to keep triggering their own overlap checks for this enemy. Better that the event checks HP first, so it can avoid checking overlaps whenever an enemy is already dead.
The previous order would check for overlap on all enemies, and then check HP only for some enemies (ie. collided enemies). This order will check the HP of all enemies, and then check for overlap for most enemies (ie. alive enemies). The trade-off is that you'll be doing more HP checks, but potentially fewer overlap checks. Since HP checks are considerably cheaper, this should be a worthwhile trade-off.
Let me know how that goes.
Right, right! Now it's all coming together, thanks! Speaking of, before I showed you the collision/overlap events, I did try the prior version and seriously wondered why the bullets weren't registering hits half the time.
For context, I've tuned the events to pretty much exactly how you've suggested, and now here are what the shooting/colliding events look like:
Please login to see this attachment.
Please login to see this attachment.
(Excuse the event cutting off. It's pretty much the same event, but for when the bullet is overlapping the "Group.Targets", which are headshot hitboxes, causing the bullet to do more damage)