[Crash] The game crashes with an error during the loading screen

[Teo_omant]

With one of the updates to my map, the game began to periodically crash with an error during the loading screen. Exactly at the moment when the picture should appear, but it does not have time to appear.
What I've already been able to do:
I have no custom loading screen.

• Removed the initialization event from all triggers, added an event to them from at least 1.00 of the game. - didnt help
• I checked the entire object editor for the presence of bugged stings. There was one windwalk, I deleted it. - didnt help
• We tested with friend on different slots and on different graphics. - didnt help

Critical crashes are ALWAYS completely random. It's just impossible to track them. A game can crash 5 times in a row, or 10 games in a row can be fine.
The error code is different every time, just a random set of numbers.
The only clue so far is this code in the crash log:

(war3mapimported\MyTextArea.fdf//85) Error, cannot find frame "EscMenuCheckBoxTemplate" for "QuestCheckBox" to inherit from!

But that doesn't make any sense. The fdf file takes standard frames and these variables are not used at all in this fdf file (attach). Complains about line 85 when there are 23 in it!
I paid attention to this because it is in almost every crash log.

I just don't have any ideas left. The previous version is not left separately for me to test by gradually migrating the data.

I just don't have any idea how to track down something that happens randomly and can't be triggered on its own. I've been puzzling over this for 3 days, please help me.

 

[PurgeandFire]

Could you attach a few of the crash logs and attach the war3mapImported/MyTextArea.fdf file?

We don't have a lot to go off on, but if it is suggesting an issue with MyTextArea.fdf then it may make sense to try to delete the file and not use it in your triggers to see if that resolves the crash.

• We tested with friend on different slots and on different graphics. - didnt help

Just to be sure, your friend was experiencing the crash as well, right?

 

[Teo_omant]

Just to be sure, your friend was experiencing the crash as well, right?

My friend didn't crash out once. But this is not just a problem for me. Other players are crashing too. Constantly.

I can't attach a fdf file.

IncludeFile "UI\FrameDef\UI\EscMenuTemplates.fdf",
IncludeFile "UI\FrameDef\UI\QuestDialog.fdf",

Frame "TEXTAREA" "MyTextArea" {
DecorateFileNames,
FrameFont "InfoPanelTextFont", 0.020, "",

TextAreaLineHeight 0.018, //Should fit used font Size, a high difference shows no text or much space between lines.

TextAreaLineGap 0.00, //adds that much space between 2 Lines, addtional to TextAreaLineHeight.

TextAreaInset 0.035, //Moves the Text and the scrollbar into the middle from all sides by this amount. This increases the min size for game crash.

TextAreaMaxLines 20, //Only that amount of lines are displayed, if more lines are added oldest are removed.

TextAreaScrollBar "MyTextAreaScrollBar",
Frame "SCROLLBAR" "MyTextAreaScrollBar" INHERITS WITHCHILDREN "EscMenuScrollBarTemplate" {
}

ControlBackdrop "MyTextAreaBackdrop",
Frame "BACKDROP" "MyTextAreaBackdrop" INHERITS "QuestButtonBaseTemplate" {
}
}

 

[PurgeandFire]

Definitely seems to be an error with loading the FDF files. The reason it may show line 85 as the error (even though your file is not very long) is because of the IncludeFile "..." expressions--that will import that entire file into your FDF file. So it ends up becoming the length of EscMenuTemplates.fdf + the length of QuestDialog.fdf + the length of your file.

I'm guessing you are following this tutorial:

UI: TEXTAREA the scrolling Text Frame

Introduction TEXTAREA is a frame to display scrollable text. Normaly TextAreas have a BACKDROP showing a box and a Background. TextAreas require a scrollbar. The scrollbar is at the right side of the TextArea and blocks a part of the space given to the TextArea. If the TextArea is big enough to...

www.hiveworkshop.com

One of the details is that the files get loaded on initialization, e.g.:

function InitTrig_Create_MyTextArea takes nothing returns nothing
    call BlzLoadTOCFile( "war3mapImported\\MyTextArea.toc" ) // Here
    call TimerStart(CreateTimer(), 0.0, false, function CreateMyTextArea)
endfunction

It might be worth commenting out those lines as well, just to narrow down the crash. Anything in InitTrig_ will get executed on initialization (in the loading screen). So I would try commenting it out like so:

function InitTrig_Create_MyTextArea takes nothing returns nothing
    // call BlzLoadTOCFile( "war3mapImported\\MyTextArea.toc" ) // Here
    // call TimerStart(CreateTimer(), 0.0, false, function CreateMyTextArea)
endfunction

Once you narrow down the crash to a particular trigger/file, we can take a look a bit closer! I'm not super familiar with the new capabilities with FDF files, but hopefully we'll find something out.

 

[Teo_omant]

I'll try, but I don't believe it's because of the fdf file. It loads in any case after a 1.00 from the start of the game.

 

[Teo_omant]

Definitely seems to be an error with loading the FDF files. The reason it may show line 85 as the error (even though your file is not very long) is because of the IncludeFile "..." expressions--that will import that entire file into your FDF file. So it ends up becoming the length of EscMenuTemplates.fdf + the length of QuestDialog.fdf + the length of your file.

I'm guessing you are following this tutorial:

UI: TEXTAREA the scrolling Text Frame

Introduction TEXTAREA is a frame to display scrollable text. Normaly TextAreas have a BACKDROP showing a box and a Background. TextAreas require a scrollbar. The scrollbar is at the right side of the TextArea and blocks a part of the space given to the TextArea. If the TextArea is big enough to...

www.hiveworkshop.com

One of the details is that the files get loaded on initialization, e.g.:

function InitTrig_Create_MyTextArea takes nothing returns nothing
    call BlzLoadTOCFile( "war3mapImported\\MyTextArea.toc" ) // Here
    call TimerStart(CreateTimer(), 0.0, false, function CreateMyTextArea)
endfunction

It might be worth commenting out those lines as well, just to narrow down the crash. Anything in InitTrig_ will get executed on initialization (in the loading screen). So I would try commenting it out like so:

function InitTrig_Create_MyTextArea takes nothing returns nothing
    // call BlzLoadTOCFile( "war3mapImported\\MyTextArea.toc" ) // Here
    // call TimerStart(CreateTimer(), 0.0, false, function CreateMyTextArea)
endfunction

Once you narrow down the crash to a particular trigger/file, we can take a look a bit closer! I'm not super familiar with the new capabilities with FDF files, but hopefully we'll find something out.

It didn't help. Crashes remained.
I checked my very old logs. They also have this fdf error, but there were crashes of a completely different and were fixed.

 

[PurgeandFire]

Bummer.

The logs don't seem to be very informative on the crash then. Sadly, debugging from this point-on is usually brute force. Here are some techniques:

1. Bisecting -- if you have several versions of your map, e.g. version 1 ... version 40, then you could quickly find the version that introduced the crash by jumping around. For example, assuming version 1 does not crash and version 40 crashes, then you would start at version 20 --> test it. If it crashes, then you can just focus on versions 1 through 20 (and repeat this process). Else, you can focus on versions 20 through 40 (and repeat). This is only helpful if you have a lot of backups of your map, though--or if you're using git.

2. Full ogre (make a backup of your map before you do this -- store it in the hive's pastebin or something) -- The first step is to ask: is a trigger causing the crash? Or is it some imported resource? (or worst-case, some combination) This sounds silly, but the first thing to do is to disable every trigger in your map and see if it crashes. If it crashes, then you know it has nothing to do with your triggers and you should just focus on the other parts of your map. If it doesn't crash, then you know it is likely caused by triggers and you can start brute forcing that even more.

If it is caused by triggers, then there's several approaches you can take. One is to just look at all the triggers you've added since your last stable version and disable them all. That'll help you isolate where the problem is. You'll want to repeat this process of narrowing it down as much as you can.

If it is not caused by triggers, then you'll want to delete all the imports you can, test, and repeat. Then you can try deleting other things, like custom objects, all the units on the map, cameras, regions, etc. Again, the goal would be to narrow down the problem to (hopefully) one part of your map.

 

[Teo_omant]

Well, I conducted more than 150 tests in multiplayer from two computers. What i found out:

The chance of desync about 7%. Perhaps it increases with the number of more players. Most crashes were during the loading screen.

The rest during initialization and after 0.00 of the game.
In the second case, by debug, I found the reason for the desync - these are frames. I had one large library that was loaded at one time, I divided it into 5 small ones and now create frame sequential. I didn't get any more desync on this one.

But crashes during the loading screen still happening.

 

[Teo_omant]

An important addition: The host has the greatest chance of crashing.

Upd. There is desync: no OE, no import. Without triggers, I couldn't get a desync, but maybe I was just lucky. All initialization is disabled (including triggers after 0.0 and frames) - there is a desync (NOTHING HAPPENS IN THE MAP AT ALL). What else I tried: I found an old version that didn't crashed. I moved all the editor's data there from the current one, the crashes appeared, so it's not about the map itself, but somewhere inside the data.

It doesn't make sense. There is no logic. The game is terrible. I hate blizzard. The cry of the soul. I think desync is interlinked with something else besides triggers.

 

[Teo_omant]

I found the problem. The TriggerRegisterPlayerEvent() and with bj function called when creating a trigger at the start of the game results in desync. I assigned mouse and keyboard events after 0.00 - crashes stopped.