Messages

1

Programming / Re: Logging support (for bug reports and stuff)

« on: December 10, 2011, 11:03:33 am »

Well, if you want to test out Logog library for logging purposes, here is simple patch which just includes Logging.h and simple init for main.cpp. Only tested for MSVC++.

Get and compile Logog library from:
https://johnwbyrd.github.com/logog/

- put Logog include files into openxcom\deps\include\logog
- put logog.lib into openxcom\deps\lib

Patch doesnt screw up your project files, so you have to do it yourself :-)
- add ..deps\include\logog into your project include
- add logog.lib to your project linker input depencies
- add Logging.h to your project files

- also remember to add #include "Engine\Logging.h"  to any file you want to use logging (well, I add it to one central .h file which gets included in every file...)

And then just go test...
INFO("This won't work, no way.");
DBUG_GROUP("AI","Alien AI is going to get you");
DBUG_GROUP("VIDEO","Another video failure, bah!");
...

And when you start loving the fine Log Files you have and all the information you get from them, you can code your own implementation of Logging class, so you dont have to use library. Might do that myself lateron, but not until after Christmas or something, if ever.

2

Programming / Re: Logging support (for bug reports and stuff)

« on: December 09, 2011, 06:37:24 pm »

I'm only a bit afraid for the extra dependency/library... SupSuper is not very fond of them

Well, I'm not suggesting including "new library", I'm just suggestin putting (some form) of logging in.

Same thing can be accomplished with just logging.cpp and logging.h file - no need for "external" library. Just needs some coding and loving to make simple logging implementation

Logog has some nice features though:
- "any" number of targets (console, log file(s)) can be easily added
- different formatter can be set for each target
- different "groups" and filters (video,audio,ai whatever) can go do different targets (for example, you can have additional target, which just logs "AI" messages to console or different file or both).
- multithread safe, portable

And though I've spotted couple of nasty things in it already, i've seen worse, hehe.

Just though it would be useful to have for the project.

Now if I just could stop killing aliens and go back coding...

3

Programming / Re: Logging support (for bug reports and stuff)

« on: December 09, 2011, 05:56:47 pm »

Isn't LUA AI for Ufo: ai dead?

Hm, I did seem to read something about performance problems with AI and using LUA can make those even worse.

But back to the topic.

I've been playing around with the code and implementing logging support into it without affecting the code itself much. Right now, it adds one file to the project, logging.h but also requires logog library. (goes into deps/logog). I can also implement without using logog, but right now for testing, its fast way to go and less buggy.

Logging level set at COMPILE time decides if logging gets compiled into binary or not.  When logging is set to NONE, there is NO ADDITIONAL CODE compiled with the project. When its set to INFO, only ERROR and WARNING are compiled in (and also logged).

Usage is simple
INFO("This is information level message")
turns into

***** 12/09/11 17:37:29: [info] : This is information level message

Right now categories are AUDIO, VIDEO, ENGINE, AI, GENERAL (being errors, infos and all the other unclassified ones).

Of course, when it really starts to make "sense", (or not) is when you turn on logging for "AI" category (you can specify categories for logging and filter them).

***** 12/09/11 17:45:49: [info] [AI] : PatrolBAIState::think started for UnitID #13
***** 12/09/11 17:45:49: [info] [AI] : PatrolBAIState: No destination for UnitID #13: Figuring where to go next
***** 12/09/11 17:45:49: [info] [AI] : PatrolBAIState: (solution 1 assault/recovery) UnitID #13 going to move to #98
***** 12/09/11 17:45:47: [info] [AI] : PatrolBAIState::think started for UnitID #9
***** 12/09/11 17:45:47: [info] [AI] : PatrolBAIState: No destination for UnitID #9: Figuring where to go next
***** 12/09/11 17:45:47: [info] [AI] : PatrolBAIState: (solution 2) UnitID #9 going to move to 79
***** 12/09/11 17:45:47: [info] [AI] : PatrolBAIState: UnitID #9 is going to walk some

So now I know why that little gray bugger went for a swim instead of shooting me .. well I don't - but I will, soon, heh.

LOGOG_AI_DBUG("AggroBAIState: Gray wants more water");

4

Programming / Re: Logging support (for bug reports and stuff)

« on: December 08, 2011, 02:46:20 pm »

Fork and do it

As for console - quake like console would be cool

Heh, I think I'll wait until UFO: AI people have got their "LUA AI" and other AI stuff propely implemented and then go see if there are useful ideas and pieces to pick...

Quake console, hm, thats intersting idea - with cvars/commands of course. Though using SDL might make it bit more painful, it should be fairly easy to make it as "consolestate", availabe from any game state.

But proper logging, thats something what needs to get done, sooner or later...

5

Programming / Logging support (for bug reports and stuff)

« on: December 07, 2011, 05:35:19 pm »

Hi,

I was wondering if there has been any talk about including runtime logging support into openxcom? I mean logging stuff into proper LOG file or console. (or maybe there is already one within code and I just didnt spot it yet).

Of course, as long as most of the testing is done by developers itself and people capable of resolving and producing good bug reports, its not so big deal, but in a longer run... me I personally prefer log files, bigger the better :-)

When crash or bug occurs, its very useful to know what is the host OS is, what video card system has and other information. Sure, user can provide that too, but sometimes, well, lets just say some users do know they use "Windows", or "Linux", but dont get all the details right... (like running WinXP without any service packs ...). And log files can provide developers that information in standard and compact form.

Well, now I'm just waiting for that "openxcom.log" file to appear in my xcom dir - well, actually it already did, but now I'm waiting for the "master" code to get one too, hehe 

***** 12/07/11 18:45:57: [info] OpenXcom v0.3
***** 12/07/11 18:45:57: [info] Running on: Windows 7 (build 7601, Service Pack 1) (64bit)
...
There are many portable multithread-safe logging classes to choose from. . One example specifically made for games is Logog https://johnwbyrd.github.com/logog/.

There are lot of alternatives too and many libs have included their own "logging" classes too.

I wish all the best for the project - XCom was my favourite games for a long time. And I want it back too, just as it was, but without bugs!

Well, I also want to use LUA for AI, but thats different story, hehe.

Dabb