Intro
My banks weren't working. I've read the triggers a hundred times and still found it logically sound. No errors were popping out so I started to assume Blizzard had glitches within its editor. Boy, was I wrong.

It wasn't easy to detect the source of the bug mainly because it's all in the backstage of the game. It's not a process you see while playing your game. And you don't know what values are being outputted. You don't know if a certain action was run or left out.

From my experience, single player debugging is like cleaning up the map. You find this and that bug, then you simply fix it.
Multiplayer debugging is a whole new thing. You're not just a janitor, you'll also have to be a detective.

Then I thought, if I could see what was happening in the backstage, I'd probably figure out the bug, rather than trying to fix something blindly. (Kind of like banging the TV until it worked rather than opening it up to fix it)

So, I introduce to you, the mapmaker's latest weapon against debugging:

Dr. Debug
It improved my debugging and detecting experience... By a long shot.

My banks for my game is now working 100%, so stats are always saving and saving correctly. I thought my logic in triggering was sound, but Dr. Debug proved me wrong several times.

I think this screenshot of a multiplayer game will say how exactly it works:

You only need to use two actions to utilize Dr. Debug.

Hire Dr. Debug to create all the necessary components of Dr. Debug and Tell Dr. Debug which contains a string input/parameter for you to describe what happened in trigger.

Examples:

        Player Group - Pick each player in (Active Players) and do (Actions)
                Bank - Open bank "TheThing" for player (Picked player)
                Tell Dr. Debug((Combine ("Stats - ", "Player ", (String((Picked player))), " bank is opened.")))

It's pretty flexible, in my opinion.

You could also have to describe what is happening and what values are being played around, step by step.

        Tell Dr. Debug((Combine ("Stats - ", "Player ", (String(PlayerLocalized)), " compiled a savecode: ", string)))
        Variable - Set string = (EncryptString(string))
        Tell Dr. Debug((Combine ("Stats - ", "Player ", (String(PlayerLocalized)), " encrypted a savecode: ", string)))
        Bank - Store string string as "0" of section "0" in bank ThingBank[PlayerLocalized]
        Tell Dr. Debug((Combine ("Stats - ", "Player ", (String(PlayerLocalized)), " stored savecode to bank file: ", (Load key "0" of section "0" from bank ThingBank[PlayerLocalized] as a String))))
        Bank - Save bank ThingBank[PlayerLocalized]
        Tell Dr. Debug((Combine ("Stats - ", "Player ", (String(PlayerLocalized)), " has his bank file saved.")))

Now aside from its main feature which is to report what is happening, it's also a pretty convenient tool.

It is capable of:

Logging and reporting at real time.
Opening and hiding at command.
Moving the window around.
Changing size.
Extracting the report.

It works best on:
Malfunctioning triggers that do not display an error.
Player dependent bugs.
Non-visual triggers.

Unfortunately there are some limitations. (I can imagine that most of these can be fixed in future versions, but this tool was only catered to me until now)

There are two disadvantages of allowing the ability to extract the report:
1. You cannot extract the report without it being a string, thus you cannot convert text to string, therefore you cannot use text variables/values, only strings variables/values.
2. Because you have to store every report as a string variable, the array size I chose is 999, which means you can only extract the first 999 reports.

I assume everyone will have a work around for this?