Debug I/O v1.1

[Moderator]

19:28, 15th May 2013
Magtheridon96: Good logging tool.

 

[Almia]

~Reserved.

Too advance and shit.

 

[SeriousEnemy]

It works now.
I guess this could be pretty useful while testing larger scripts or a complete map!

Maybe you should add a better example for people without vjass knowledge.

+ rep for the nice coding and the eye candy result

 

[mckill2009]

although this is kinda useless to me coz Im not playing at battlenet, but good job!

 

[SeriousEnemy]

although this is kinda useless to me coz Im not playing at battlenet, but good job!

This is working in single player aswell.

 

[MasterTrainer]

I've never had a chance to comment my thoughts regarding this system before but:

This is awesome. Not only was I able to fix my triggers on my own but I also got a fun way of reading the game.

 

[mckill2009]

This is working in single player aswell.

I know butit's more useful in multiplayer coz of chats...

 

[edo494]

I must ask, why did you upload again instead of just editing the old submission?

 

[Chaosy]

may I ask what you use the counter for?

 

[Almia]

I must ask, why did you upload again instead of just editing the old submission?

The one is GUI,so i have to seperate it.

may I ask what you use the counter for?

Counter? Do you mean the time,or the one in the demo?

edit
Updating the code.

 

[Chaosy]

the time

 

[Almia]

Just to know what time the log was tested,especially,for crashes.

edit
Thanks for the wonderful comments

I should have named this as Debug I/O

edit
Renamed to Debug I/O.

 

[Geries]

Actually, no, leave it Debug Log or similar to that. Debug IO sounds stupid, and nobody searches for that name, what they will search for is probably Debug log, Debug File, Log file, or something like that, not Debug IO. Also this is just output.

I don't know what the hell did your code do to warcraft, but it turned it into multithreaded and used almost 2 cores on full load( 80% ) which tells the script is quite not effective, even in your test map it wasn't printing out that intensively. Other thing I noticed is that update( ) function never ends, it is public, so calling it in an another function causes rest code never getting executed. I don't know what's the reason of that, since thread crash shouldn't happen( at first, when there's not so many log entries ), maybe some Preload( ) is missing " somewhere, but this is a major issue with the code.

Also, I really recommend you to NOT update existing log data file, cause right now you need to store all log entries to write them out at next update again. Since you use an array to store those entries, that is quite limited. Instead I recommend to buffer log entries and dump them on next update( ) into a new log-data files. Update should occur after 30-60 seconds, or after 100/200 log entries. This way you'd decrease time spent on writing log, cause you'd have to write new entries only. Three minor cons this method has: There will be a lot data files on intensive use, you need more advanced .bat and script that can handle them, if a player quits all log text after the last update will be missing for him.

That's all for now, but I like the idea of debug files, so once it is fully working, I'll be quite happy.

 

[Almia]

Nice review
Actually,the second paragraph is the only one that i don't understand.

Actually,if you are going to clear the log entries,this won't be called a DebugLog at all,because you won't be tracking the debug messages any more.

 

[Geries]

2. paragraph is about that Log.update( ) never finishes execution, or some other weird stuff happens.

I only say to store log entries into more files, not just one file. This can help performance of writing new log entries, but complicates the log-assembler bat file.

 

[Almia]

I can't. The users must do the overwrite safety. MS-DOS and Command Prompt doesn't allow that kind of feature(or im missing something).

 

[Chaosy]

@almia
seconds since game started then I guess?

 

[Almia]

@almia
seconds since game started then I guess?

Yes.

Its actually, minutes - seconds - jiffy

 

[Almia]

Updated.
Optimized code
Now,file are created automatically.
A new feature where you can have the Header optional.

 

[WaterKnight]

I see you do not write lines immediately. PreloadGenEnd is slow because Wc3 buffers all the Preload lines and then creates a wholly new file on every PreloadGenEnd instead of appending. Still, to test for fatal errors/desyncs, pushing back updates is no option since fatals halt everything. So maybe provide an alternative write option.

What I wanted to generally ask though, any chance to speed up writing to a file? One could erase prior lines again after a block has been completed but this requires to re-equip the preload-buffer like you do at the moment, therefore takes performance on its own and you are likely to reach limits. It should be better to move to another file at a certain amount of lines. Then you do not have to reload as much, wc3 does not need to replace large files and do not have to worry about the oplimit.

 

[Almia]

So you want me to do a File IO-like functionality? Nononononoononononoonononoononononononononoononononoononononononono

 

[WaterKnight]

So you want me to do a File IO-like functionality? Nononononoononononoonononoononononononononoononononoononononononono

Nononononoononononoonononoononononononononoononononoononononononono, I did not.

I mentioned the situation provided by wc3. It's too slow to log large amounts of information. Then I remarked that the functionality shown here is not suited for testing critical errors, therefore made a suggestion.

Independent from your resource - although it may also be improved this way - I pointed out that splitting the output is more effective. Your batch can even remerge all the outputs afterwards. Above all, I am interested in hearing more ideas about speeding up the process.

 

[WaterKnight]

Another idea: It is often ugly to spam the screen ingame with debug game messages. And if you put it away somewhere in quests or some multiboard, then you are very limited or lack the fast access while playing. Therefore I am now using this, outsourcing debug messages in txt files, in conjunction with a parallel running program that redirects the results to stdout of a cmd.exe. So I start the game, a central file is set in the beginning to indicate what map/session you are playing in order to identify where the debugs are stored. Then you call the aiding tool that periodically reads the contents there and prints new entries. Of course wc3 should be windowed so you can see both. Or you have a 2nd monitor. Also, debug msgs should contain a timestamp and you see the timer in the game permanently.

 

[Almia]

So, because I haven't read the whole description, you mean like a Delayed Message Queue?

 

[edo494]

your test scripts wont even compile, lets see if you can find the error yourself

 

[Almia]

wut.
I compiled this since the day I submitted it, along with the tests.
using 5e

edit
WTH happened? I didn't even updated this resource? WTF

 

[edo494]

Mag updated it, it was nothing big tho, the script as is is working buglessly, but the examples were bugged a bit:
They were requiring nonexisting, DebugIO library
The second example was trying to call nonexisting method .add instead of .write

 

[pred1980]

Wow, this is really cool. I'll add this to our project to get a better Feedback from the users. They just have to paste the debug-log in our Bugs-Forum and we can see what happens...

Greate System!!! Thx a lot! I'll add you to the Credit List if you want?!? The project i mean you'll find in my signature.

 

[axleion]

This really helps for debugging process though becoming a huge workload to implement to almost finished map.

it would be better if you explain each API further rather than short explanation.

why not make use of static if when using constant boolean?

is there's any limitation?

I come across some strange things, a log shows about 3000 lines yet it only display about 10 lines in the log.
Just found that I can't use | and > in Log.write

it seems to be there is mistype over here:

                if sec > 59 then
                    set sec = 0
                    set mil = mil + 1
                endif

it should be:

                if sec > 59 then
                    set sec = 0
                    set min = min + 1
                endif

from what I manage to understand from the code,
the log is limited to 8190 lines because of max array size,
and because of the periodic .createfile() which by default reads a growing amount of string array every second, it started to lag after about one minute in game.
and we can't use .clear() to free up the string array as it will clear the next created log file too.
could you set the script to workaround this current limitation? especially the amount of lines and growing string array.

 

[NEL]

This thing doesn't work now in 1.27 or above. :<

 

[Almia]

This thing doesn't work now in 1.27 or above. :<

Preload was patched