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:
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.
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.
Extracting the report.
WORKS BEST ON
Malfunctioning triggers that do not display an error.
Player dependent bugs.
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?
Triggers not working properly? Get a check up from Dr. Debug!
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.
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.)
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.
Here's a possible fix: In Trigger Editor, select Tell Dr. Debug, select Options: Action and check Create Thread.
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.
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
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
to avoid multiplayer errors. Always write your code to assume that it is going to be handling multiple players.
KageNinpo = SN
DialogLeaderboard & TeamSort
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:
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.
u should make this an asset instead of have it in a thread
A Rogue's Story
Death Haven V2
Diablo 3 Waypoint
Diablo 3 UI Tutorial
Okay, I'm not sure what the difference is tho.
Quote from SouLCarveRR: Go@Vicboy: Go
set the map not to ignore errors
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...)
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.
Quote from Vicboy: Go@xXdRaGoNrIdDeRXx: Go
Okay, I'm not sure what the difference is tho.
it will make it easier to find
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)
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.
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.
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 :(
On a serious note, isn't it memory consuming to have that much arrays even if they're empty.
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.
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.
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.
Malum Ruina: SC2Mapster
Eternal Exile: SC2Mapster
Spine Crawler Madness: SC2Mapster
Xeno Crisis: SC2Mapster
I think it saves for all players, though I've never tested them in multiplayer. It saves to "StarCraft II\UserLogs\MapName".
make it so you click a button to save the file vic, and then save it to a bank for the triggering player.
Is anyone interested in seeing this improve in functionality?
You must login to post a comment. Don't have an account? Register to get one!