I've recently released a new map to the arcade, and every time I play it with people there are at least 1 or 2 players whose game crashes. I already know that I have a lot of triggers in the map, but they are all used for something (of course).
I ran a debug check, and I honestly don't know what to say about the results (check it out below). Have I got too many triggers?
P.S. On the picture the game has been running for about 5½ minutes.
First, as I can see, you have many events that fires for nothing. It's anormal that you have a trigger that runs 3200 times in 5.5 minutes. Keep in mind that a specific event is by far more efficient than a failed condition. You can see it with your picture that your event failed 3200 times with your conditions so you have lost a precious 55 seconds in engine time.
Second, I can't see your script, but have you put the least triggers possible? The worst thing you can do is to connect triggers together. If you put action definitions with while loops you could save a lot of time in your script.
Also variables with arrays are more efficient than single array variable. For example, x [10] takes less place than 10 x variables.
One last thing that I can say is that using graphics (create actors, moving units, etc.) takes more memory than pure calculation. Instead of ordering 10 times the same order at differents places, do the calculs and put 1 chain of 10 orders.
It's sure that with your script visible it could be easier to help you.
The crashing is most definitely not going to be related to trigger load. Even if you were getting infiniloops without waits (what's the technical name for that again?), it still wouldn't crash the game (but there would be a noticeable pause.)
Most likely, there's something specifically causing the crashes, in either data or triggers (or imports), unrelated to load. One possibility would be an unconventional standard UI hookup modification (afaik that's only start up).
Just to clarify, the crashes occur during the game, not at the start, right?
Yes exactly. The game crashes during gameplay (although I haven't experienced a crash, some of the other players have).
However, I just read through some posts about action definitions, functions and records. Some of them say that multiple global variables could overload the RAM and such (I don't know if that could cause a crash). After reading those posts I realized that my code is messed up and I use too many triggers for the same events (and maybe too many variables aswell), which I have to fix....
But what do you say about the import and the UI? I have imported some sound effects, button icons and two models, AND I have modified the UI a tiny bit. Could those things lead to a crash?
It's sure that my example is a bit extreme, but in my map I have a terrain generator that create actors. So instead of creating an actor at every point I need, I just set the desired height with a variable and then create the actors. With this I can avoid creating multiple actors at the same point, which is much harder for the system.
The secret of a good triggering is to have the less triggers, actions and variable as possible. You can also compare trigger as global variable and action definition as local variable.
The only goal of triggers is they are used to fire an event. Once the trigger runs, you should automaticly fire an action definition. If this action is not linked with another action, you should put the create thread option to make it runs alone. With this you will save a lot of time.
For global variable, you should only used them when it's absolutely necessary, like dialogs or a map grid. The reason why is simple : once the trigger is finished, all the local variable in it will be deleted, so you will free many space (especially if the trigger contains a lot of variable).
I think that I'll make a trigger for beginner thread soon to help people making nice script.
Alright, thanks for your replies. To be honest, I've never used a single action definition, function or a record (like ever), which means I have to revamp my trigger work completely and learn new and different techniques. I feel so stupid that I didn't even know that multiple triggers and global variables had an impact on the gameplay.
They wouldn't lead to a crash directly, and I've never heard of images/sounds being problematic. Certain models, however, can sometimes get funky and cause crashes (editor)/errors when saving. I've never heard of 'incompatible' models causing crashes in-game ([sprites] in SC1, sure, but that's not relevant).
Anyway, what's your UI modification? And information about the imported models could help. Unfortunately, there are lots of possible causes and you'll have to narrow it down. I'd grab a few volunteers, and test the map with different segments of the map removed, starting with imports, then triggers, then data. Once you find the module, more testing would be needed to narrow it down to the culprit. I had a similar problem (5% chance of crashing on load up), and I continued working on the map while narrowing it down to a standard hookup UI modification. Just saying, you don't need to halt progress.
No worries. I, too, once ignored action definitions, functions, and records. But once you begin implementing those things as a normal course of design, it's like
It's just simple UI stuff (rearrangements to be exact). I've not tried to modify the buttons or anything like that (simply because I don't know how to xD).
Looking at your trigger results specifically; their run times are not the problem. that time on the right is in MS, not seconds. .001 of a second. .055 seconds of run time in 5.5 minutes is nothing. Even added them all up your run time is ~400ms in 5.5 minutes.
While it is true, you can do a lot to improve your triggers, I do not think specifically that your triggers will be causing the lag.
If the crash is on startup, then it is most likely in your map init triggers. Players load at a different pace; so if player 1 has a super computer while player 2 has a few sticks and a rock; stuff may load differently for them, if you use triggers like "pick all players" for example. Player 2 may not be loaded into the basic game settings when player 1 is activating such things.
As a simple test; run all of your map init triggers after .2 seconds of game time have elapsed; and see if people still drop during the load.
The crashes only occur during gameplay. Startup is irrelevant.
Btw, you cannot just generalize the ms like that, as different computers have different clock speeds. I have an Intel i7 4770 processor, and that's why the ms numbers are small in the debug window. It would show very different numbers if this game was to run on a toaster.
Look at the picture below. I ran a debug check on my slow laptop. It's about 2½ minutes in game at that point.
Even on your toaster; you are looking at 800ms in 2.5 minutes. that is .8 seconds of lag in 150 seconds. You want to see "horrific" play some of the more popular games on the arcade, multiplayer, with the debugger open.
The debugger itself slows the game down considerably; so if your "toaster" can run the game with the debugger open, I doubt it is due to the "demand" from your triggers. If you have something coded poorly, it may be that specific thing. Say there is a set of rare scenarios that may line up and cause a multi-dimensional loop to run 1000 times over at once; someone with a weak computer may drop, while stronger computers survive. If you think your strong computer can handle it; play the game multiplayer until the problem occurs; having the debugger open. If it is trigger related; an error should show in the log; and if it is lag related, you should see the MS from a specific trigger spike.
units and pathing are the largest cause for lag in sc2; if you cannot pinpoint it as a trigger problem; those would be the things to look into.
test your game with the debugger open; then leave the game to return to the main window. you can then login to battle.net and do such from there; while the debgugger remains open. Downside? windowed mode. Upside? Debugger!
No, not yet. Right now I'm just struggling to revise my triggers, as I think they're part of the issue. I'll update this thread when I'm done (It might take weeks or months to revise the triggers btw).
Alright. I ran a debug while playing online, and here are my results. From what I can tell based on the picture is that the player crashes because of the amount of triggers I have. If that's not it, then it must be something in the data editor. Please tell me what you think.
Note: This is not an updated version of the map. The updated one is on my HDD right now (but not yet ready for release).
UPDATE: I've fixed a lot of triggers, but the game still crashes for some people.
I've recently released a new map to the arcade, and every time I play it with people there are at least 1 or 2 players whose game crashes. I already know that I have a lot of triggers in the map, but they are all used for something (of course).
I ran a debug check, and I honestly don't know what to say about the results (check it out below). Have I got too many triggers?
P.S. On the picture the game has been running for about 5½ minutes.
First, as I can see, you have many events that fires for nothing. It's anormal that you have a trigger that runs 3200 times in 5.5 minutes. Keep in mind that a specific event is by far more efficient than a failed condition. You can see it with your picture that your event failed 3200 times with your conditions so you have lost a precious 55 seconds in engine time.
Second, I can't see your script, but have you put the least triggers possible? The worst thing you can do is to connect triggers together. If you put action definitions with while loops you could save a lot of time in your script.
Also variables with arrays are more efficient than single array variable. For example, x [10] takes less place than 10 x variables.
One last thing that I can say is that using graphics (create actors, moving units, etc.) takes more memory than pure calculation. Instead of ordering 10 times the same order at differents places, do the calculs and put 1 chain of 10 orders.
It's sure that with your script visible it could be easier to help you.
@tatatatate: Go
Thanks for your reply. Do you mean the actual script or the triggers I've set up? Btw, I always use arrays for my variables.
What do you mean by that exactly?
@TheLazzoro: Go
The crashing is most definitely not going to be related to trigger load. Even if you were getting infiniloops without waits (what's the technical name for that again?), it still wouldn't crash the game (but there would be a noticeable pause.)
Most likely, there's something specifically causing the crashes, in either data or triggers (or imports), unrelated to load. One possibility would be an unconventional standard UI hookup modification (afaik that's only start up).
Just to clarify, the crashes occur during the game, not at the start, right?
@Charysmatic: Go
Yes exactly. The game crashes during gameplay (although I haven't experienced a crash, some of the other players have).
However, I just read through some posts about action definitions, functions and records. Some of them say that multiple global variables could overload the RAM and such (I don't know if that could cause a crash). After reading those posts I realized that my code is messed up and I use too many triggers for the same events (and maybe too many variables aswell), which I have to fix....
But what do you say about the import and the UI? I have imported some sound effects, button icons and two models, AND I have modified the UI a tiny bit. Could those things lead to a crash?
@TheLazzoro: Go
It's sure that my example is a bit extreme, but in my map I have a terrain generator that create actors. So instead of creating an actor at every point I need, I just set the desired height with a variable and then create the actors. With this I can avoid creating multiple actors at the same point, which is much harder for the system.
The secret of a good triggering is to have the less triggers, actions and variable as possible. You can also compare trigger as global variable and action definition as local variable.
The only goal of triggers is they are used to fire an event. Once the trigger runs, you should automaticly fire an action definition. If this action is not linked with another action, you should put the create thread option to make it runs alone. With this you will save a lot of time.
For global variable, you should only used them when it's absolutely necessary, like dialogs or a map grid. The reason why is simple : once the trigger is finished, all the local variable in it will be deleted, so you will free many space (especially if the trigger contains a lot of variable).
I think that I'll make a trigger for beginner thread soon to help people making nice script.
Alright, thanks for your replies. To be honest, I've never used a single action definition, function or a record (like ever), which means I have to revamp my trigger work completely and learn new and different techniques. I feel so stupid that I didn't even know that multiple triggers and global variables had an impact on the gameplay.
@TheLazzoro: Go
They wouldn't lead to a crash directly, and I've never heard of images/sounds being problematic. Certain models, however, can sometimes get funky and cause crashes (editor)/errors when saving. I've never heard of 'incompatible' models causing crashes in-game ([sprites] in SC1, sure, but that's not relevant).
Anyway, what's your UI modification? And information about the imported models could help. Unfortunately, there are lots of possible causes and you'll have to narrow it down. I'd grab a few volunteers, and test the map with different segments of the map removed, starting with imports, then triggers, then data. Once you find the module, more testing would be needed to narrow it down to the culprit. I had a similar problem (5% chance of crashing on load up), and I continued working on the map while narrowing it down to a standard hookup UI modification. Just saying, you don't need to halt progress.
No worries. I, too, once ignored action definitions, functions, and records. But once you begin implementing those things as a normal course of design, it's like
@Charysmatic: Go
It's just simple UI stuff (rearrangements to be exact). I've not tried to modify the buttons or anything like that (simply because I don't know how to xD).
EDIT: btw, the imported models are not in use.
@Charysmatic: Go
Creep is very frustrating sometimes. I started a creep generator and it crashes like 1 time on 3.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumLooking at your trigger results specifically; their run times are not the problem. that time on the right is in MS, not seconds. .001 of a second. .055 seconds of run time in 5.5 minutes is nothing. Even added them all up your run time is ~400ms in 5.5 minutes.
While it is true, you can do a lot to improve your triggers, I do not think specifically that your triggers will be causing the lag.
If the crash is on startup, then it is most likely in your map init triggers. Players load at a different pace; so if player 1 has a super computer while player 2 has a few sticks and a rock; stuff may load differently for them, if you use triggers like "pick all players" for example. Player 2 may not be loaded into the basic game settings when player 1 is activating such things.
As a simple test; run all of your map init triggers after .2 seconds of game time have elapsed; and see if people still drop during the load.
Skype: [email protected] Current Project: Custom Hero Arena! US: battlenet:://starcraft/map/1/263274 EU: battlenet:://starcraft/map/2/186418
@GlornII: Go
The crashes only occur during gameplay. Startup is irrelevant.
Btw, you cannot just generalize the ms like that, as different computers have different clock speeds. I have an Intel i7 4770 processor, and that's why the ms numbers are small in the debug window. It would show very different numbers if this game was to run on a toaster.
Look at the picture below. I ran a debug check on my slow laptop. It's about 2½ minutes in game at that point.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumEven on your toaster; you are looking at 800ms in 2.5 minutes. that is .8 seconds of lag in 150 seconds. You want to see "horrific" play some of the more popular games on the arcade, multiplayer, with the debugger open.
The debugger itself slows the game down considerably; so if your "toaster" can run the game with the debugger open, I doubt it is due to the "demand" from your triggers. If you have something coded poorly, it may be that specific thing. Say there is a set of rare scenarios that may line up and cause a multi-dimensional loop to run 1000 times over at once; someone with a weak computer may drop, while stronger computers survive. If you think your strong computer can handle it; play the game multiplayer until the problem occurs; having the debugger open. If it is trigger related; an error should show in the log; and if it is lag related, you should see the MS from a specific trigger spike.
units and pathing are the largest cause for lag in sc2; if you cannot pinpoint it as a trigger problem; those would be the things to look into.
Skype: [email protected] Current Project: Custom Hero Arena! US: battlenet:://starcraft/map/1/263274 EU: battlenet:://starcraft/map/2/186418
@GlornII: Go
How do I run the game online with the debug window?
-
View User Profile
-
View Posts
-
Send Message
Curse Premiumtest your game with the debugger open; then leave the game to return to the main window. you can then login to battle.net and do such from there; while the debgugger remains open. Downside? windowed mode. Upside? Debugger!
Skype: [email protected] Current Project: Custom Hero Arena! US: battlenet:://starcraft/map/1/263274 EU: battlenet:://starcraft/map/2/186418
@GlornII: Go
Ahh, thx :D
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumJust as a follow up; have you figured out what was causing the lag issue?
Skype: [email protected] Current Project: Custom Hero Arena! US: battlenet:://starcraft/map/1/263274 EU: battlenet:://starcraft/map/2/186418
@GlornII: Go
No, not yet. Right now I'm just struggling to revise my triggers, as I think they're part of the issue. I'll update this thread when I'm done (It might take weeks or months to revise the triggers btw).
Alright. I ran a debug while playing online, and here are my results. From what I can tell based on the picture is that the player crashes because of the amount of triggers I have. If that's not it, then it must be something in the data editor. Please tell me what you think.
Note: This is not an updated version of the map. The updated one is on my HDD right now (but not yet ready for release).
UPDATE: I've fixed a lot of triggers, but the game still crashes for some people.