Winboard questions

[Guenther Simon]

Hi HG,

What is the current limit of engines displayed in the built-in tournament manager?
I am asking because my list stops at around 70% of the installed engines

There is also another problem (may be related, may be not), shortly before the displayed list
ends, one correctly installed engine from the WB.ini is only displayed as 'tbs' which is just
the last part of an argument for the real engine?

e.g.

Code: Select all

"SOS_51" /fd=c:\Engines\UCI\SOS_51
"SOS_991103 c:\sicherheit\chess\tbs" /fd=c:\Engines\WB\SOS_991103
"SSEChess_2050DC" /fd=c:\Engines\WB\SSEChess_2050DC

displayed as:

Code: Select all

SOS_51
tbs
SSEChess_2050DC

Moreover I did not find an option to specify single debug files for each played game in a specified
tournament, as I was used with PSWBTM. Could this be added to the TM menu, or is it done automatically?
(I haven't started a tournamen yet, just looking at all the new things)

A few other suggestions:
- adding the move number to the header of the eval graph would be nice
- somehow I am not used anymore to the way the eval graph is displayed, what if the colour for the graph
could follow the played colour only, instead of the player too?

Edit: All the above with HGMaster_20120118

Guenther

[H.G.Muller]

What is the current limit of engines displayed in the built-in tournament manager?
I am asking because my list stops at around 70% of the installed engines

I must admit I don't really know that. Obviously it cannot be any longer than the maximum length of the -firstProgramNames option in the winboard.ini file. But the limit there is in characters, not in lines. But it could be that in preparing the combobox in the Load Engine and Tournament Options dialogs, I use an array of limited size. I will have a look at that, and if necessary increase the limit.

There is also another problem (may be related, may be not), shortly before the displayed list
ends, one correctly installed engine from the WB.ini is only displayed as 'tbs' which is just
the last part of an argument for the real engine?

e.g.

Code: Select all

"SOS_51" /fd=c:\Engines\UCI\SOS_51
"SOS_991103 c:\sicherheit\chess\tbs" /fd=c:\Engines\WB\SOS_991103
"SSEChess_2050DC" /fd=c:\Engines\WB\SSEChess_2050DC

displayed as:

Code: Select all

SOS_51
tbs
SSEChess_2050DC

To get the combo-box items, I use the 'tidy name' WinBoard derives from the name of the executable. This is also the name that would appear in the PGN and the window title, were it not that modern engine have a myname feature, which overrules it with whatever they want to call themselves. The latter cannot be known without running the engine, though.

The algorithm to tidy the name is strip off the directory, and any arguments behind space. Unfortunately in the Windows file system there is no way to know that the space before c: is not simply part of the name of the first directory of the path, but seperating an argument that does have backslashes in it. To avoid problems with such awkward engine commands, it is possible to install the engine as:

Code: Select all

"nickname" -fcp "SOS_991103 c:\sicherheit\chess\tbs" /fd=c:\Engines\WB\SOS_991103


This would make "nickname", which can be an arbitrary string, appear as engine ID in the combobox. This is a kludge, as what really happens is that you give two engine names, the second overruling the first. But I discovered that this practice is in common use, so I figured I might as well exploit it, and made it such that the combobox item is derived from the first engine name, even if WB will only use the last to run the engine. Thie 'duplicate engine kludge' is what happens when you install the engine with a nickname in the Load Engine dialog.

Moreover I did not find an option to specify single debug files for each played game in a specified
tournament, as I was used with PSWBTM. Could this be added to the TM menu, or is it done automatically?
(I haven't started a tournamen yet, just looking at all the new things)

I am afraid that this is something I did not implement yet. The easiest way to implement it would be to allow the useer specifying the name of a debug file that has a variable component, derived from the tourney game number. E.g. -debugfile debugs\game%d.debug. Then I could expand that in match mode at the beginning of every game, compare it with the name in force, and if it is different, close the debug file, and open the new one.

A few other suggestions:
- adding the move number to the header of the eval graph would be nice
- somehow I am not used anymore to the way the eval graph is displayed, what if the colour for the graph
could follow the played colour only, instead of the player too?

Not sure what exactly you mean by the last point.

[Guenther Simon]

Thanks for the quick answer HG! For comments see below.

What is the current limit of engines displayed in the built-in tournament manager?
I am asking because my list stops at around 70% of the installed engines

I must admit I don't really know that. Obviously it cannot be any longer than the maximum length of the -firstProgramNames option in the winboard.ini file. But the limit there is in characters, not in lines. But it could be that in preparing the combobox in the Load Engine and Tournament Options dialogs, I use an array of limited size. I will have a look at that, and if necessary increase the limit.

Ok I understand I counted the fd entries now and they are around 1100 lines (engines) but 2000 would be good

There is also another problem (may be related, may be not), shortly before the displayed list
ends, one correctly installed engine from the WB.ini is only displayed as 'tbs' which is just
the last part of an argument for the real engine?

e.g.

Code: Select all

"SOS_51" /fd=c:\Engines\UCI\SOS_51
"SOS_991103 c:\sicherheit\chess\tbs" /fd=c:\Engines\WB\SOS_991103
"SSEChess_2050DC" /fd=c:\Engines\WB\SSEChess_2050DC

displayed as:

Code: Select all

SOS_51
tbs
SSEChess_2050DC

To get the combo-box items, I use the 'tidy name' WinBoard derives from the name of the executable. This is also the name that would appear in the PGN and the window title, were it not that modern engine have a myname feature, which overrules it with whatever they want to call themselves. The latter cannot be known without running the engine, though.

The algorithm to tidy the name is strip off the directory, and any arguments behind space. Unfortunately in the Windows file system there is no way to know that the space before c: is not simply part of the name of the first directory of the path, but seperating an argument that does have backslashes in it. To avoid problems with such awkward engine commands, it is possible to install the engine as:

Code: Select all

"nickname" -fcp "SOS_991103 c:\sicherheit\chess\tbs" /fd=c:\Engines\WB\SOS_991103


This would make "nickname", which can be an arbitrary string, appear as engine ID in the combobox. This is a kludge, as what really happens is that you give two engine names, the second overruling the first. But I discovered that this practice is in common use, so I figured I might as well exploit it, and made it such that the combobox item is derived from the first engine name, even if WB will only use the last to run the engine. Thie 'duplicate engine kludge' is what happens when you install the engine with a nickname in the Load Engine dialog.

Ok I have already started to add the nickname workaround to the problematic entries which contain too much arguments and complete directories
and it works fine.

Moreover I did not find an option to specify single debug files for each played game in a specified
tournament, as I was used with PSWBTM. Could this be added to the TM menu, or is it done automatically?
(I haven't started a tournamen yet, just looking at all the new things)

I am afraid that this is something I did not implement yet. The easiest way to implement it would be to allow the useer specifying the name of a debug file that has a variable component, derived from the tourney game number. E.g. -debugfile debugs\game%d.debug. Then I could expand that in match mode at the beginning of every game, compare it with the name in force, and if it is different, close the debug file, and open the new one.

This solution sounds good. In PSWBTM the user also defines a debug folder per tournament and PSWBTM adds the game number variable as name for each debug file. It wouldn't be bad if it would be automatically saved to a subfolder called debug in the folder of the game file I guess?
BTW do the different games of a tournament get a number tag or a round tag or something similar?

A few other suggestions:
- adding the move number to the header of the eval graph would be nice
- somehow I am not used anymore to the way the eval graph is displayed, what if the colour for the graph
could follow the played colour only, instead of the player too?

Not sure what exactly you mean by the last point.

I wasn't very clear. Currently we can define two colours following the players in the graph. But sometimes it looks a bit confusing at first sight thus it would be perhaps a good idea?(despite losing some extra info) if the defined coulors only follow the score instead(as an alternative option), e.g. green or yellow always good for White and red or whatever good for Black, but that's just cosmetical and not too important.

Thanks for all the work for Winboard!

Guenther

[H.G.Muller]

This solution sounds good. In PSWBTM the user also defines a debug folder per tournament and PSWBTM adds the game number variable as name for each debug file. It wouldn't be bad if it would be automatically saved to a subfolder called debug in the folder of the game file I guess?

The question is always how it should behave if the folder does not yet exist. If the choice is to have it create the folder, than it would just be a matter of specifying a path name as -debugfile (or have that specified in the master settings file, so that it becomes essentially the default setting in stead of winboard.debug.)

BTW do the different games of a tournament get a number tag or a round tag or something similar?

After some thinking, the most useful way to set the PGN round tag I could come up with was as the game number within the pairing. So with 10 games per pairing (or 2 cycles of 5 games per pairing) it would count 1-10, and the first game in every pairing would be round 1, etc. This is also the number from which the game or position index would be derived in auto-increment mode of the -lgf and -lpf files. It takes the place of the game number in an old-style match, and basically makes a more complex tourney simply a collection of such matches.

If you know any other useful way to set this, it could be made subject to an option.

There is currently no way the games get a unique number in the PGN; there is a unique ordering of the games in a tourney, though, which follows from the tourney parameters. Perhaps I should make it possible to put that in the round tag.

I have checked, and indeed I have a parameter MAX_ENGINES which was set to 1000. Easy enough to set it to 2000, or even 5000. At some point the design with a combobox will probably become awkward. (Although on Windows you can type a character, and it will automatically scroll there.) For very large numbers of engines, it might be better to have some structuring, like a two-level pull-down menu. Not sure how exactly that should be organized.

[H.G.Muller]

Btw, I have just pushed a new version that allows upto 2000 engines. It also offers the possibility to group the engines, so it won't try to display them all at once in a single ombobox, but would instead display group names, that you can then open to see what is in them. See http://www.talkchess.com/forum/viewtopic.php?t=42390 .

I still have to work on the debug files.

[H.G.Muller]

OK, I think I have implemented most of your suggestions now:

Individual debug files

It is now possible to specify a name for the debug file that contains a unique tournament game number: simply put a %d anywhere in it, and that will be replaced by the game number. Like

winboard -debug -debugfile game%d.debug

would produce files game1.debug, game2.debug, ... for the respetive games. These would be created in the WinBoard folder, like debug files normally would; If you want them in a separate folder, say C:\MyTourneyDebugs, you should specify that yourself by

winboard -debug -debugfile {C:\MyTourneyDebugs\game%d.debug}

where you should make sure that folder exists.

Game number in PGN

I added a persistent option -pgnNumberTag true|false (default false), which controls whether (in a tournament!) a Number tag is included in the saved PGN, like

[Number "1"]

The number is unique in the tourney, and corresponds to the number in the debug file name. It can be different from the Round tag, which needs not be unique: in one round (of a round-robin) all players play one game (save a bye).

Move number in Eval Graph title

I changed the title to put the move number as the first thing between the braces, like:

Eval Graph {14: +0.37/8 3}

I am still not sure what you would want for the Eval Graph colors. There are two display modes (depending on space), histogram or line. With histogram the colors of the bars alternate (they could be set the same through command-line options). In line mode, there are two different lines, of different color. Setting the colors the same would just make the lines indistinguishable.

Is that what you mean, that the score of both engines should be displayed as a single line? Often engines disagree very much about the score, so this could be a highly oscillating line. Nevertheless, I could make it do that in case the colors were specified as exactly the same.

Max number of engines

As announced above, I inreased that to 2000. And I allow grouping to make such large numbers easier to handle. Unfortunately this activated a latent bug in readout of comboboxes, so when you used it in the Tourney dialog, it would crash when you pressed OK. (I had tested on Load Engine, and to see if I could correctly selected tourney participants, but I never actually tried to start a tourney...) This should be fixed now.

Altering settings not in menus

I added an undocumented kludge, which I am not sure we will keep, but which could be useful for experienced users that know what they are doing: You can now type options in the Move Type-In dialog! This can be used, for instance, for setting -afterGame or -debugfile during the session, by typing things like

!!! -debugfile game%d.txt -afterGame "crosstable.exe mygames.pgn"

The leading "!!! " is required to 'unlock' the feature, as a safety measure against accidental use by a typo. This because the patch in the current form is quite dangerous: a typo in the option would cause a fatal error, an make WinBoard exit. Furthermore, options that have effects during initialization (like board colors) will not work, as the initialization is not redone. This could lead to inconsistent states. Their new values would be written in the ini file on saving settings, though. (If they are persistent, that is). So this feature is only to be used for options that are just consulted during the session for an instantaneous decision, such as the -debugfile when a new tourney game starts, or -afterGame when it finishes.

[Guenther Simon]

Hi HG!

A first answer about a bug which showed up yesterday and which I am not sure is the one you fixed already
in the newest version. In the load engine dialogue from which you showed a screenshot at Talkchess instead
of (load as) 'First' or 'Second' (I guess it would be 'Second' because I cannot see it) I have engine names.
My editor says the two shown names instead of first and second should be lines 1001 and 1002 in my fd ini.
When trying to load those instead of 'first' 'second' I see sometimes strange characters and WB might crash.

I download again now.

More later

Guenther

[H.G.Muller]

Hmm, that sounds like an array is badly overflowing...

Ah, I see! The arrays in the WB front-end for expanding the engine list in does use a hard size 1000 in stead of MAXENGINES (= 2000). I fixed a similar thing for XBoard recently (where the size was a hard 100 !). The routine that fills it would only pull on the break if you exceed MAXENGINES.

Thanks for spotting this. I will fix it immediately. It is a miracle you don't crash right away!

[edit] OK, I uploaded a version where this should be fixed now. (2288070 bytes; unfortunately the WinBoard .exe has the same date...)

[Guenther Simon]

Hmm, that sounds like an array is badly overflowing...

Ah, I see! The arrays in the WB front-end for expanding the engine list in does use a hard size 1000 in stead of MAXENGINES (= 2000). I fixed a similar thing for XBoard recently (where the size was a hard 100 !). The routine that fills it would only pull on the break if you exceed MAXENGINES.

Thanks for spotting this. I will fix it immediately. It is a miracle you don't crash right away!

[edit] OK, I uploaded a version where this should be fixed now. (2288070 bytes; unfortunately the WinBoard .exe has the same date...)

Yes the bug is gone. Thanks HG. The other things need some time, I report back in the next days.

Guenther

[Guenther Simon]

OK, I think I have implemented most of your suggestions now:

Individual debug files

It is now possible to specify a name for the debug file that contains a unique tournament game number: simply put a %d anywhere in it, and that will be replaced by the game number. Like

winboard -debug -debugfile game%d.debug

would produce files game1.debug, game2.debug, ... for the respetive games. These would be created in the WinBoard folder, like debug files normally would; If you want them in a separate folder, say C:\MyTourneyDebugs, you should specify that yourself by

winboard -debug -debugfile {C:\MyTourneyDebugs\game%d.debug}

where you should make sure that folder exists.

Game number in PGN

I added a persistent option -pgnNumberTag true|false (default false), which controls whether (in a tournament!) a Number tag is included in the saved PGN, like

[Number "1"]

The number is unique in the tourney, and corresponds to the number in the debug file name. It can be different from the Round tag, which needs not be unique: in one round (of a round-robin) all players play one game (save a bye).

Move number in Eval Graph title

I changed the title to put the move number as the first thing between the braces, like:

Eval Graph {14: +0.37/8 3}

I am still not sure what you would want for the Eval Graph colors. There are two display modes (depending on space), histogram or line. With histogram the colors of the bars alternate (they could be set the same through command-line options). In line mode, there are two different lines, of different color. Setting the colors the same would just make the lines indistinguishable.

Is that what you mean, that the score of both engines should be displayed as a single line? Often engines disagree very much about the score, so this could be a highly oscillating line. Nevertheless, I could make it do that in case the colors were specified as exactly the same.

Max number of engines

As announced above, I inreased that to 2000. And I allow grouping to make such large numbers easier to handle. Unfortunately this activated a latent bug in readout of comboboxes, so when you used it in the Tourney dialog, it would crash when you pressed OK. (I had tested on Load Engine, and to see if I could correctly selected tourney participants, but I never actually tried to start a tourney...) This should be fixed now.

Altering settings not in menus

I added an undocumented kludge, which I am not sure we will keep, but which could be useful for experienced users that know what they are doing: You can now type options in the Move Type-In dialog! This can be used, for instance, for setting -afterGame or -debugfile during the session, by typing things like

!!! -debugfile game%d.txt -afterGame "crosstable.exe mygames.pgn"

The leading "!!! " is required to 'unlock' the feature, as a safety measure against accidental use by a typo. This because the patch in the current form is quite dangerous: a typo in the option would cause a fatal error, an make WinBoard exit. Furthermore, options that have effects during initialization (like board colors) will not work, as the initialization is not redone. This could lead to inconsistent states. Their new values would be written in the ini file on saving settings, though. (If they are persistent, that is). So this feature is only to be used for options that are just consulted during the session for an instantaneous decision, such as the -debugfile when a new tourney game starts, or -afterGame when it finishes.

I did some first tests now.

1. Individual debug files set up at winboard startup works
2. Move number in title bar of the eval graph works
3. The bug I had reported last night due to max engines > 1000 is gone


4. Inserting !!! -debugfile game%d.txt in the type move dialogue did not work and no debug was written at all.
May be it should be !!! -debug -debugfile game%d.txt, because the debug switch is not set before the file is specified?
Or I did something wrong, I will test that later again.

5. A minor problem with tournaments. I still load WB with the startup dialogue and with the default loaded engine wich is
the one in the special first lines of fd and sd directories of the WB.ini, e.g.

Code: Select all

}
/firstChessProgramNames={'Abrok_50 hash 256' /fd=c:\Engines\WB\Abrok_50
...
}
/secondChessProgramNames={'Abrok_50 hash 256' /sd=c:\Engines\WB\Abrok_50
...


If I start now a tournament with the internal tournament manager the deafult engine is not unloaded and stays
in memory(does not use cpu because it still waits...for commands). It should be unloaded before a tournament starts.

Ah and for the colours in the eval graph, this was just a suggestion for an alternative display mode and I try to
explain it more clearly. I would like to have a mode(if possible) where the colour follows the SCORE not the PLAYER,
e.g. positive score alwways GREEN (or whatever), negative score RED (or whatever), the default now is that the
colour is set for the player.(this doesn't lose too much info because I can still click on a single move in the histogram
to see who made what move)

Guenther

[H.G.Muller]

I did some first tests now.

1. Individual debug files set up at winboard startup works
2. Move number in title bar of the eval graph works
3. The bug I had reported last night due to max engines > 1000 is gone


4. Inserting !!! -debugfile game%d.txt in the type move dialogue did not work and no debug was written at all.
May be it should be !!! -debug -debugfile game%d.txt, because the debug switch is not set before the file is specified?
Or I did something wrong, I will test that later again.

That is correct. -debugfile does not imply -debug. And I don't think it should; -debug can be switched on or off with Ctrl+Alt+F12 (now also Ctrl+D, as newer Windows systems seem to have usurped that keystroke...) during the session, and it would be perfectly legitimate use to set -debugfile in the master settings file to something other than xboard.debug by default (e.g. because you want it in another folder), and still run by default in non-debug mode, until you switch it on through the keyboard (or explicitly start with -debug).

What you say would sort of work: it exactly shows the danger of the !!! kludge. Normally setting -debug through the type-in would cause trouble, because the debug file is opened in the startup initialization. In this application it might work, because at the beginning of each game a new debug file would be opened.

5. A minor problem with tournaments. I still load WB with the startup dialogue and with the default loaded engine wich is
the one in the special first lines of fd and sd directories of the WB.ini, e.g.

Code: Select all

}
/firstChessProgramNames={'Abrok_50 hash 256' /fd=c:\Engines\WB\Abrok_50
...
}
/secondChessProgramNames={'Abrok_50 hash 256' /sd=c:\Engines\WB\Abrok_50
...


If I start now a tournament with the internal tournament manager the deafult engine is not unloaded and stays
in memory(does not use cpu because it still waits...for commands). It should be unloaded before a tournament starts.

Ah yes, that definitely is not as it should be. I will look into it.

Ah and for the colours in the eval graph, this was just a suggestion for an alternative display mode and I try to
explain it more clearly. I would like to have a mode(if possible) where the colour follows the SCORE not the PLAYER,
e.g. positive score alwways GREEN (or whatever), negative score RED (or whatever), the default now is that the
colour is set for the player.(this doesn't lose too much info because I can still click on a single move in the histogram
to see who made what move)

Ah, OK, now I understand. Later in the game the the graph might switch to line mode, and oyou would have two closely spaced lines of the same color. And selecting one move would not be easy then, as the clicks select by x-coordinate, not y-coordinate, so you could not click on one line to see who's it was.

[H.G.Muller]

OK, fixed! The previous engines should now unload at the start of a tourney. I pushed the corrected version to the same link.

[Guenther Simon]

Ah, OK, now I understand. Later in the game the the graph might switch to line mode, and oyou would have two closely spaced lines of the same color. And selecting one move would not be easy then, as the clicks select by x-coordinate, not y-coordinate, so you could not click on one line to see who's it was.

Well, I completely forgot about the line mode when games last longer and space of the eval graph runs out. Then it seems my suggestion
cannot work. No problem, just forget about it.

Guenther

[Guenther Simon]

Some thoughts about the debug feature. I noticed that at least when playing from start positions(may be also with GUI book which I never used so far)
the beginning of a new game is added to the 'old' debug file is this intended? Shouldn't it be finished somehow after 'gameend' and what it does before picking up a new game?

I am asking because if users want e.g. use TLCV there would be a problem with missing moves. An even bigger problem I noticed in this
scenario is that the TLC server relies on a certain file thus it would be necessary to rename the debug files after the game not beforehand,
as PSWBTM it does.

But may be all of this is obsolete with the ICS and the live viewer you used yourself? I have no idea what it requires to use those and if they are
intended for free use at all? Note that I speak generally for all users, because I really don't know if I ever would do live broadcasts again...

What do you think?

Guenther

example: debug end

Code: Select all

1298062 <second: 42 +0 100 1194325 Rf1+ Ke6 Re1+ Kf6 Rf1+
GameEnds(27, User adjudication, 4)
1298078 >first : result 1/2-1/2 {User adjudication}
1298078 >second: result 1/2-1/2 {User adjudication}
1298078 >first : force
1298078 >first : ping 2
1298078 >second: force
1298078 >second: ping 2
results = '-+*'
Critter_14\012Stockfish_222JA\012Houdini_15a\012Rybka_4-32\012
pick next game from '-+=': 3
Reserved, next=3, nr=2, procs=(10aefe0,10a6fe0)
1298078 <first : pong 2
1298078 <second: pong 2
cycle=0, round=0, pairing=0 curGame=4
Reset(0, 1) from gameMode 8
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
shuffleOpenings = 0
TC string = ':40/180'
mps=40 tc=180000 inc=0
TC string = ':40/180'
mps=40 tc=180000 inc=0
1298093 >first : new
random
1298093 >first : ics -
1298093 >first : level 40 3 0
1298093 >first : post
1298093 >first : hard
1298093 >first : easy
1298093 >first : ping 3
LoadGame(): on entry, gameMode 0
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial 1,-1,-1,-1  type 1000
trial -1,-1,-1,-1  type 0000
trial -1,-1,1,3  type 0021
Disambiguate in:  0(-1,-1)-(1,2) = 0 (-)
Disambiguate out: 0(1,1)-(1,2) = 0 (-)
trial -1,-1,2,5  type 0021
Disambiguate in:  0(-1,-1)-(2,4) = 0 (-)
 25 23 24 26 43 24 23 25
 22 22 22 22 22 22 22 22
 44 44 44 44 44 44 44 44
 44 44 44 44 44 44 44 44
 44 44 44 44 44 44 44 44
 44 44 44 44 44 44 44 44
  0  0  0  0  0  0  0  0
  3  1  2  4 21  2  1  3
Disambiguate in:  0(-1,-1)-(2,5) = 0 (-)
 25 23 24 26 43 24 23 25
 22 22 22 22 22 22 22 22
 44 44 44 44 44 44 44 44
 44 44 44 44 44 44 44 44
 44 44 44 44 44 44 44 44
 44 44 44 44 44 44 44 44
  0  0  0  0  0  0  0  0
  3  1  2  4 21  2  1  3
trial 1,-1,-1,-1  type 1000
trial -1,-1,1,-1  type 0010
trial -1,-1,-1,-1  type 0000
trial 2,-1,-1,-1  type 1000
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
Parsed game start '[Event "RWBC Full2plies"]' (38)
Parsed PGNTag: [Event "RWBC Full2plies"]
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
Parsed PGNTag: [Site "ESPRESSO"]
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
Parsed PGNTag: [Date "2007"]
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
Parsed PGNTag: [White "X"]
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
Parsed PGNTag: [Black "Y"]
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
Parsed PGNTag: [Result "1/2-1/2"]
trial -1,-1,-1,-1  type 0000
trial -1,-1,-1,-1  type 0000
trial 1,-1,-1,-1  type 1000
recognized 'RWBC Full2plies' (-1) as variant normal
1298093 >first : new
random
1298093 >first : ics -
1298093 >first : level 40 3 0
1298093 >first : post
1298093 >first : hard
1298093 >first : easy
1298093 >first : ping 4
1298093 >first : force
trial -1,-1,-1,-1  type 0000
trial -1,-1,1,3  type 0021
Disambiguate in:  0(-1,-1)-(1,2) = 0 (-)
Disambiguate out: 0(1,1)-(1,2) = 0 (-)
Parsed b3 into b2b3
CoordsToAlgebraic, piece=0 (1,1)-(1,2) -
7 0 4 7 0 4 Legality test? b2b3
movetype=21, promochar=0=-
MateTest: K=1, my=16, his=16
move: b2b3
, parse: b3 (
)
trial -1,-1,3,5  type 0021
Disambiguate in:  22(-1,-1)-(3,4) = 0 (-)
Disambiguate out: 22(3,6)-(3,4) = 0 (-)
Parsed d5 into d7d5
CoordsToAlgebraic, piece=22 (3,6)-(3,4) -
7 0 4 7 0 4 Legality test? d7d5
movetype=21, promochar=0=-
MateTest: K=1, my=16, his=16
move: d7d5
, parse: d5 (
)
trial 1,-1,-1,-1  type 1000
Parsed game end: 1/2
GameEnds(27, , 3)
ForwardInner(2), current 0, forward 2
PauseEvent(): pausing 0
1298093 >first : usermove 1298093 >first : b2b3
1298093 >first : usermove 1298093 >first : d7d5
LoadGame(): on exit, gameMode 7

[H.G.Muller]

Hmm, I switched debug file when TwoMachinesEvent was called to start a game. Apparently when playing from an opening file, the game is loaded even before that. I will look into it.

I did not think about the TLCS consequences. Indeed I don't consider TLCS/V a WinBoard core component, as it is not able to handle most of the variants. This is why I developed the other system. But I admit it is not as good as TSCV yet, (in cases where TSCV would work).

Renaming the file afterwards should not be too much of a problem.; what I do now is calculate what the name should be in the next game, and compare it to what it was, and if they differ close the old file, and open the new. It would be just a small change to keep track of the names the same way, but after closing the old file, rename it to the old name, and then always open a file with a fixed name. I guess I would have to add something for after the end of the last game. But perhaps I could displace the entire code to the GameEnds routine, that should solve the problem with the loadGameFile at the same time.

The question is, would TLCS be able to handle it if the file was moved away, and one of the same name re-opened. Or does it really need it to remain the same file?

[Guenther Simon]

...


The question is, would TLCS be able to handle it if the file was moved away, and one of the same name re-opened. Or does it really need it to remain the same file?

Actually I don't remember anymore it is too long ago for me. Hopefully Olivier of Fonzy or someone else can answer this.

Guenther

[Olivier Deville]

...


The question is, would TLCS be able to handle it if the file was moved away, and one of the same name re-opened. Or does it really need it to remain the same file?

Actually I don't remember anymore it is too long ago for me. Hopefully Olivier of Fonzy or someone else can answer this.

Guenther

I think it shouldn't be a problem.

Olivier

[H.G.Muller]

OK, after some more thinking I also come to the conclusion it should not be a problem. Because now you are using PSWBTM to play the tourney, and that starts up a new WinBoard which then creates own debug file anyway, overwriting the previous one (if it hadn't been moved away).

[H.G.Muller]

I uploaded a new trial version ( http://hgm.nubati.net/WinBoard-4.5TM.exe ). I equiped it with an extra option -serverFile where you can specify a sort of extra debug file (with a fixed name) that only logs engine communication. Except that at the start it fakes two StartChildProcess lines, so that you can see which engines were playing.

I hope that this will be enough for TLCS to work from. The file will be created for overwrite each time a nw tourney game starts.

[Guenther Simon]

Hi again HG,

I noticed it might be useful to add a list/log of running processes at the end or beginning of a debug file, this way it would
be easy to notice when something went wrong in an automatic tourney. (Or it might be possible to call a prog like ProcExplorer
from commandline making such logs after each game with the -afterGame flag.) What do you think about such an idea?

Guenther