SjaakII also has a work-around for that in that you can tell it to accept an arbitrary string as a variant name it understands.hgm wrote:This is the problem with engine-defined variants: there is no guarantee that they use the same name for the same variant.
SjaakII 1.0 RC1
Moderator: Ras
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: SjaakII 1.0 RC4
-
hgm
- Posts: 28505
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: SjaakII 1.0 RC4
I noticed that option, and first I wanted to mention it in this context. But when I tried to explain it I was not sure how it could work:
XBoard would never send a variant name that the engine did not 'declare' in its variants feature. And these are only sent at startup. So you won't have the opportunity to set that option before Sjaak already told XBoard it did not play the variant.
For an option like this to work it seems there should be a change in the way XBoard uses the protocol. Now it is not prepared to get an error response on the variant command. I guess this is an omission anyway, as for v1 engines it cannot know what the engine supports, and XBoard assumes it plays only normal, or the variant the user requests in the XBoard -variant command-line option.
The problem is that it is not so easy to recover when an engine refuses a variant, when you have already switched to it. (Switching variant erases memory of an initial position set through an external file, and the pieceToCharTable. So XBoard checks already before switching variant whether the switch would be allowed, and only starts to send things to the engine after it switched. So it might not be possible to switch back to the old variant.)
I guess the user can fool XBoard with the -first/secondFeatures option into make it think the engine has said it supports a certain variant. But that you would have to install the engine with such an option sort of spoils any advantage of having it as an interactive option. It would be better then to let the engine accept a command-line option to accept the variant (and mention it in the variants feature). This is what I do in UCI2WB, when it has to be used for other variants than Xiangqi/Shogi/Chess. E.g. "uci2wb -var seirawan schess.exe".
XBoard would never send a variant name that the engine did not 'declare' in its variants feature. And these are only sent at startup. So you won't have the opportunity to set that option before Sjaak already told XBoard it did not play the variant.
For an option like this to work it seems there should be a change in the way XBoard uses the protocol. Now it is not prepared to get an error response on the variant command. I guess this is an omission anyway, as for v1 engines it cannot know what the engine supports, and XBoard assumes it plays only normal, or the variant the user requests in the XBoard -variant command-line option.
The problem is that it is not so easy to recover when an engine refuses a variant, when you have already switched to it. (Switching variant erases memory of an initial position set through an external file, and the pieceToCharTable. So XBoard checks already before switching variant whether the switch would be allowed, and only starts to send things to the engine after it switched. So it might not be possible to switch back to the old variant.)
I guess the user can fool XBoard with the -first/secondFeatures option into make it think the engine has said it supports a certain variant. But that you would have to install the engine with such an option sort of spoils any advantage of having it as an interactive option. It would be better then to let the engine accept a command-line option to accept the variant (and mention it in the variants feature). This is what I do in UCI2WB, when it has to be used for other variants than Xiangqi/Shogi/Chess. E.g. "uci2wb -var seirawan schess.exe".
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: SjaakII 1.0 RC4
Well, the option is saved, so restarting works anyway (SjaakII sends the name you specify as a variant it understands).
I think I also send "done=0" to resend the options if it is changed, but I'm not entirely sure about that (if I don't it's a bug). I do the same thing when you load a variant configuration file, or toggle the option to list user-defined variants before buil-in variants. It seems to work there.
EDIT: good idea about the command-line option though.
I think I also send "done=0" to resend the options if it is changed, but I'm not entirely sure about that (if I don't it's a bug). I do the same thing when you load a variant configuration file, or toggle the option to list user-defined variants before buil-in variants. It seems to work there.
EDIT: good idea about the command-line option though.
-
hgm
- Posts: 28505
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: SjaakII 1.0 RC4
Ah, OK. I had not realized Sjaak II had persistent options. And the done=0 trick should indeed make it work.
In fact it would probably already work if you simply resent the variants feature. The protocol specs only promise this for 'myname', I think, but in XBoard there actually is no checking at all whether features are received at startup or later. They just overwrite the previous setting. Except for option features, as these go into a list, and I was too lazy to check if a received one already was in the list, so it could be overwritten. And it seemed better to allow deletion of options as well, so I invented the done=0 trick instead.
Perhaps I should explicitly mention in the specs that the variants feature can be resent at any time, to add engine-defined variants. I don't expect this to give any back-ward compatibility problems, as other interfaces would not support engine-defined variants.
In fact it would probably already work if you simply resent the variants feature. The protocol specs only promise this for 'myname', I think, but in XBoard there actually is no checking at all whether features are received at startup or later. They just overwrite the previous setting. Except for option features, as these go into a list, and I was too lazy to check if a received one already was in the list, so it could be overwritten. And it seemed better to allow deletion of options as well, so I invented the done=0 trick instead.
Perhaps I should explicitly mention in the specs that the variants feature can be resent at any time, to add engine-defined variants. I don't expect this to give any back-ward compatibility problems, as other interfaces would not support engine-defined variants.
-
myfish
- Posts: 131
- Joined: Sat Feb 07, 2015 3:17 pm
Re: SjaakII 1.0 RC4
http://www.myfishcasting.com/shogi/imag ... g-tori.txthgm wrote:That link is broken (404: file not found)
Right Click / Save As
-
hgm
- Posts: 28505
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: SjaakII 1.0 RC4
Still no luck...
-
myfish
- Posts: 131
- Joined: Sat Feb 07, 2015 3:17 pm
Re: SjaakII 1.0 RC4
Odd that. It is most certainly there.hgm wrote:Still no luck...
http://www.myfishcasting.com/shogi/xboa ... g-tori.zip
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: SjaakII 1.0 RC4
I can download the zip file, but the file inside it containsmyfish wrote:Odd that. It is most certainly there.hgm wrote:Still no luck...
http://www.myfishcasting.com/shogi/xboa ... g-tori.zip
Code: Select all
<!-- SHTML Wrapper - 404 Not Found -->
<!DOCTYPE html>
<html>
<head>
<title>404 Not Found</title>
<meta name="revisit-after" content="10">
<meta name="ROBOTS" content="NOINDEX, NOFOLLOW">
<script type="text/javascript" src="http://cdn.dsultra.com/js/registrar.js"></script>
<link href="http://cf.bluehost-cdn.com/media/shared/general/homelayout.css" rel="stylesheet" type="text/css">
<link rel="stylesheet" href="http://cf.bluehost-cdn.com/media/shared/general/_bh/homestyle.css" type="text/css">
<style>
body{
margin:25px;
}
.t1{
color:#000000;
font-family: Arial, Helvetica, sans-serif;
font-size:14px;
}
.t2{
color:#3d3d3d;
font-family: Arial, Helvetica, sans-serif;
font-size:10px;
white-space:nowrap;
}
.icontent {
width: 1025px;
height: 700px;
border: none;
margin-top: 4px;
margin-bottom: 4px;
}
h1 {
font-size: 18px;
display: block;
}
h2 {
font-size: 16px;
}
ul {
margin-left: 34%
}
</style>
</head>
<body bgcolor=white>
<div style="border: solid 2px;border-color: #033B73;padding: 0px;width: 1065px;margin: 0 auto;">
<table cellpadding="0" cellspacing="0" border="0" width="1065">
<tr>
<td colspan="2" class="topheading">
<table cellpadding="0" cellspacing="0" border="0"><tr>
<td style="padding-left:25px;width:205px;height:90px"><a href="http://www.bluehost.com/"><img src="http://cf.bluehost-cdn.com/media/shared/general/_bh/logo.gif" width="178" height="39" alt="bluehost" border="0"></a></td>
<td style="text-align:left">Affordable, Reliable<br />Web Hosting Solutions.</td>
</tr></table>
</td>
</tr>
</table>
<div style="text-align: center">
<h1>404 Error File Not Found</h1>
<h2> The page you are looking for might have been removed, <br />had its name changed, or is temporarily unavailable.</h2>
<iframe frameborder="0" scrolling="no" src="about:blank" id='ad_frame' class="icontent"></iframe>
<script type="text/javascript">registrar_frameset({a_id: 143209, drid: "as-drid-2578124767373827", frame: "ad_frame"});</script>
<p><a href="http://www.bluehost.com">Web Hosting</a> provided by Bluehost.com</p>
</div>
</div>
</body>
</html>
-
myfish
- Posts: 131
- Joined: Sat Feb 07, 2015 3:17 pm
Re: SjaakII 1.0 RC4
OK, something is weird here. Will fix it.
-
myfish
- Posts: 131
- Joined: Sat Feb 07, 2015 3:17 pm
Re: SjaakII 1.0 RC4
http://www.myfishcasting.com/shogi/tori-debug.txt.zip
It seems, the act of me making the original xboard-debug file a 'txt' file screwed it up.
Emacs would open it but nothing else would recognise it.
So, I copy/pasted the contents of xboard-debug to a 'new' txt file and saved as utf-8.
I've not encountered this problem before, sorry guys.
It seems, the act of me making the original xboard-debug file a 'txt' file screwed it up.
Emacs would open it but nothing else would recognise it.
So, I copy/pasted the contents of xboard-debug to a 'new' txt file and saved as utf-8.
I've not encountered this problem before, sorry guys.