Hi Spinky, here are some answers to your questions:
- It’s cheaper to have a global rule with a condition that checks if the Host Player is doing something rather than using Ongoing - Each Player with a condition that compares against the Host Player. The latter is checking 12 things (one for each player) instead of just 1 thing.
- I haven’t measured it, but it probably doesn’t make much difference whether you use a global variable or Host Player. I’d recommend the latter since you don’t have to worry about updating a variable that way.
- If you know the duration of the Wait in advance, and if it’s fairly long (that is, more than a few frames), then using a Wait and a Loop is better than using a condition since a condition just notices that it has a continuously-changing value and, seeing that it does, performs a check every frame. However, if you are going to be checking every frame anyway (or almost every frame), then a condition is cheaper since you don’t have the overhead of executing actions in order to perform your check. (This overhead has been reduced significantly in 1.45, but it’s still present.) As for scalability, your best bet is to perform the check in a single rule and set a variable that the other rules are listening for (since this variable won’t be changing continuously, and thus the conditions listening for it are asleep until the variable changes). Of course, if each rule requires an independent timer, then the variable trick won’t work.
- There’s almost no difference between your examples in terms of performance since both methods take advantage of short circuiting (that is, not evaluating the second condition if the first is false). I’d encourage using the first way since it’s easier to read. (Side note: There was some disagreement earlier between me and Zach regarding whether conditions have short circuiting. I’ve confirmed today that they do. Zach was right!)
- Yes, Workshop uses short circuiting in conditions, the And value, and the Or value.
- Reevaluation generally occurs when something in the value is changing. For values that change continuously or could change continuously (such as positions), this causes reevaluation of the entire value to occur every frame. If the array you’re filtering has anything in it that continuously changes (either the array itself or the condition you’re using) then that might get expensive. Filtering an array of all players with a player variable as the condition, however, will not be considered continuous unless the variable is continuous (which it would be if it were being chased). Such a value would cause reevaluation only when players are added or removed or when your variable changes. For that reason, you probably don’t need a global variable that maintains a filtered copy of All Players unless you have many places where you’re making the same Filtered Array check (though what counts as “many” would need to be measured – I’m just saying there’s a cutoff at some point where maintaining a global variable is cheaper).
Good luck optimizing your scripts! I forgot to mention the Disable Inspector Recording action in my post above – use it when your script starts up to gain some efficiency back, and then use Enable Inspector Recording to debug specific problem areas.