Arena protocol: moveerror

[Werner Schüle]

Hi,
in Arena Protocol I see following message:
*moveerror*start piece<0 and target piece<0 !Tf3xf5!

Anybody can help what this means?

Werner

35.171.295*1*Start calc, move no: 80
35.171.295-->1:position startpos moves e2e4 c7c5 g1f3 d7d6 d2d4 c5d4 f3d4 g8f6 b1c3 e7e6 g2g4 h7h6 h2h3 a7a6 f1g2 f8e7 c1e3 b8c6 d4c6 b7c6 e1g1 e8g8 f1e1 a8b8 b2b3 f6d7 d1d2 d7e5 a1d1 e5g6 a2a3 g6h4 g2h1 e6e5 f2f4 h6h5 f4f5 h5g4 h3g4 g8h7 c3a4 g7g6 e1f1 a6a5 f1f2 g6f5 g4f5 f8g8 g1h2 g8g7 f5f6 e7f6 d2d6 d8d6 d1d6 f6e7 d6c6 c8e6 a4c5 e7c5 c6c5 b8h8 f2f6 h4g6 h2g1 h7g8 h1f3 h8h3 g1f2 g6h4 c5e5 h3h2 f2e1 h2h3 e1e2 h4f3 f6f3 e6g4 e5f5 f7f6
35.171.295-->1:go wtime 663213 btime 685711 winc 0 binc 0 movestogo 40
35.171.327<--1:info depth 1 seldepth 2 nodes 13 nps 0 time 0 hashfull 994 score cp -255 pv f5a5
35.171.359<--1:info depth 1 seldepth 2 nodes 28 nps 0 time 0 hashfull 994 score cp 236 pv f5f6
35.171.359<--1:info depth 1 seldepth 2 nodes 120 nps 0 time 0 hashfull 994 score cp 236 pv f5f6
35.171.390<--1:info depth 2 seldepth 4 nodes 177 nps 0 time 0 hashfull 994 score cp 174 upperbound pv f5f6
35.171.420<--1:info depth 2 seldepth 4 nodes 348 nps 0 time 0 hashfull 994 score cp 174 pv f5f6
35.171.452<--1:info depth 3 seldepth 6 nodes 703 nps 0 time 0 hashfull 994 score cp 149 pv f5f6
35.171.452<--1:info depth 4 seldepth 9 nodes 1491 nps 0 time 0 hashfull 994 score cp 174 pv f5f6 h3h2 e2d3 g4f3 f6f3
35.171.452<--1:info depth 5 seldepth 10 nodes 4678 nps 0 time 0 hashfull 994 score cp 185 pv f5f6 h3h2 e2d3 g4f3 f6f3
35.171.483<--1:info depth 6 seldepth 12 nodes 7720 nps 0 time 0 hashfull 994 score cp 185 pv f5f6 h3h2 e3f2 g4f3 e2f3 g7f7 e4e5 f7g7 e2f2
35.171.515<--1:info depth 7 seldepth 14 nodes 14237 nps 0 time 0 hashfull 994 score cp 145 upperbound pv f5f6 h3h2 e3f2 g4f3 e2f3 g7f7 e4e5 f7g7 e2f2
35.171.515<--1:info depth 7 seldepth 14 nodes 15202 nps 0 time 16 hashfull 994 score cp -55 upperbound pv f5f6 h3h2 e3f2 g4f3 e2f3 g7f7 e4e5 f7g7 e2f2
35.171.545<--1:info depth 7 seldepth 14 nodes 22076 nps 0 time 16 hashfull 994 score cp 89 pv c2c4 g4f5 e4f5 g7g2 e3f2 h3h2 e2e3 g8g7 c4c5
35.171.578<--1:info depth 7 seldepth 14 nodes 26032 nps 0 time 16 hashfull 994 score cp 89 pv c2c4 g4f5 e4f5 g7g2 e3f2 h3h2 e2e3 g8g7 c4c5
35.171.608<--1:info depth 8 seldepth 16 nodes 28775 nps 0 time 16 hashfull 994 score cp 49 upperbound pv c2c4 g4f5 e4f5 g7g2 e3f2 h3h2 e2e3 g8g7 c4c5
35.171.640<--1:info depth 8 seldepth 16 nodes 39138 nps 0 time 16 hashfull 994 score cp 50 upperbound pv a3a4 h3f3 f5f3 g7b7 e2f2 h3h2 e2e3 g8g7 c4c5
35.171.670<--1:info depth 8 seldepth 16 nodes 99212 nps 0 time 47 hashfull 994 score cp 75 pv e3d4 g4f5 e4f5 g7e7 f3e3 g8f7 e3f2 g8f7 f2e1 h3h2 e2d3 h2h5
35.171.703<--1:info depth 8 seldepth 16 nodes 100975 nps 0 time 47 hashfull 994 score cp 75 pv e3d4 g4f5 e4f5 g7e7 f3e3 g8f7 e3f2 g8f7 f2e1 h3h2 e2d3 h2h5
35.171.733<--1:info depth 9 seldepth 18 nodes 199644 nps 0 time 94 hashfull 994 score cp 77 pv e3d4 h3f3 f5f3 g7h7 f3e3 g8f7 e3f2 g8f7 f2e1 h3h2 e2d3 h2h5
35.171.765<--1:info depth 10 seldepth 20 nodes 438265 nps 0 time 204 hashfull 994 score cp 98 pv e3d4 g4f5 e4f5 g7e7 e2f2 h3h5 d4f6 e7f7 f6d4 h5f5 f3f5 f7f5 f2e3
35.171.795<--1:info depth 11 seldepth 22 nodes 891376 nps 0 time 375 hashfull 994 score cp 116 pv e3d4 g4f5 e4f5 g7e7 e2f2 h3h2 f2g3 h2h6 c2c4 e7c7 f3f5 f7f5 f2e3
35.171.795*moveerror*start piece<0 and target piece<0 !Tf3xf5!
35.171.828<--1:info depth 12 seldepth 24 nodes 1152853 nps 0 time 485 hashfull 994 score cp 76 upperbound pv e3d4 g4f5 e4f5 g7e7 e2f2 h3h2 f2g3 h2h6 c2c4 e7c7 f3f5 f7f5 f2e3
35.171.828*moveerror*start piece<0 and target piece<0 !Tf3xf5!

[Guenther Simon]

Hi Werner,

I hope there is no Arena protocol Actually you meant to write 'Arena debug file'. The protocol
used in your debug snippet clearly is UCI of course.
I could find the reason why Arena sent that message, but it is unclear to me why it _needed_
to send this error message, because IMO it is not the GUIs business to check even the PVs
for legality and if Arena had stopped the game here(had it?) I would say it is also a bug in Arena.

Ok, back to the reason, despite you had not posted the PGN nor a FEN I was able to
feed the UCI moves input and then we get this position:

6k1/6r1/5p2/p4R2/4P1b1/PP2BR1r/2P1K3/8 w - - 0 41



From here reading the PVs for depth 11 and 12, both times the program in question, started
to send illegal moves at the end of the PVs starting with Rxf5(f3f5 in your debug), when f5 was Whites own pawn

35.171.795<--1:info depth 11 seldepth 22 nodes 891376 nps 0 time 375 hashfull 994 score cp 116 pv e3d4 g4f5 e4f5 g7e7 e2f2 h3h2 f2g3 h2h6 c2c4 e7c7 f3f5 f7f5 f2e3

41. Bd4 Bxf5
42. exf5 Re7+
43. Kf2 Rh2+
44. Kg3 Rh6
45. c4 Rc7
46. Rxf5?????? and so on...

Guenther

[Werner Schüle]

Fabelhaft!!

Thanks a lot, Guenther!
it was of course the Arena engine debug file and the engine is Tornado 3.19 x64 2CPU. The game does not stop - but later the engine crashes.

I will send your answer to the author.

Best wishes

Werner
(edited)

[Christopher Conkie]

Fabelhaft!!

Thanks a lot, Günther
it was of course the Arena engine debug file and the engine is Tornado 3.19 x64 2CPU. The game does not stop - but later the engine crashes.

I will send your answer to the author.

Best wishes

Werner

Guenther is correct. Engin was having a few problems exactly like this recently Werner.

I'm sure he will be glad to see the report of your problem.

Regards

Christopher

[Roger Brown]

Guenther is correct. Engin was having a few problems exactly like this recently Werner.

I'm sure he will be glad to see the report of your problem.

Regards

Christopher

Hello Christopher Conkie,

Guenther is usually correct but that causes me to ask a couple of questions.

In such a case as the one above, would Arena stop the game? I mean, taking your own man is considered cannibalistic to say nothing of illegal.

Guenther said that if Arena did that (stop the game), it would be a bug in Arena. Why? I thought that the gui should decide that the position on the board arose out an illegal move and decide in favour of the non-offending engine.

I think in real life if you make an illegal move that the arbiter may restore the board back to its state before the illegal move was made and the game resumes but I do not think that Arena can - or should - do that.

Your thoughts?

Later.

[Christopher Conkie]

Guenther is correct. Engin was having a few problems exactly like this recently Werner.

I'm sure he will be glad to see the report of your problem.

Regards

Christopher

Hello Christopher Conkie,

Guenther is usually correct but that causes me to ask a couple of questions.

In such a case as the one above, would Arena stop the game? I mean, taking your own man is considered cannibalistic to say nothing of illegal.

Guenther said that if Arena did that (stop the game), it would be a bug in Arena. Why? I thought that the gui should decide that the position on the board arose out an illegal move and decide in favour of the non-offending engine.

I think in real life if you make an illegal move that the arbiter may restore the board back to its state before the illegal move was made and the game resumes but I do not think that Arena can - or should - do that.

Your thoughts?

Later.

I suppose it would depend whether you have legality switched on or off in Arena.

Sooner ( always better )

Christopher

[Guenther Simon]

Guenther is correct. Engin was having a few problems exactly like this recently Werner.

I'm sure he will be glad to see the report of your problem.

Regards

Christopher

Hello Christopher Conkie,

Guenther is usually correct but that causes me to ask a couple of questions.

In such a case as the one above, would Arena stop the game? I mean, taking your own man is considered cannibalistic to say nothing of illegal.

Guenther said that if Arena did that (stop the game), it would be a bug in Arena. Why? I thought that the gui should decide that the position on the board arose out an illegal move and decide in favour of the non-offending engine.

I think in real life if you make an illegal move that the arbiter may restore the board back to its state before the illegal move was made and the game resumes but I do not think that Arena can - or should - do that.

Your thoughts?

Later.

Hi Roger,

You mixed the real game and the PV it seems. The move in question _never was made_ on the board,
only on the internal board of Tornado far ahead in the future in certain depths of the PV of the engine.
I know several programs which can spit out illegal moves during the PVs, but never make an illegal
move on the board itself(and no crashing too).
Of course a GUI, or the opponent should stop a game if an illegal move _appears on the real board_.
BTW I am not 100% sure anymore the message about the move error came from Arena, but the missing
'<--' symbol for pipe output _from_ the engine made me make this assumption. There is a chance it came from
Tornado itself and because of non standard output it was displayed different in the debug file, but in the end
only an Arena expert can answer this.

Guenther

[Guenther Simon]

Guenther is correct. Engin was having a few problems exactly like this recently Werner.

I'm sure he will be glad to see the report of your problem.

Regards

Christopher

Hello Christopher Conkie,

Guenther is usually correct but that causes me to ask a couple of questions.

In such a case as the one above, would Arena stop the game? I mean, taking your own man is considered cannibalistic to say nothing of illegal.

Guenther said that if Arena did that (stop the game), it would be a bug in Arena. Why? I thought that the gui should decide that the position on the board arose out an illegal move and decide in favour of the non-offending engine.

I think in real life if you make an illegal move that the arbiter may restore the board back to its state before the illegal move was made and the game resumes but I do not think that Arena can - or should - do that.

Your thoughts?

Later.

I suppose it would depend whether you have legality switched on or off in Arena.

Sooner ( always better )

Christopher

Hi Christopher,

I think this is incorrect, because legality checking normally means checking of moves
going to be made Here the move was far from being executed it just flashed
up in the distance of a PV. (and as I wrote in another posts several programs
display sometimes illegal moves during their PVs, despite always performing
correct moves on the board) There seems to be a missunderstanding with Roger.

Guenther

[Christopher Conkie]

Hi Christopher,

I think this is incorrect, because legality checking normally means checking of moves
going to be made Here the move was far from being executed it just flashed
up in the distance of a PV. (and as I wrote in another posts several programs
display sometimes illegal moves during their PVs, despite always performing
correct moves on the board) There seems to be a missunderstanding with Roger.

Guenther

Yes, I agree. Was talking to Engin about it just now and the illegal move is in the pv not on the board .

The problem does seem to be with Tornando although. It is quite confusing as it looks like it's Arena but we think not.

At this moment we are trying to find out if it's the compiler Engin used which was VS 2010 beta x64).

Have you ever had problems with VS 2010 x64 compiles? It seems that these crashes started after 3.17 when he made the x64 version with that.

It seem it's exclusively an x64 problem as well.

3.18 and 3.19 are those affected.

I bet it's something simple. We are just trying to help him resolve it.

Any ideas would be really helpful.

Regards

Christopher

[Roger Brown]

I suppose it would depend whether you have legality switched on or off in Arena.

Sooner ( always better )

Christopher

Hello Christopher,

I suppose it would depend on whether you were the executioner or the victim, hmmmm?



Thanks for the info.

Sooner (than) Later.

[Roger Brown]

Hi Roger,

You mixed the real game and the PV it seems. The move in question _never was made_ on the board,
only on the internal board of Tornado far ahead in the future in certain depths of the PV of the engine.
I know several programs which can spit out illegal moves during the PVs, but never make an illegal
move on the board itself(and no crashing too).
Of course a GUI, or the opponent should stop a game if an illegal move _appears on the real board_.
BTW I am not 100% sure anymore the message about the move error came from Arena, but the missing
'<--' symbol for pipe output _from_ the engine made me make this assumption. There is a chance it came from
Tornado itself and because of non standard output it was displayed different in the debug file, but in the end
only an Arena expert can answer this.

Guenther

[Slaps forehead several times.]

Thanks for the clarification Guenther. When will I learn to stay out of sophisticated conversation?

Later.

[Werner Schüle]

At this moment we are trying to find out if it's the compiler Engin used which was VS 2010 beta x64).
Have you ever had problems with VS 2010 x64 compiles? It seems that these crashes started after 3.17 when he made the x64 version with that.
It seem it's exclusively an x64 problem as well.
3.18 and 3.19 are those affected.
I bet it's something simple. We are just trying to help him resolve it.
Any ideas would be really helpful.
Regards
Christopher

Hi, thanks too Christopher,
I would be too very interested in a solution as I have here following situation:
Tornado 3.19a x64 2CPU crashes under Windows XP 64bit here; PC is a Core2Quad

Tornado 3.19a x64 2CPU runs under Windows VISTA 64bit on my Core2Duo without crashes
Tornado 3.19a x64 1CPU runs under Windows XP 64bit without crashes
Tornado 3.19a w32 2CPU runs under Windows XP 64bit without crashes

...and Engin has no problems with the engine....

best wishes
Werner

[Engin]

hello,

to moveerror:

i fully agree with Simon, the PV outputs of an engine is most confuse and must not be all legal, that is not so important for the game on the board, only the move that the engine make on the board is important, the GUI have no the right to stop the game because on the PV outputs they are illegal moves.

if the engine make illegal moves on the board that is the problem, but my engine did never made such illegal moves on board.

that Arena is prove also PV moves for legality is an bug from Arenas it self, not from engines.


to chrashes from Tornado:

since from 3.17 i have to compiled an x64 version with the vs 2010 beta, well i think that is not the problem of the compiler, that was my fault too, i fixed there bugs with SMP and Egtb look ups, that the threads are sometimes crashed and hanging during the game, then lost on time, that happen only on Olivier Openwar only, but not on Chesswar with 1 cpu.

Werner said me he have an "exception" with x64 version, on my mashine i get never such attention window, on my mashine Quad q8200 4 GB ram and Vista x64 i see never of problems so far, and testing on my older dual core amd 3800+ with Windows xp x64 had also no problems too.

the newest version 3.19a seem now for without problems, but werner told me he have problems continue. i dont know what he made wrong...

if there is an x64 problem or smp or tb errors, or if this the vs 2010 beta bug, i dont know....

if anybody had also problems with the vs 2010 beta and x64 please tell me that.

i am boring last days now and will going to holiday on sunday this weekend, pradu want to play the ACCA tournament for me there.

i have enough from programing now and i will work again if i am back from holidays.

best wishes to all and have some nice summer days !
Engin

[Christopher Conkie]

At this moment we are trying to find out if it's the compiler Engin used which was VS 2010 beta x64).
Have you ever had problems with VS 2010 x64 compiles? It seems that these crashes started after 3.17 when he made the x64 version with that.
It seem it's exclusively an x64 problem as well.
3.18 and 3.19 are those affected.
I bet it's something simple. We are just trying to help him resolve it.
Any ideas would be really helpful.
Regards
Christopher

Hi, thanks too Christopher,
I would be too very interested in a solution as I have here following situation:
Tornado 3.19a x64 2CPU crashes under Windows XP 64bit here; PC is a Core2Quad

Tornado 3.19a x64 2CPU runs under Windows VISTA 64bit on my Core2Duo without crashes
Tornado 3.19a x64 1CPU runs under Windows XP 64bit without crashes
Tornado 3.19a w32 2CPU runs under Windows XP 64bit without crashes

...and Engin has no problems with the engine....

best wishes
Werner

OpenWar is also played using a Quad (with Windows xp 64 but this might be irrelevant).

This is the exact same scenario where Tornado crashes (sometimes) for Olivier when using Winboard as happened to you in Arena.

It is the only common denominator.........

Does Tornado crash on the Quad using 1 CPU Werner?

Regards

Christopher

[Werner Schüle]

OpenWar is also played using a Quad (with Windows xp 64 but this might be irrelevant).
This is the exact same scenario where Tornado crashes (sometimes) for Olivier when using Winboard as happened to you in Arena.
It is the only common denominator.........
Does Tornado crash on the Quad using 1 CPU Werner?
Regards
Christopher

Hi Christopher,
Tornado does not crash using 1CPU. I have already played 24 games on the quad and 45 games on AMD 64x2.

Using 2 CPUs it continues crashing here with and without tb-access e.g. inside different GUIs (64bit version).

best wishes
Werner

[Werner Schüle]

Gerhard has had an idea:

perhaps a newer dll is needed to run a program made with this compiler and VISTA has this dll and XP not??

PS: 2 other tester have confirmed the crashes, so I am sure its not my pc...
best wishes
Werner