SC2Mapster Forums

Resources > Trigger Libraries & Scripts

Dr. Debug, a debugging tool for triggers

  • 20 posts
    #1 Jan 19, 2013 at 20:57 UTC - 0 likes


    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:

    http://vicdepository.webs.com/drdebug.jpg

    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.

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

    WORKS BEST ON
    Malfunctioning triggers that do not display an error.
    Player dependent bugs.
    Non-visual triggers.

    LEARN THE LIMITATIONS
    The tool was initially catered for me only until now. Here is a list of things you must be aware of until later updates address it://<<<139905690398664>>> 1. You can only input 999 string variables until it errors. It is currently NOT recommended for constant usage during public games as it will bug up after it passes the 999th variable.
    2. It cannot use Text values, so player names in particular CANNOT be used as well as the other text values.

    I assume everyone will have a work around for these?

    Download here

    Last edited Jan 24, 2013 by Vicboy
    #2 Jan 23, 2013 at 18:59 UTC - 0 likes

    Hey man
    Thanks for this debugger. its simple but very useful.

    I came across a pretty big bug when I added this to my map.

    The debugger itself was working and logged all the events... but it caused all the triggers I added it to become unstable
    (they were previously working without any issue)

    Whatever triggers i added the action "Tell Dr. Debug" the rest of the trigger seemed to be ignored...
    (but it was random... sometimes it would do the rest and sometimes it wouldn't...)

    As soon as we disabled Dr.Debugger, everything is working again.

    I'm not sure if you know what would cause this.

    Last edited Jan 23, 2013 by JosinJJ
    #3 Jan 23, 2013 at 20:23 UTC - 0 likes

    @JosinJJ: Go

    Huh. Hmm, can you show me what string values you fed Tell Dr. Debug?

    Also, it's required that Hire Dr. Debug is the first trigger with Map Init event on it. (Assuming you've planted Tell Dr. Debug in Map Init event triggers.)

    EDIT:

    Just in case anyone's wondering, I'm not so much of a good programmer (Hence why I needed this damn debugger in the first place).

    Also, another thing, since Tell Dr. Debug is an action definition, if it errors in its process, it'll skip the remaining triggers.

    EDIT:

    Here's a possible fix: In Trigger Editor, select Tell Dr. Debug, select Options: Action and check Create Thread.

    EDIT:

    Also, the recording limit is currently 999. I can imagine that, after 999 records, it'll stop working. I guess there's more to work on for this tool.

    Last edited Jan 23, 2013 by Vicboy
    #4 Jan 23, 2013 at 20:51 UTC - 0 likes

    Tell Dr. Debug((Combine (("Player " + (String((Owner of (Triggering unit))))), "'s CC has died")))
    ^ this one was one of the ones I isolated to be causing the problem, there are 3 strings in a combine multiple.
    (all strings, not text)

    Not sure why it would cause an error in the action...

    I didn't realize that if an action errors it will skip the rest of the trigger
    That sounds like it could be the issue, ill try the threading option like you suggested (Thanks)

    Does the 999 sting cap mean that the debugger will start erroring on every call of tell dr debug once you pass it?
    If so then this could be the reason that it was not working

    Last edited Jan 23, 2013 by JosinJJ
    #5 Jan 23, 2013 at 21:28 UTC - 0 likes

    @Vicboy: Go

    This is kinda pointless and may add more instability to your map by having it in there.

    All it is doing is creating a dialog to place debug messages in.


    To properly debug

    1. set the map not to ignore errors
    2. use text out put messages to check your values
    3. use text out put messages to signal the entry and exit of an action or thread
    4. use text out put messages to check results after a process is done
    5. use the built in trigger debugger that runs externally to sc2 , this can be used while online but you gotta start sc2 from the editor and leave the debug window up.
    6. worst case scenario you can write to a local file all your debug statements.

    to avoid multiplayer errors. Always write your code to assume that it is going to be handling multiple players.

    Last edited Jan 23, 2013 by SouLCarveRR

    Skype
    KageNinpo = SN

    My Libraries
    DialogLeaderboard & TeamSort

    My Projects
    SPACEWAR Tribute
    Infinite TD

    #6 Jan 23, 2013 at 21:40 UTC - 0 likes

    @SouLCarveRR: Go

    It's not pointless at all, and all the alternatives you've provided below are not convenient. Also, you only need to plant this on bugged up triggers, then remove it when finished.

    All it is doing is being a flexible ready-to-microwave tool that allows you to precisely find out what's wrong in real time and using a friendly interface.

    Reasons why I disagree:

    1. What about the triggers that do not put out errors?
    2. It fades out soon enough, you cannot copy the error and you are limited by a string length limit.
    3. It fades out soon enough, you cannot copy the error and you are limited by a string length limit.
    4. It fades out soon enough, you cannot copy the error and you are limited by a string length limit.
    5. No customization and not specialized.
    6. Do you mean banks? Why not real time?

    To avoid multiplayer errors? You'll never avoid that. It's not that easy. Once a game gets really big, shit starts to break down. Not even the big game companies can avoid this, even with their final releases. My playerbase are always finding new ways to fuck up my game.

    Last edited Jan 23, 2013 by Vicboy
    #7 Jan 23, 2013 at 22:08 UTC - 0 likes

    u should make this an asset instead of have it in a thread

    #8 Jan 23, 2013 at 22:13 UTC - 0 likes

    @xXdRaGoNrIdDeRXx: Go

    Okay, I'm not sure what the difference is tho.

    #9 Jan 23, 2013 at 22:19 UTC - 0 likes
    Quote from SouLCarveRR: Go

    @Vicboy: Go set the map not to ignore errors

    Does that hide the warnings?
    The game itself doesn't show trigger errors ingame anymore which I dislike.

    I experimented with showing the debug window at the start of the game. That works to some degree, but throws a warning at the start of the map, if you are in fullscreen and it can potentially destroy the game, with players using windowed mode and their debugger showing each event.

    Best solution I can imagine would be an error message thrown about the trigger error and a way to open the debugger in replays. (With the debugging action, the debugger will start in the replay...)

    @topic
    I looked at it and it seemed like a nice tool. Its only real competitor is the debug message.

    When I was searching for the performance eater in my map during 1.5 arcade beta, I created a few small functions that might be interesting for your debugging tool:
    - Check which threads are running by incrementing an integer in an array at start and decrementing it before the thread ends (-> normal ending & skip remaining actions). Each thread had its own integer. Then I had a function that could return a list of the running threads and their integer values.
    - output the amount of units on the map
    - output the amount of data table entries
    - actions to clear death models, clear particles. I had more that could remove most things on the map including actors, portraits, dialogs and effects, but I don't think that would be good to add.

    http://img42.imageshack.us/img42/7586/signaturemj.jpg

    #10 Jan 23, 2013 at 22:29 UTC - 0 likes
    Quote from Vicboy: Go

    @xXdRaGoNrIdDeRXx: Go

    Okay, I'm not sure what the difference is tho.

    it will make it easier to find

    #11 Jan 24, 2013 at 00:24 UTC - 0 likes

    So I think what was happening was:

    After 999 outputs the "Tell Dr. Debug" action was throwing an error due to going beyond the size of the string array.
    This caused whatever trigger had called Dr. Debug to fail.

    So I removed the string array variable and the edit box function.
    I increased the width of the dialogs to 800 so that longer messages can still be read.
    (this should work for me since i really don't need to copy text from the edit box)

    #12 Jan 24, 2013 at 02:38 UTC - 0 likes

    Okay, I plan to implement several more things, an option to use Text values, an option to make the text copyable, and an Accountant for Dr. Debug who'll be counting anything integer.

    #13 Jan 24, 2013 at 04:11 UTC - 0 likes

    here's a version of dr. debug i whipped up that has a max array size of 205,000. The selection portion might get a bit shaky if you make it out that far, but i haven't had reason to. It's the original thing with just a bigger array.

    Last edited Jan 24, 2013 by willuwontu
    Name Size MD5
    Dr._Debug_expanded.SC2Map 30.1 KiB e188b5a821c5...

    I'm a triggerer
    I can't make awesome terrains
    I dabble in data

    I suck at poems
    That is why i do haiku
    i suck at them too :(

    #14 Jan 24, 2013 at 05:28 UTC - 0 likes

    @willuwontu: Go

    Lol wontu.

    EDIT:

    On a serious note, isn't it memory consuming to have that much arrays even if they're empty.

    Last edited Jan 24, 2013 by Vicboy
    #15 Jan 24, 2013 at 07:08 UTC - 0 likes

    yes it is, but you can also decrease the size by decreasing the array. But if you do modify the array just be sure to modify the tell the dr. and select list item triggers accordingly.

    #16 Jan 24, 2013 at 11:53 UTC - 0 likes

    @SouLCarveRR: Go

    Oh, I didn't realize there were built in debug triggers. But it still sucks. But not to worry! I'll use the action where you can save it as a text file. Hmm... is this even multiplayer compatible? How do you even pick which players get the file.

    #17 Jan 24, 2013 at 12:55 UTC - 0 likes

    This library has been added to the category list as unapproved. You can get it approved by tweaking this post in accordance with the Submission Guidelines. Have a nice day.

    My Projects:
    Malum Ruina: SC2Mapster
    Eternal Exile: SC2Mapster
    Spine Crawler Madness: SC2Mapster
    Xeno Crisis: SC2Mapster

    #18 Jan 24, 2013 at 14:24 UTC - 0 likes

    @Vicboy: Go

    I think it saves for all players, though I've never tested them in multiplayer. It saves to "StarCraft II\UserLogs\MapName".

    Send me a PM with any questions or comments.

    Learn about HotS mods, publishing, and regions here

    #19 Jan 24, 2013 at 16:56 UTC - 0 likes

    make it so you click a button to save the file vic, and then save it to a bank for the triggering player.

    #20 Jun 04, 2013 at 12:26 UTC - 0 likes

    Is anyone interested in seeing this improve in functionality?

  • 20 posts

You must login to post a comment. Don't have an account? Register to get one!