Re: [Scidvspc-users] patch for chess960!

[Britton F. <bri...@gm...>]

I made a ticket for the setup board thing that Gregor found. It is an issue
where tcl somewhere decides that castling is not legal and changes any Q or
KQ or k or whatever into a dash before fen string is passed to c. I posted
a backtrace that shows it. Somebody else might could address it better than
me since I do not really know tcl. I'm thinking like just make it really
lenient like check only if k and r are on back ranks and which side. There
is actually 2 places in the interface but they might really be the same
thing, im not sure. One is doing setup board and pasting fen in the box and
the other is going to Edit -> Paste FEN

As far as the king +2, -2, the tcl doesn't need to care if it is legal or
not. If not legal, the c code will know and not let you do it anyway. You
can just find the nearest friendly rook on that side and pass that square
along with the king square and it should be taken care of from there.

You were saying something about it already handling normal chess. I think
the king +2,-2 in interface is the only thing left to where the end user
will not be able to tell the difference (aside from bugs, unfinished 960
stuff). It is kind of like a superset that includes normal chess

Another thing that cropped up that might be related to position Game *,
variations is that it is failing to read the ECO file in the beginning.
This was working lately, but maybe I messed it up again fixing something
else. I see there is a lot going on in general like you are saying. It
seems even just incrementing or decrementing a single move, the whole thing
iterates through tons of positions i guess trying to match positions in
books, etc. Some positions are created where I didn't really see the need
or the way to find a game to make its owner yet, or whether a game should
persist in being its owner. So some stuff I left alone so far and always
check for NULL when access position owner.

Just an idea that might make it easy on everybody: Is there a way for you
to make a branch from r2569 and let me commit only to that branch? Or have
the branch and I can give patches to be committed by somebody else to the
branch? Then that branch can be periodically merged with the trunk (or
rather the trunk merged back with the branch, keep 960 out of trunk). That
way anybody working on 960 branch can periodically svn up their read only
copy and stay a little saner. Like for example, if somebody else besides me
went in and did the K +2,-2 tcl stuff, it could be committed and then on my
end i can just svn up my working copy of the branch to get that. Also when
I submit a patch without a branch, I will be asking myself stuff like
"should i make a patch for r2569 that has already been patched once (or
more) or make a patch for totally unpatched r2569", like the patches will
start being on top of each other and we will be in confusion on how to
submit them or apply them. Just throwing that out there, not sure how much
of a pain that is to do.


On Wed, Aug 3, 2016 at 1:04 AM, Steve A <ste...@gm...> wrote:

>
> > Variations were giving me a major headache with the recursive function
> that now needs to stay on top of CurrentPos the whole time in and out of
> variations. I will look into that. I was actually overthinking it at first
> and messing it up, then i took out some code that i put in and thought i
> had it working with a little tweak but i guess it needs some more attention
> for subvariations(?) I will look at ticket
>
> I wonder if the position being tied to a game will ever give us headaches.
> This is the most novel thing you do.. And as positions are thrown around
> everywhere in Scid, we'll have to keep an eye on this.
> One thing comes to mind.. Games are always getting pushed and pulled of a
> stack.
> with sc_game_push. Just check this is not breaking anything.
>
> > I haven't yet done any setup board stuff yet. I can get to that. Should
> just be a matter of attaching a proper Game * to those positions wherever
> they are made.
>
> I can do that this weekend. Shouldnt be much work . Maybe just relaxing
> Castling sanity checks. Handling the king +-2 will be harder i think, but i
> should have time for it.
>
> > Just curious, if you guys are interested in the work and i keep
> producing, how would you guys handle it on the backend? Like make a branch
> at r2569 and keep putting this stuff there and then merge later from time
> to time? I can just keep a 2569 around for myself locally and make patches
> from that to give you if that works.
>
> I'm thinking just to keep it as a patch for a while, maybe posting a
> windows beta binary.
> Normally, merging patches isn't much of an issue nowadays.
> If it is solid,  we can inline it as an #ifdef, and a build configuration
> option,
> and post separate binaries for Scidvs960 (or whatever).
> Though it can handle normal chess... hard to say now whether it could ever
> become the only default code.
>
> Thanks
>
>