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 <stevena...@gmail.com> 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 > >
------------------------------------------------------------------------------
_______________________________________________ Scidvspc-users mailing list Scidvspc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scidvspc-users
