I have run into Too Many Threads errors recently (see http://www.sc2mapster.com/forums/development/triggers/25946-too-many-threads/) and it got me thinking about why sometimes when 5 players play my map, it crashes (due to Too Many Threads), and for others it doesn't (still with 5 players). Then I got to thinking: what machine is actually doing the processing for the map? The host? Is it distributed across all players' machines? Based on evidence found in replays, I started thinking that the error has to do not with an absolute number of threads running, but with the processing power available.
Does anyone know how processing is distributed to battle.net vs host vs other players in a multiplayer map?
I guess it works the same way as in sc 1. Every machine runs the game for itself and compares the data regulary.
At the same time the game is synced as commands only get executed by the game, if they receive the command from battle.net (these should be stored in replays), so every player will lag at the same time as one player lags and that explains the delay between ordering a unit to do something and the execution.
Let's say there are 3 players. I have a pulldown menu that appears onscreen for all players. I have a Trigger that runs some code when the pulldown selection is changed by any player.
Let's say I use some code in the Trigger Editor to Select Item 1 of Pulldown X for (All Players). I'm assuming this would launch the Trigger I mentioned above once for Player A, once for Player B, and once for Player C. I'm also assuming that every machine would be running all 3 of those threads, meaning we have a total of 9 threads running when considering all machines.
Can anyone correct those assumptions? If they are correct, does the system count this as 9 threads, or 3 threads?
Let's say there are 3 players. I have a pulldown menu that appears onscreen for all players. I have a Trigger that runs some code when the pulldown selection is changed by any player.
Let's say I use some code in the Trigger Editor to Select Item 1 of Pulldown X for (All Players). I'm assuming this would launch the Trigger I mentioned above once for Player A, once for Player B, and once for Player C. I'm also assuming that every machine would be running all 3 of those threads, meaning we have a total of 9 threads running when considering all machines.
Can anyone correct those assumptions? If they are correct, does the system count this as 9 threads, or 3 threads?
Is the selection made in the pulldown not synced for all players (so every player sees the current selection)?
Also, will a selection change trigger the event, if the selection was changed by a trigger action, because there was no human UI input?
I'm not used to display an interactive dialog to multiple players at the same time, so this might be wrong:
So I guess there would be 1 thread (the one that does the change with an action). If the action triggers the event (I guess it won't), there should be up to 15 additional threads because you can't just create dialog items that exist for a player only (you can only set visibility). Therefore it should trigger the event for every player active.
You could test this with a computer player, trigger debugger and triggers containing appropriate events and a wait, so they are visible in the debugger's thread tab.
My guess is that the server does all the behind-the-scenes work. I had a friend test my (laggy) AI, and when he tested it in single player he was lagged to death. But when I published and we both tested the same map in multiplayer (with even more bots than before) he ran perfectly fine.
Just my anecdote; could be more complex than that.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I have run into Too Many Threads errors recently (see http://www.sc2mapster.com/forums/development/triggers/25946-too-many-threads/) and it got me thinking about why sometimes when 5 players play my map, it crashes (due to Too Many Threads), and for others it doesn't (still with 5 players). Then I got to thinking: what machine is actually doing the processing for the map? The host? Is it distributed across all players' machines? Based on evidence found in replays, I started thinking that the error has to do not with an absolute number of threads running, but with the processing power available.
Does anyone know how processing is distributed to battle.net vs host vs other players in a multiplayer map?
@jcraigk: Go
I guess it works the same way as in sc 1. Every machine runs the game for itself and compares the data regulary.
At the same time the game is synced as commands only get executed by the game, if they receive the command from battle.net (these should be stored in replays), so every player will lag at the same time as one player lags and that explains the delay between ordering a unit to do something and the execution.
So in short: everyone is processing...
@Ahli634: Go
Okay, so how about this scenario:
Let's say there are 3 players. I have a pulldown menu that appears onscreen for all players. I have a Trigger that runs some code when the pulldown selection is changed by any player.
Let's say I use some code in the Trigger Editor to Select Item 1 of Pulldown X for (All Players). I'm assuming this would launch the Trigger I mentioned above once for Player A, once for Player B, and once for Player C. I'm also assuming that every machine would be running all 3 of those threads, meaning we have a total of 9 threads running when considering all machines.
Can anyone correct those assumptions? If they are correct, does the system count this as 9 threads, or 3 threads?
Is the selection made in the pulldown not synced for all players (so every player sees the current selection)?
Also, will a selection change trigger the event, if the selection was changed by a trigger action, because there was no human UI input?
I'm not used to display an interactive dialog to multiple players at the same time, so this might be wrong:
So I guess there would be 1 thread (the one that does the change with an action). If the action triggers the event (I guess it won't), there should be up to 15 additional threads because you can't just create dialog items that exist for a player only (you can only set visibility). Therefore it should trigger the event for every player active.
You could test this with a computer player, trigger debugger and triggers containing appropriate events and a wait, so they are visible in the debugger's thread tab.
My guess is that the server does all the behind-the-scenes work. I had a friend test my (laggy) AI, and when he tested it in single player he was lagged to death. But when I published and we both tested the same map in multiplayer (with even more bots than before) he ran perfectly fine.
Just my anecdote; could be more complex than that.