[Crash] My map crashed, I don't know why. How should i go about this?

[vlekje5]

Hello everyone, so during a testing phase using the custom game and not the WE test function, my map randomly kicked me out. I was playing singleplayer in a private game but since it's reforged it was still online. I didn't get a disconect box but instead just went straight to scoreboard.

The map i have is quite big and uses alot of custom triggers, though most are done in GUI. I have no idea what caused the crash, but i'm quite scared for playtests with 24 people. it's mostly heavy on the trigger side of things. The base map i edited had quite alot of triggers, and i added some major systems to that. (save/load, alternative modes and some custom spells) Is there a hard cap after which your map keeps crashing? I noticed that my game started lagging a bit before the crash which is worrying if there are going to be 24 ppl playing at once. As far as i know the original map was quite laggy lategame but didnt crash that often.

What would be the best way to go about fixing crashes? Does anyone here have experience with that? Should i just rewrite all of my triggers to make sure theyre completely leak free? i Did just make a new spell that might leak but i'd be suprised if that caused it since i only used it a few times and i was not in the game for that long when it crashed.

Is there perhaps any tool to detect crashes or leaks in your code? or do i have to manually look for that needle in the haybatch?

 

[Planetary]

It doesn't sound like a crash. Going straight to the scoreboard is usually a sign of a desync unless you are using very shoddy triggers.

You'll have to post your triggers or map to get suggestions.

Are you using any extra fast triggers? (less than 0.03 sec)

 

[vlekje5]

It doesn't sound like a crash. Going straight to the scoreboard is usually a sign of a desync unless you are using very shoddy triggers.

You'll have to post your triggers or map to get suggestions.

Are you using any extra fast triggers? (less than 0.03 sec)

Yes, one of the custom abilities i was testing uses a fast trigger. Not 0.03 but close (0.04) This is part of a custom spell i mostly imported And i was playing as the hero that has that spell when the crash occured.

Is there any big difference between desyncs and crashes? I have yet to properly make my triggers leakproof since i want to do that all at once (i'm still fairly bad at recognizing when a trigger leaks) I do have some location based spells that don't have the remove location fix yet.

I'll post the map however, it's still kind of messy since there are some models not yet imported and i disabled some of the triggers from the original version which i know were lagg inducing like the income system.

The fast trigger is the meathook one i imported. It's in the rebens triggers > pullerhero > spell map.
The only thing i changed in this trigger from the original is that i made it turn of unit collisions while a unit is being pulled.
Most of the triggers in my map are not properly tested for leaks yet. And i don't know how leakproof the original triggers are.

would highering the tick rate to say 0.10 sec or even 0.05-0.06 sec make it significantly harder to desync?

 

[Planetary]

Yes, one of the custom abilities i was testing uses a fast trigger. Not 0.03 but close (0.04) This is part of a custom spell i mostly imported And i was playing as the hero that has that spell when the crash occured.

Is there any big difference between desyncs and crashes? I have yet to properly make my triggers leakproof since i want to do that all at once (i'm still fairly bad at recognizing when a trigger leaks) I do have some location based spells that don't have the remove location fix yet.

I'll post the map however, it's still kind of messy since there are some models not yet imported and i disabled some of the triggers from the original version which i know were lagg inducing like the income system.

The fast trigger is the meathook one i imported. It's in the rebens triggers > pullerhero > spell map.
The only thing i changed in this trigger from the original is that i made it turn of unit collisions while a unit is being pulled.
Most of the triggers in my map are not properly tested for leaks yet. And i don't know how leakproof the original triggers are.

would highering the tick rate to say 0.10 sec or even 0.05-0.06 sec make it significantly harder to desync?

Anything that is .03 sec or slower should be fine. It'd be anything faster such as a .01 sec timer that I've seen cause desyncs for other users.

I'll see if I can spot anything in the map script that stands out. The only thing I noticed is you said single player: I'm not sure if Reforged would allow a desync with 1 player in the match but knowing how Deforged has been, could be the case.

 

[Planetary]

Alright, I had a look through.

Unfortunately, the triggers are too messy and uncategorized and have too much going on to do any deep dive that will be meaningful.

However, I do see a host of issues:

1) Leaks, lots of them. There are a ton of events that use locations for example (e.g. Run Event) which is probably going to cause issues in a 24-player match. I'd definitely look into cleaning them up Memory Leaks.

2) Overloaded with wait steps that are going to reference the wrong objects. I would prioritize this as the first thing to look into. There's a bit more info here so I don't have to re-type it all on why wait steps can lead to broken code, including an example: MUI Triggers with Waits

e.g.:

• Items aqquired
  • Events
    • Unit - A unit Acquires an item
  • Conditions
    • Or - Any (Conditions) are true
      • Conditions
        • (Item-type of (Item being manipulated)) Equal to |cffd45e19Head |rof the |cffff0000SIEGEBREAKER|r
        • (Item-type of (Item being manipulated)) Equal to |cff6f2583CLAW|r of the |cffff0000SIEGEBREAKER|r
        • (Item-type of (Item being manipulated)) Equal to |cff008000Heart|r of the |cffff0000SIEGEBREAKER|r
        • (Item-type of (Item being manipulated)) Equal to |cff00ff00Eye|r of the |cffff0000SIEGEBREAKER|r
        • (Item-type of (Item being manipulated)) Equal to |cff808080Leg|r of the |cffff0000SIEGEBREAKER|r
        • (Item-type of (Item being manipulated)) Equal to |cffffff00Soul|r of the |cffff0000SIEGEBREAKER|r
  • Actions
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • And - All (Conditions) are true
          • Conditions
            • (Race of (Owner of (Hero manipulating item))) Equal to Undead
            • And - All (Conditions) are true
              • Conditions
                • ((Item carried by (Hero manipulating item) of type |cff008000Heart|r of the |cffff0000SIEGEBREAKER|r) is owned) Equal to True
                • ((Item carried by (Hero manipulating item) of type |cff6f2583CLAW|r of the |cffff0000SIEGEBREAKER|r) is owned) Equal to True
                • ((Item carried by (Hero manipulating item) of type |cffd45e19Head |rof the |cffff0000SIEGEBREAKER|r) is owned) Equal to True
                • ((Item carried by (Hero manipulating item) of type |cffffff00Soul|r of the |cffff0000SIEGEBREAKER|r) is owned) Equal to True
                • ((Item carried by (Hero manipulating item) of type |cff00ff00Eye|r of the |cffff0000SIEGEBREAKER|r) is owned) Equal to True
                • ((Item carried by (Hero manipulating item) of type |cff808080Leg|r of the |cffff0000SIEGEBREAKER|r) is owned) Equal to True
      • Then - Actions
        • Game - Display to (All players) for 15.00 seconds the text: THE SIEGEBREAKER IS...
        • Item - Remove (Item carried by (Hero manipulating item) of type |cff008000Heart|r of the |cffff0000SIEGEBREAKER|r)
        • Item - Remove (Item carried by (Hero manipulating item) of type |cff6f2583CLAW|r of the |cffff0000SIEGEBREAKER|r)
        • Item - Remove (Item carried by (Hero manipulating item) of type |cffd45e19Head |rof the |cffff0000SIEGEBREAKER|r)
        • Item - Remove (Item carried by (Hero manipulating item) of type |cff808080Leg|r of the |cffff0000SIEGEBREAKER|r)
        • Item - Remove (Item carried by (Hero manipulating item) of type |cff00ff00Eye|r of the |cffff0000SIEGEBREAKER|r)
        • Item - Remove (Item carried by (Hero manipulating item) of type |cffffff00Soul|r of the |cffff0000SIEGEBREAKER|r)
        • Unit - Replace Shrine of Nezzreth 0123 <gen> with a Shrine of Nezzreth ACTIVE using The old unit's relative life and mana
        • Unit - Move (Hero manipulating item) instantly to (Center of Region 002 <gen>)
        • Unit - Make (Hero manipulating item) Invulnerable
        • Unit - Pause (Hero manipulating item)
        • Wait 10.00 game-time seconds
        • Unit - Make (Hero manipulating item) Vulnerable
        • Unit - Unpause (Hero manipulating item)
        • Unit - Replace (Hero manipulating item) with a SIEGEBREAKER using The old unit's relative life and mana
        • Game - Display to (All players) for 15.00 seconds the text: THE SIEGEBREAKER HA...
        • Trigger - Turn off (This trigger)
      • Else - Actions

 

[vlekje5]

1) Leaks, lots of them. There are a ton of events that use locations for example (e.g. Run Event) which is probably going to cause issues in a 24-player match. I'd definitely look into cleaning them up Memory Leaks.

I feared as much, i guess i'll start off by fixing all my location based triggers for leaks first trigger by trigger.

 

[vlekje5]

2) Overloaded with wait steps that are going to reference the wrong objects. I would prioritize this as the first thing to look into. There's a bit more info here so I don't have to re-type it all on why wait steps can lead to broken code, including an example: MUI Triggers with Waits

About this part, i've generally heard somewhere that waits are bad so i tried to avoid them a bit. Anyway i've read through the article you linked. The main problem seems to be that waits are MUI unfriendly. Meaning that if it's fired twice during a time the trigger breaks. Anyhow. This particular trigger only fires when a player accuires 5 different items. The catch is that each item gets auto removed from the store once acquired so hypothetically there should only be one of each in the game at any point. Meaning that the trigger can only be fired off once per game. Since only one player can have all 5 items and the second someone does have all 5, the items get removed from the game completely before the wait starts.

I have also used waits in a hero spell. However that shouldnt be able to cause the MUI problem eighter since there can only be one hero of each type in the game, and the spell cooldown is quite a bit longer than the wait (300 seconds to 0.75 second long wait or something).


I hope my reasoning is right here
Anyway i'll focus on fixing some of the location leaks first hopefully without breaking the triggers