 |
DanteX
Apprentice
Joined: 13 Aug 2007
Posts: 166
|
 Posted: Sat Nov 14, 2009 11:26 am
[3.12] Debugger message displaying
|
I'm using the debugger to try track down some problems... but I'm not finding it as helpful as I wish it could be.
This e.g. doesn't say me anything in the end about what changed
0.0025 | k Aardwolf | [459] Var "SpellupVar" changed from "AliasSoon|LastCast=Self|SaffSpell=mental b..." to "AliasSoon|LastCast=Self|SaffSpell=mental b..."
When "SpellupVar" is a DB-variable.
So when using #ADDKEY somewhere.. please make it display the CHANGE only and not try displaying the entier variable, because as you can see... it results in not displaying anything useful.
Can you make it display the LOCATION of the variable also being read also?
e.g. Var "root/Spellup/SpellupVar" changed from "..." to "..."
Maybe also do the same with variables being read...?
Another BIG problem I have with the debugger, is when I try to reduce WHAT is being displayed...
For that, I use the tree that's available, with the checkboxes... I uncheck a class... THE ENTIER DEBUGGER STOPS for that window (the map capture window continues).
This is really not the way it should be imo... Or?
DanteX |
|
|
|
|
orphean
Apprentice
Joined: 21 Oct 2008
Posts: 147
Location: Olympia, WA
|
Posted: Sat Nov 14, 2009 5:43 pm Re: [3.12] Debugger message displaying
|
| DanteX wrote: |
| So when using #ADDKEY somewhere.. please make it display the CHANGE only and not try displaying the entier variable, because as you can see... it results in not displaying anything useful. |
Use #debug for stuff like this. It prints whatever you want to the debugger window. Put a '#debug New key/val pair added to myDBVar: %key %val' (or whatever your variables are) right before the #addkey.
| DanteX wrote: |
| e.g. Var "root/Spellup/SpellupVar" changed from "..." to "..." |
You probably should clarify what you want it to do since 'from ... to ...' doesn't make much sense.
| DanteX wrote: |
Another BIG problem I have with the debugger, is when I try to reduce WHAT is being displayed...
For that, I use the tree that's available, with the checkboxes... I uncheck a class... THE ENTIER DEBUGGER STOPS for that window (the map capture window continues).
This is really not the way it should be imo... Or? |
I can't reproduce this behavior. |
|
|
|
|
DanteX
Apprentice
Joined: 13 Aug 2007
Posts: 166
|
Posted: Sat Nov 14, 2009 6:04 pm
|
Dude.
I am trying to make this zmud session work properly in CMUD:
Zmud stats: 1270 Aliases, 2343 Triggers, 106 Macros, 1081 Vars
Please don't tell me to go through all of them and add something like that #debug thing manually, because the whole point of the debugger is ruined if it's not handy to use, if I needed to do everything like this manually, I'd stick to zMUD, not pay for CMUD, and do debugging like I always have with the #SHOW command everywhere.
If you look at the third line, I pasted a line that displays a variable, where it says exacly that - changed from "content before change" to "content after change". And as you can see there, it displays exacly the same thing. Why? Becuase it's a database variable, and displaying nonsense instead of the change of a variable is to me nonsense.
If it helps you to reproduce the stopping of the debugger, I can tell you that apart from the main window connected to the mud, I have 7 capture windows and the map opened.
One of those capture windows is ASCII-map capturing. If I choose in the list to the left to exclude any class, the debugger stops totally. But as I move around, I can see it process the captured map but in the window "maps" instead of "Aardwolf" (the map shows up in the debugger). |
|
|
|
|
DanteX
Apprentice
Joined: 13 Aug 2007
Posts: 166
|
Posted: Sat Nov 14, 2009 6:06 pm
|
Oh, and after importing my session to CMUD from zMUD, I have created a new one and transferred the converted stuff there, because I had problems there... Just wanted to clarify I'm not on a converted-from-zmud session.
|
|
|
|
|
orphean
Apprentice
Joined: 21 Oct 2008
Posts: 147
Location: Olympia, WA
|
Posted: Sat Nov 14, 2009 7:35 pm
|
I play on Aardwolf and have 10 capture windows and the map open and can't reproduce this </smug> 
Yeah the debugger window is poorly suited for MASSIVE PACKAGES (dear god man!). Having more fine grained control would be pretty much essential. For variables, maybe Zugg could add in a Variable Watch window that tracks changes like 'real debuggers' have. I'd like the treelist to be able to expand to each individual trigger/alias/whatever and allow you to toggle it on or off individually to track. |
|
|
|
|
DanteX
Apprentice
Joined: 13 Aug 2007
Posts: 166
|
Posted: Sat Nov 14, 2009 7:42 pm
|
Oh dear God... what wrong with me and all my sessions?! I seem to get into promblems that few or no one other gets... dunno whether to laugh or cry, lol
That would be really handy to have yes. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Nov 16, 2009 5:26 pm
|
| Quote: |
| Zmud stats: 1270 Aliases, 2343 Triggers, 106 Macros, 1081 Vars |
You've got to be kidding me, right? Yes, with a package of that size and complexity you are bound to have problems that nobody else in the world will have, along with all sorts of script interactions, instabilities, and problems. CMUD is not zMUD. CMUD is a rewritten MUD client that attempts to be as compatible with zMUD as possible. But zMUD had lots of scripting and parsing issues that were fixed or improved in CMUD. With that many scripts, your chances of having stuff left-over from how zMUD did things wrong is very high. The Compatibility Report in CMUD can help find some of those changes, but not all of them.
I just can't imagine how slow your MUD playing must be with such a huge package.
As far as the debugger, it does the best that it can. The "Show Variable changes" message fires when a variable is changed and the new value is written to the internal database. Database variables don't show up on this because they are hash tables and are changed at a lower level and then cached. They are not written to the database until needed because to write them to the database (or to even Print their value in the debugger window) requires converting the hash table to a string value, which is a very slow operation.
The debugger will *never* show you something when any variable is "read". What you are asking for would bring the debugger and the MUD session to a crawl. The debugger is already slow enough. I'm not going to add features that nobody would use because they are so obscure and just make it impossible to debug because it's too slow.
Finally, if you are use to using #SHOW to debug in zMUD, how is that any different from using #DEBUG in CMUD? #DEBUG is even better because it doesn't interfere with your normal MUD output, which could mess up your triggers in zMUD.
The bottom line is that debugging any package of that huge size is going to be a very time-consuming task no matter what you do and no matter what features I would add. |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
