Debugging... IT'S DAMN NEAR IMPOSSIBLE!!! : FFXI General Discussions

XU would be a lot better if it were simpler to DEBUG! I mean it takes forever to make a change, load up XU, launch the program, and then see if the script is working yet or not! It needs to be easier to debug! This built-in anti detection crap that really doesn't do much except give me headaches only makes things worse.

Please, PUT SOME EFFORT INTO MAKING IT EASIER TO DEBUG!

Thank you.

The best way is to add log statements in your code so you know what is happening at those points in the code.

Also, try running your game in windowed mode so you can easily switch to notepad or whatever to edit your script.

I agree with LagMonster, I spend more time trying to debug my code than actually coding.

I end up having to POL every 2 or 3 times I run a script too, because they simply quit working after a while (i.e. when you click 'start' it immediately stops the script). I'm not sure what causes this, but i have experienced it with every script I use from XUFish, to getLocation, etc, on 12 different computers using both (windows 2000 & windowsXP operating systems).

Plus scripts don't always stop properly, sometimes you hit stop and the xml button switches from 'stop' to 'start', but the script doesn't actually stop running.

That is caused by a memory leak in the script. That is most offen attributed to declaring an object, but not setting it to nothing before you leave that sub/function.

It could also be due to a script not stopping properly. I will be looking into that again after the next XU patch.

As a temporary fix, you can run a different script ( ie the mouse demo script) and it will usually clear out old memory and reload a new script host.

Just as a side thought, it is a very good idea to do two things when coding. THe first is code small chuncks and test them a little at a time. Do not add a bunch of code changes and expect them all to work without a hitch. The second things, is add a bunch of debug log messages. These are usually done with a statement like: If debug=1 then log(xxxx)

While developing XUFishv4 I thought about this and placed everything into objects, even the scripts in the initializer vbs files. I've noticed that as I set everything to nothing it works a helluva lot better.

I still find it highly annoying to debug though, the best way I've found so far is set on error resume next and sprinkly my code with message boxes to see where it goes wrong.
Debugging would be a different world if there was some way to find the file and line number of where something goes wrong, as it is now it's just a pain in the !@#$%^&* and when you get a bug you just can't find you're quite likelly to just give it up for a few weeks.

Calling deactivate on windows before freeing them helps too.
Granted, the game still "chops" every second after you've been running scripts 20 times or so, makes me kinda wish there was some way to launch scripts via ctrl+ins+number so I wouldn't have to display the run script dialog.

[quote="Admin";p="50929"]
Just as a side thought, it is a very good idea to do two things when coding. THe first is code small chuncks and test them a little at a time. Do not add a bunch of code changes and expect them all to work without a hitch. The second things, is add a bunch of debug log messages. These are usually done with a statement like: If debug=1 then log(xxxx)
[/quote]

Yeah... I kinda realized this back when I was 12... How to debug is not the issue. The issue with XU is that it takes ungodly amounts of effort just to figure out what is causing the problem.

First of all, you are forced to write in VBScript. VBScript is one unpleasent language to code in. It's error handling is pathetic. You are limmited to using "On Error Resume Next" which, upon encountering an error, simply executes the next line of code. Since the line that caused the error is never executed, aditionals errors are almost certain to occur. The end result is a script that simply does nothing. It either terminates or will loop determining how it's coded. So in order to track down an error, you must check Err.Number every line and see if it's not 0.

But most of the blame lies with XU itself. Unless there is a way of executing code specific to XU running the code outside of the XU enviroment I don't know about, you must debug the code from within XU which has no error handling at all for the most part. The stupid launcher renames the DLL that runs the XU host each time you click play, there is no way of loading XUHost remotely. This is the most annoying thing of all. Debugging from inside the game is hell, especially when you have no control over the execution or anyway of knowing just what the script has processed. I am not going to use native XU commands if I can't test them first. This has got to be fixed! Badly!

Personally, I am used to being spoiled when it comes to debugging. I expect to have syntax xhecking, break points, the ability to step thru code and see exactly what result a line of code returns. I don't exdpect this from XU but XU is about as far away from this as possible. It's like driving blindfolded in a SUV. You may run over someone but comes accross as any other bump in the road.

I got something for you here. I haven't made a debug module yet, but let's see how it goes.

You could do "on error goto subname" and do the debug work in there. The only information we might be missing is the line #.

BRB, I'll check that out right away.

How about this?

Did you test if it works? Never did for me when I tried.

That's VB code! Not VBS!

dang

I think there's a coma too much in there
You are right I haven't tested it. I haven't played FFXI in a month too. Look at the message box sample god admin gave us with the xu client and use that.

I dont think on error goto works in VBS.

See the vbs documentation at microsoft.