Complete.Org: Mailing Lists: Archives: freeciv-ai: August 2004:
[freeciv-ai] Re: (PR#9659) RfP: Even better AI logging

[freeciv-ai] Re: (PR#9659) RfP: Even better AI logging

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory.Berkolaiko@xxxxxxxxxxxxx
Subject: [freeciv-ai] Re: (PR#9659) RfP: Even better AI logging
From: "Per I. Mathisen" <per@xxxxxxxxxxx>
Date: Tue, 10 Aug 2004 04:34:02 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: >

On Tue, 10 Aug 2004, Gregory Berkolaiko wrote:
> The life of an AI debugger (even if it means just a couple of people)
> was made much easier by introduction of specialized log calls like
> CITY_LOG and UNIT_LOG and then by introduction of the "debug" command.
> But the number of log calls grows and now comes the time that even
> switching on the logging of one city can produce more output that you'd
> want to see.

No doubt the immediate problem is caused by settlers patch. We can cull
this as a short term solution.

> BTW, the first argument to *_LOG calls, the loglevel, is almost useless
> because all calls are debug ones so it is always LOG_DEBUG.

Mostly, yes. However, it is sometimes useful to change one line of code to
make only one log call emit information.

> Here are two (mutually exclusive) proposals:
> 1. Introduce the "priority level", as in
> CITY_LOG(priority, pcity, message....)

I dislike priority. This was tried with LOG_* and has mostly been a
failure, IMHO. Nobody uses it. Ditto for gamelog priority.

> 2. Introduce "log group", as in
> CITY_LOG(group, pcity, message....)
> The "debug" command becomes
> debug 2,5,6 city 13 32
> which switches log messages of groups 2, 5 and 6 for city at (13,32).
> Groups 0 and 99 are reserved and play the role of PL_FORCE and
> PL_SPECIAL correspondingly.
> In the code, the symbolic names of the groups should contain their
> number as well, so you don't have to look up their value; for example
> #define LG_MIL_BUILD3 3

This is a much better idea. It should be "debug <group> city <x> <y>",
where <group> is a string and listed in "help debug", though. A little bit
more work to implement, but so much more easy to use.

Each group should a bit in bitvector pcity->debug, I guess.

  - Per

[Prev in Thread] Current Thread [Next in Thread]