I am NOT asking about the 3 server load actions that exist in the workshop (Server Load, Avg, Peak)
What I’m asking is HOW the game processes the Rules. IF there’s a thread already about this plz paste the link, as i haven’t found anything specific to what I’m asking.
Would 100 Ongoing - Each Player Rules (Each with conditions that have to be met to execute) cause the same amout of load as, let’s say; 50 Ongoing - Each Player Rules & 50 Subroutine Rules. (the 50 Each Player rules have conditions, where as the Subroutine Rules don’t. & thus don’t execute until one of the Each Player rules Call for a Subroutine) Thus, the game isn’t checking for Pass/Fail conditions on those Subroutines.
TLDR;
I guess what i’m getting at is, does the Server have to process the Conditions of each rule every frame? & check to see if any are true?
Does this cause Load? Do “Conditions” require processing power? Are they checked Every frame?
OR
Is it only the “Actions Half” of the Rule that causes Load?
OR
Neither do. Simply the existence of the code it’s self (Total Element Count) that causes load?
Is the load dealt to the server SOLELY based on the Total Element Count? or HOW you wright the scripts?
I understand, to an extent, When & Why you’d use a Global rule vs. Each Player rule. & the benefit of the Subroutine. However, it’s fairly easy to alter a script to function the same in all three cases.
As I understand it, both conditions and actions increase server load (as well as anything that needs to be continuously reevaluated from the script [HUD texts, effects, camera, etc.] and anything non scripted that happens in the game [default hero abilities, healing and damage, deaths, objectives, and player movement] as well as the AI of the default AI bots that can be added in the lobby).
Conditions in ongoing rules are checked every single frame (there is short-circuiting so the order of conditions can make a difference).
(See this post by Dan Reed:)
As for actions, they can lead to server load peaks, though if they are simple actions such as changing a variable, you can run hundreds of them in a single frame without any problems. The problems may start if the same number of actions are run for every single player in a match with 12 players and at short intervals (loops with very short wait times greatly affect server load, in my experience).
I personally try to keep the number of ongoing rules (and especially ongoing - each player rules) and the number of conditions in these rules as low as possible. From my experience, subroutines have next to no impact on server load when they are not being called.
(I’ve posted a list of some general principles I try follow when writing workshop scripts in this thread: [Workshop Modes] Delwion's Workshop Modes [at the bottom of the first post].)
Looking at the behavior of WorkShop, I think there are the following factors.
(Because it is a guess, it may contain mistakes)
Rules
You know that the cost of a PlayerRule is equivalent to 12 Rules handlers.
You can carefully choose the number of rule handlers that actually work by adding team and hero conditions.
However, even with a lot of rule handlers, they themselves don’t put too much load on the server.
The amount of re-evaluation of the conditions set in the handler and the amount by which the action is triggered puts a load on the server.
Conditions
If the value set in Condition changes, the Condition expression is reevaluated to determine whether to trigger Action.
I think you’re monitoring changes in values based on the server’s tick rate,
But, the reevaluation of the Condition expression and its processing costs only occur if the value changes.
For example, PositonOf(Player) changes more often than IsDead(Player), so the Condition expression needs to be re-evaluated frequently, which increases the load on the server.
Actions, values, and their own costs
Getting internally pooled values and simple actions is low processing costs.
I think the above PositonOf() and IsDead() are of this kind.
What I know is NearestWalkablePosition() is processing cost is high enough to cause an overloaded shutdown of the server.
When these costly values are bound to a condition, unexpected overload shutdowns are repeated.
There may be values and actions with high processing costs other than NearestWalkablePosition() …
If don’t understand how server load works when dealing with large scripts,
We will suffer from many overload shutdowns and their debugging tasks.
I also want to understand correctly…
One option would be to create our own events and allowing us to do stuff depending on the tick rate or hosting our own dedictaed servers with a bit more processing power and better internally handled network infrastructure and lifetime managament of server/client memory. The other options we currently can do is do apply some stress reduction techniques, like working with states which means to store some values in variables and let rules evaluate with them, when they really change somewhere else, splitting bigger rules in some smaller ones or create subroutines and be really sure of your mode concept regarding how you go through Context hierachy is it really required to have a Player to Player Context, Player to Global and Player Context, Player to Global Context, Global Context to Player Context and Global Context or Global to Global Context, knowing how your script should process through the hierachy might optimize or keep the server load consistent.
Thanks for all the responses. It has helped me understand more about how the workshop works especially the link with Dan Reed. Something that has been mentioned a few times now, still confuses me.
From what I’ve learned using the workshop, a Rule will execute when the Condition evaluates to True (Assuming there IS a condition & there Isn’t a Loop). & won’t execute again until that condition becomes False, then True again. I’d imagine the Server still checks the condition every frame, but does Not repeat until True - False - True happens. Is this Not the case?
For example:
I have 5 Rules. (all are Ongoing - whatever) The server goes down the list 1-5 evaluating each Rule’s Condition(s) each frame. This repeats indefinitely.
At some point; Rule 2 becomes True & Executes action(s)
A) Is Rule 2 now Skipped/Marked/Flagged until the condition becomes False?
OR
B) The server still process the condition(s) for Rule 2, but because the condition still = True, nothing happens?
TLDR;
I guess it’s the word “Reevaluated” that’s confusing me. Because this gives me the impression that Server doesn’t not check the conditions unless something changes. However, How does it know something changed IF it’s not evaluating that condition each frame? & comparing said value…
Why is this important? With the addition of the While & Wait Until Actions. We can now have Conditions that are buried inside an action, and thus aren’t evaluated until the host action executes. So instead of a condition being checked every frame indefinitely while a game is running, it’s only checked for a short period of time once & IF the main action happens (Relatively speaking). This then can be linked to Subroutines & so on…
I apologize for the confusion.
but, the important thing is that the Condition is divided into the following two processing categories.
I) Monitor the change in the value referenced by Condition and determine if the formula needs to be recalculated.
Ⅱ) Actually recalculate the Condition formula and decide whether to execute the action.
My “Reevaluated” means Ⅱ).
For example, suppose the following expression is bound as a Condition.
“Distance Between (PlayerA, PlayerB) <= 5”
I) means that Player A or Player B move.
This should be monitored at the correct tick rate on the OW server side.
Otherwise, will not be able to respond in real time.
(It seems that UpdateEveryFrame () can make the supervision rate more strict)
This is always running in the background when loaded the script that created the expression in Condition.
Therefore, it does not increase the processing cost of the server at a specific timing.
Ⅱ) is the process of acquiring the coordinates of PlayerA and PlayerB and converting them into distances using the vector difference and trigonometry.
This II) occurs only when the above I) is detected.
To re-evaluate the Condition expression, resolve the referenced value to a number that is actually calculable.
At this timing, the processing cost of the server increases depending on the type and number of values to be resolved and the complexity of the conditional expression.
My understanding of this part is probably in line with your understanding.
The I) is always operates in the background.
However, in the case of the condition set by the action of WaitUntil (), monitoring can be performed only when this is executed.
Conditions in ongoing rules are checked every single frame
False.
Conditions with sporadically changing values, such as health or is crouching, are tied to an event and are only checked when the value changes. So if you have is crouching == true then the condition will only be checked when the player crouches or uncrouches.
Conditions with constantly changing values, such as position of, will be evaluated continuously, but most of the time not every frame (hence the updateEveryFrame() function). For example, position of updates every 12.5th of a second.