@bhorton: Thanks for the continued testing - I'll be looking into this next. By the way, the array variables values displayed by the debugger are just indices to the actual data. Presently, RuDE doesn't support string or array variables.
Update: It seems the problem with the debugger screen is not just in menu mode 1002 but any menu mode.
The loop problem happens in 'while' loops as well.
Also the variable data displayed for arrays is not correct (it does not actually show any true data just garbage as far as I can tell).
other than these problems the debugger works well and I am using it when I can. To be honest I would like to endorse this but the three issues I have come across make it hard too (especially the loop issue). Will endorse if the issues are resolved.
@bhorton22: I'm not sure if that's expected behaviour (I haven't touched RuDE's code in over a year) but I'll look into it. Thanks for testing the plugin
I have started using this DeBugger and I am having a couple of problems: 1) If I set a break point and then start stepping through the code and get to a loop (foreach in the case I came across) the debugger falls out of the loop after the first iteration (i.e. it goes to the next line of code after the loop command). I was expecting the debugger to go to the next iteration and go back to the top of the loop (foreach command). It sort of makes it hard to debug the loop as I can't get to the second or following iterations of it.
2) I set a break point in a piece of code that executes when in menu mode for the players inventory (Begin Menumode 1002). It does not matter where I set the break point in the menumode 1002 the debugger screen is never displayed so I can't debug the code that is executed when the players inventory is displayed.
Can you let me know if this is expected and if so if/when it will be resolved as I really like this debugger and was hoping to use it, but the above problems make it a little hard.
Re. ConScribe: A tongue-in-cheek reference to how it has pretty much become the mainstay in any modder/player's utility locker. RuDE was supposed to usurp its throne but you can clearly see how that never came to pass ">
OK, now I see ">. Meanwhile, I've discovered that you're responsible for ConScribe yourself, so I can call you the master of both mainstay-or-at-least-meant-to-usurp-the-throne debugging tools. This is like a big company throwing two competing tools on the market, without letting anybody know that they share the same origin. The competition alone will keep the market busy "> (just kidding). Anyway, I like them both (but am still working more with ConScribe, because I just got so used to it).
Re. Runtime OBSE family: More inane banter; the first was REID (Runtime EditorIDs). The third - RuST (Runtime Script Profiler).
Alright... never heard of RuST before (will have a look at it immediately). Why not link all three tools in your description?
Feel free to post your requests and bug reports in the official BGSF thread.
Will gladly do so. But what's the BGSF thread? Is it mentioned anywhere here?
[EDIT] Can't find the Runtime Script Profiler/RuST with the nexusmods search. Or should the name read RusP rather thatn RusT. Couldn't you just provide a link here? I am sure that I will like it as much as the other two, if only I could find it!
@jaime: I'm yet to fathom why RuDE isn't as popular as you'd expect it to be!
Re. ConScribe: A tongue-in-cheek reference to how it has pretty much become the mainstay in any modder/player's utility locker. RuDE was supposed to usurp its throne but you can clearly see how that never came to pass
Re. Runtime OBSE family: More inane banter; the first was REID (Runtime EditorIDs). The third - RuST (Runtime Script Profiler).
Re. Support: Yeah, I do provide support (as with all of my other OBSE plugins; the regular mods - Not so much. They're pretty much in their final state). Not sure when I'll be updating it next but there are still a couple of more neat features that I want to implement (background queuing, custom error handlers for scripts, array/string variable browsers, etc).
Feel free to post your requests and bug reports in the official BGSF thread.
Am I really the only one showing interest in this tool? It really works as described, and I am impressed that such a thing is possible!
I wonder whether shadeMe is still supporting it? Is there a chance for further development?
One thing that I stumbled across and that reduces usability a bit is the following: With every debugging step the window seems to get refreshed and repositioned. I am using a dual-monitor setup, where the game is running on the primary screen and the debugging window should remain fixed to the secondary screen. With the current behavior, the debugger will always pop back to my primary monitor and thus overlay the game, which is quite annoying. Maybe this is something that could be changed without much efforts? "> I'd be really happy if this project would be kept up. It's the most professional debugging utility for TES that I've met so far...
Astonishing that this tools is getting only so little attention! If the debugger is really working as promised, this should normally be one of the must-have things for any modder. Are many people using it? Why are there only so few endorsements? "> I tried it only very quickly some months ago. I couldn't get it to work then and had no time to analyze it further. But I'll start a new turn now. I am excited to see if I'll succeed this time ">
[EDIT] BTW, what I never understood is: Why are there sworn enemies of ConScribe? What's so bad about it? I've been using it for a long time very efficiently for debugging, so I'd be interested in why people don't like it. I am just curious... if there's still a better debugger (like this one maybe?), I'll gladly use it, of course. [EDIT] And here's one more (just my curiosity): Why is this tool called The second member of the ‘Runtime’ OBSE plugin family in its description? What's the first member then? I wonder whether adding a little more info about these things would raise perception of this tool a bit? ">
Give Feedback
16 comments
Rename it and RUDE will have a mouse again.
Update: It seems the problem with the debugger screen is not just in menu mode 1002 but any menu mode.
The loop problem happens in 'while' loops as well.
Also the variable data displayed for arrays is not correct (it does not actually show any true data just garbage as far as I can tell).
other than these problems the debugger works well and I am using it when I can. To be honest I would like to endorse this but the three issues I have come across make it hard too (especially the loop issue). Will endorse if the issues are resolved.
1) If I set a break point and then start stepping through the code and get to a loop (foreach in the case I came across) the debugger falls out of the loop after the first iteration (i.e. it goes to the next line of code after the loop command). I was expecting the debugger to go to the next iteration and go back to the top of the loop (foreach command). It sort of makes it hard to debug the loop as I can't get to the second or following iterations of it.
2) I set a break point in a piece of code that executes when in menu mode for the players inventory (Begin Menumode 1002). It does not matter where I set the break point in the menumode 1002 the debugger screen is never displayed so I can't debug the code that is executed when the players inventory is displayed.
Can you let me know if this is expected and if so if/when it will be resolved as I really like this debugger and was hoping to use it, but the above problems make it a little hard.
PS: You can find RuDE's thread by searching for my topics at BGSF.
OK, now I see
Alright... never heard of RuST before (will have a look at it immediately). Why not link all three tools in your description?
Will gladly do so. But what's the BGSF thread? Is it mentioned anywhere here?
[EDIT] Can't find the Runtime Script Profiler/RuST with the nexusmods search. Or should the name read RusP rather thatn RusT. Couldn't you just provide a link here? I am sure that I will like it as much as the other two, if only I could find it!
Re. ConScribe: A tongue-in-cheek reference to how it has pretty much become the mainstay in any modder/player's utility locker. RuDE was supposed to usurp its throne but you can clearly see how that never came to pass
Re. Runtime OBSE family: More inane banter; the first was REID (Runtime EditorIDs). The third - RuST (Runtime Script Profiler).
Re. Support: Yeah, I do provide support (as with all of my other OBSE plugins; the regular mods - Not so much. They're pretty much in their final state). Not sure when I'll be updating it next but there are still a couple of more neat features that I want to implement (background queuing, custom error handlers for scripts, array/string variable browsers, etc).
Feel free to post your requests and bug reports in the official BGSF thread.
It really works as described, and I am impressed that such a thing is possible!
I wonder whether shadeMe is still supporting it? Is there a chance for further development?
One thing that I stumbled across and that reduces usability a bit is the following:
With every debugging step the window seems to get refreshed and repositioned. I am using a dual-monitor setup, where the game is running on the primary screen and the debugging window should remain fixed to the secondary screen. With the current behavior, the debugger will always pop back to my primary monitor and thus overlay the game, which is quite annoying.
Maybe this is something that could be changed without much efforts?
If the debugger is really working as promised, this should normally be one of the must-have things for any modder. Are many people using it? Why are there only so few endorsements?
I tried it only very quickly some months ago. I couldn't get it to work then and had no time to analyze it further. But I'll start a new turn now. I am excited to see if I'll succeed this time
[EDIT] BTW, what I never understood is: Why are there sworn enemies of ConScribe? What's so bad about it? I've been using it for a long time very efficiently for debugging, so I'd be interested in why people don't like it. I am just curious... if there's still a better debugger (like this one maybe?), I'll gladly use it, of course.
[EDIT] And here's one more (just my curiosity): Why is this tool called The second member of the ‘Runtime’ OBSE plugin family in its description? What's the first member then? I wonder whether adding a little more info about these things would raise perception of this tool a bit?