I am surprised and disappointed, though the second is none of your fault.
Surprised by the matter of fact that there’s next to no extremely common mistakes like way too aggressive looping (I take this back, RIP to those Projectile Creations) or overblown complexity inside said loop.
Though from the amount of loops there are that’s still quite rough.
Disappointed due to the lack of Pathfinding Solution, the mention of PvE / AI peaked my interest, but I was let down.
From the short look I had at some of the existing loops I’d say that this is a script that buckles due to the sheer amount of HUD Creation / Destruction Events, unless I missed some other glaring issue, while not impossible due to the quality of the script that does exist I’m in doubt of though.
As a whole I’d argue that making use of HUD Evaluation would be a significant improvement compared to the sometimes Frequent other times less creation of Identical HUD elements that’s happening.
But chains like this are a decent example nonetheless
"0% COOLDOWN"
Create Progress Bar HUD Text(Event Player, 0, Custom String("– FORCE PUSH –"), Left, 200, Color(Red), Color(Red),
Visible To Values and Color, Default Visibility);
Event Player.TextId[40] = Last Text ID;
Wait(0.600, Ignore Condition);
Destroy Progress Bar HUD Text(Event Player.TextId[40]);
"10% COOLDOWN"
Create Progress Bar HUD Text(Event Player, 10, Custom String("– FORCE PUSH –"), Left, 200, Color(Red), Color(Red),
Visible To Values and Color, Default Visibility);
Event Player.TextId[41] = Last Text ID;
Wait(0.600, Ignore Condition);
Destroy Progress Bar HUD Text(Event Player.TextId[41]);
"20% COOLDOWN"
Create Progress Bar HUD Text(Event Player, 20, Custom String("– FORCE PUSH –"), Left, 200, Color(Red), Color(Red),
Visible To Values and Color, Default Visibility);
Event Player.TextId[42] = Last Text ID;
Wait(0.600, Ignore Condition);
Destroy Progress Bar HUD Text(Event Player.TextId[42]);
"30% COOLDOWN"
Create Progress Bar HUD Text(Event Player, 30, Custom String("– FORCE PUSH –"), Left, 200, Color(Red), Color(Red),
Visible To Values and Color, Default Visibility);
Event Player.TextId[43] = Last Text ID;
Wait(0.600, Ignore Condition);
Destroy Progress Bar HUD Text(Event Player.TextId[43]);
"40% COOLDOWN"
Create Progress Bar HUD Text(Event Player, 40, Custom String("– FORCE PUSH –"), Left, 200, Color(Orange), Color(Orange),
Visible To Values and Color, Default Visibility);
Event Player.TextId[44] = Last Text ID;
Wait(0.600, Ignore Condition);
Destroy Progress Bar HUD Text(Event Player.TextId[44]);
"50% COOLDOWN"
Create Progress Bar HUD Text(Event Player, 50, Custom String("– FORCE PUSH –"), Left, 200, Color(Orange), Color(Orange),
Visible To Values and Color, Default Visibility);
Event Player.TextId[45] = Last Text ID;
Wait(0.600, Ignore Condition);
Destroy Progress Bar HUD Text(Event Player.TextId[45]);
"60% COOLDOWN"
Create Progress Bar HUD Text(Event Player, 60, Custom String("– FORCE PUSH –"), Left, 200, Color(Orange), Color(Orange),
Visible To Values and Color, Default Visibility);
Event Player.TextId[46] = Last Text ID;
Wait(0.600, Ignore Condition);
Destroy Progress Bar HUD Text(Event Player.TextId[46]);
"70% COOLDOWN"
Create Progress Bar HUD Text(Event Player, 70, Custom String("– FORCE PUSH –"), Left, 200, Color(Yellow), Color(Yellow),
Visible To Values and Color, Default Visibility);
Event Player.TextId[47] = Last Text ID;
Wait(0.600, Ignore Condition);
Destroy Progress Bar HUD Text(Event Player.TextId[47]);
"80% COOLDOWN"
Create Progress Bar HUD Text(Event Player, 80, Custom String("– FORCE PUSH –"), Left, 200, Color(Yellow), Color(Yellow),
Visible To Values and Color, Default Visibility);
Event Player.TextId[48] = Last Text ID;
Wait(0.600, Ignore Condition);
Destroy Progress Bar HUD Text(Event Player.TextId[48]);
"90% COOLDOWN"
Create Progress Bar HUD Text(Event Player, 90, Custom String("– FORCE PUSH –"), Left, 200, Color(Yellow), Color(Yellow),
Visible To Values and Color, Default Visibility);
Event Player.TextId[49] = Last Text ID;
Wait(0.600, Ignore Condition);
Destroy Progress Bar HUD Text(Event Player.TextId[49]);
"100% COOLDOWN"
Create Progress Bar HUD Text(Event Player, 100, Custom String("– FORCE PUSH –"), Left, 200, Color(Green), Color(Green),
Visible To Values and Color, Default Visibility);
Event Player.TextId[50] = Last Text ID;
Could be entirely replaced by a single HUD creation, followed by a long wait for the entire Up-time to then Destroy, instead of the several Creation / Destructions per loop.
Create Progress Bar HUD Text(Event Player, 10 * Round To Integer((Total Time Elapsed - Evaluate Once(Total Time Elapsed) / 0.600), Down), Custom String(“– FORCE PUSH –”), Left, 200, Array(Color(Red), Color(Red), Color(Red), Color(Red), Color(Orange), Color(Orange), Color(Orange), Color(Yellow), Color(Yellow), Color(Yellow), Color(Green))[Round To Integer((Total Time Elapsed - Evaluate Once(Total Time Elapsed) / 0.600), Down)], Array(Color(Red), Color(Red), Color(Red), Color(Red), Color(Orange), Color(Orange), Color(Orange), Color(Yellow), Color(Yellow), Color(Yellow), Color(Green))[Round To Integer((Total Time Elapsed - Evaluate Once(Total Time Elapsed) / 0.600), Down)],
Visible To Values and Color, Default Visibility);
Incredibly crude, I’m aware, I just didn’t want to bother setting any Variable up for this as a matter of fact.
But it gets the point across, hopefully, you’ll want to leverage the client side more by having them Evaluate the HUD components instead of having the Server & Client be tasked with the frequent Creation & Destruction of elements.
Highly doubt that applying this on its own will already fully fix your Crashing woes, but it’s at least something that should help.
The only other questionable thing I came across in my short look was that Hero Setup stuff like the Ability Button availability & Stats were also looped, for Junkrat at least.
Admittedly didn’t look into it further so it might have a valid reason to do so, but under normal circumstances this just screams band-aid fix to temporary modifications that weren’t properly cleaned up.
Expand this to more than just the HUD’s but essentially anything that instead could leverage Re-evaluation instead of Rapid Logic re-application.
Mercy’s / Lifeweavers Ascension / Decension are another great example, instead of Starting the same Acceleration 20 times a second both could be a single Start that just fires as long as it should be available without either Button Input to instead move the Button input to the Evaluation of the Acceleration.
That or at the very least increase the wait to 0.1 with the Acceleration adjusted in its strength to accommodate for this change.
I’m also concerned that your last tests were just a fluke as Re-Evaluation shouldn’t be a Server side load thing at all.
Perhaps unknowingly the Players were also just not playing Heroes that have any of the more aggressive loops that also altered the outcome.