Chess game

[FB_Numpty]

Hi frisian

I have (hopefully) solved the castling problem, I added code that store and place back the values of w_cas and b_cas.

Good work, seems to be case - latest version now solves 'KiwiPete' perft test I posted previously - interesting fix references w_cas & b_cas which are the actual castling rights - from that test failure it seemed a problem with the castling permissions in search (ie w_casflags etc) - anyway now all seems to work fine.

I have also replaced the incheck() and attack() routines it takes 2k extra but is much faster then the old code.

Nice code!

If you have time you should have a look to at the make_move and unmake_move routines, unmake "unmakes" more things than "make" makes.

I've had a look but not sure what you mean here - what is the problem?

I also came across a problem with the 3-fold repetition routine.

Yes, well spotted - there is a small problem in some cases (don't know if you noticed - I never included checking for castling and ep conditions in the repetition tests - 3 fold rep requires everything in board state to be the same. 3 Fold repetition is notoriously difficult to get right for computer programs (and GUI in some cases for that matter) and many seem to get it wrong and/or interpret it differently. (Arena sometimes flags Numpty for this - I think wrongly). The winboard protocol handling conditions were updated to better clarify how this should be handled after I developed the code in Numpty - it was always something I meant to go back to and review - so perhaps I should do now.

New version of my version of NoMega

Many thanks for the latest version - certainly seems to be a little faster (c10%) - I have been busy this week but managed to give it 500 game also against original Numpty DD - results not so good this time (though 500 is still small sample):

1: Numpty_DD 253.5/500
2: Nomega140318 246.5/500

14 time losses - 11 for Nomega140318 and 3 for Numpty_DD (these were for 3 rep issue above). There was also 1 loss by Nomega due to rule infraction - game is below

[Event "New nomega test6"]
[Site "MY-PC"]
[Date "2014.03.19"]
[Round "88"]
[White "Nomega140318"]
[Black "Numpty_DD"]
[Result "0-1"]
[BlackElo "2200"]
[ECO "D00"]
[Opening "Queen's Pawn"]
[Time "10:48:08"]
[Variation "2.c3 Nf6 3.Bf4"]
[WhiteElo "2200"]
[TimeControl "60/60:60/60:60/60"]
[Termination "rules infraction"]
[PlyCount "62"]
[WhiteType "program"]
[BlackType "program"]

1. d4 Nf6 2. c3 d5 3. Bf4 Bf5 4. Qb3 Qc8 5. e3 e6 6. Nf3 Bd6 7. Bb5+ Nbd7
8. Bxd6 cxd6 9. e4 Ke7 10. exf5 exf5 11. O-O Rd8 12. Nbd2 Kf8 13. c4 dxc4
14. Nxc4 d5 15. Qb4+ Kg8 16. Nd6 a5 17. Nxc8 axb4 18. Ne7+ Kf8 19. Nxf5 Ra5
20. Bd3 Rda8 21. Bb1 b3 22. a3 Kg8 23. Nd6 R5a7 24. Nd2 Rd8 25. Nf5 Re8 26.
Bd3 Raa8 27. Nd6 Re6 28. Nxb7 Rb8 29. Nc5 Reb6 30. Rfe1 h5 31. Re7 Kf8
{Arena Adjudication. Illegal move!} 0-1

Not yet had chance to work this game yet and find the reason for the termination.

[frisian]

Many thanks for the latest version - certainly seems to be a little faster (c10%) - I have been busy this week but managed to give it 500 game also against original Numpty DD - results not so good this time (though 500 is still small sample):

1: Numpty_DD 253.5/500
2: Nomega140318 246.5/500

14 time losses - 11 for Nomega140318 and 3 for Numpty_DD (these were for 3 rep issue above). There was also 1 loss by Nomega due to rule infraction - game is below

I don't think that result is that bad, (I assume that they had 60 seconds for 60 moves) the speed difference does not make that great impact if the timing is very small. Since both have the same evaluation routine there not much difference between them. If the time per move gets greater NoMega gets better (gets a extra depth). I have seen Nomega do worse in tournament with a max depth of 4 per move. Also the bookmoves play a role in this. Sometimes it looks to be just luck who gets the best start.

If you have time you should have a look to at the make_move and unmake_move routines, unmake "unmakes" more things than "make" makes.[

I've had a look but not sure what you mean here - what is the problem?

At the end of the unmake_move routine you adjust the number of Bishop's and Knight's in case of a promotion but in the make_move routine these value's don't get changed.

I will look into the problem of losses due to timing and the illegal move that could take time.

[FB_Numpty]

I don't think that result is that bad, (I assume that they had 60 seconds for 60 moves) the speed difference does not make that great impact if the timing is very small. Since both have the same evaluation routine there not much difference between them. If the time per move gets greater NoMega gets better (gets a extra depth). I have seen Nomega do worse in tournament with a max depth of 4 per move. Also the bookmoves play a role in this. Sometimes it looks to be just luck who gets the best start.

Agreed, and it is also difficult to form a judgement with games influenced by time loss and illegal moves. But latest Nomega is 20% faster than Numpty DD which other things being equal should be worth about 15 elo (which should be measurable - and self play tends to magnify elo differences compared to using a balanced set of opponents). I ran 100 games at 40 moves in 3 minutes (again not statistically valid in its own right) - no time losses or illegal moves this time and Numpty DD won this 54:46. Nomega version is clearly searching faster so there may be some something else to look at in due course.

At the end of the unmake_move routine you adjust the number of Bishop's and Knight's in case of a promotion but in the make_move routine these value's don't get changed.

Ok, thanks again I will have another look at this.

I will look into the problem of losses due to timing and the illegal move that could take time.

Rather than duplicate effort looking at the same problem, I'll leave you to do this then.

[frisian]

FB_Numpty

in your code you have the following code to reduce the number of root moves.

Code: Select all

' above 3 ply following lines attempt to implement some crude reductions in root moves searched at deeper ply based on score
if it_depth = 3 and score - best_score < -500 then root = root - 1
if it_depth = 4 and score - best_score < -275 then root = root - 1
if it_depth = 5 and score - best_score < -200 then root = root - 1 '225

if it_depth = 6 and score - best_score < -175 then root = root - 1'200

if it_depth > 6 and score - best_score < -150 then root = root - 1 '175


this is the code that sends the move to winboard/Arena

Code: Select all

IF WinboardMode = 1 and root <> 0 THEN
        conv_clock_move_no =  conv_clock_move_no + 1
        SendCommand ("move " + lcase(CompMoveFrom$ + CompMoveTo$ + Prom_Piece$))
    END IF

Question what will happen if root = 0. Answer no move is send and winboard/Arena wait to the time elaps and declare a time forfeit (oddly enoff a move is entered into the move list by the program).
Solution make sure that root never can be 0 by adding the following test.

If root > 1 then
If it_depth = …
...
End if

This will insure that there is at least one root move left.

But there was a second situation that triggered a time forfeit, some one that occurred less frequent the previous one. When the MoveFrom and MoveTo where 0 then “move '/'/” was send to winboard/Arena wich in turn did not react because it was an incorrect move and kept waiting for a “correct” move.

Code: Select all

if depth = 1 and root_sort(1) - root_sort(2) > 250 then
    B_M_To_easy_move =  B_M_To
    B_M_From_easy_move =  B_M_From
end if

if depth = 4 and root_sort(1) - root_sort(2) > 250 and Move_list(depth+1,1,1) = B_M_From_easy_move and Move_list(depth+1,1,2) = B_M_To_easy_move then it_depth = max_depth

Are B_M_To and B_M_From equal to move_list_root(depth,1,x), it can but it is not very likely.
Better change it to
B_M_To_easy_move = move_list_root(depth,1,1)
B_M_From_easy_move = move_list_root(depth,1,2)

After 537 games only 4 time forfeits, all from Numpty_DD (playing with white) at least one in a lost position. A second one it had still 4 possible squares where it could move it king to.

-----------------Nomega-----------------
Nomega - Numpty_DDorg : 277,5/537 245-227-65 (...) 52% +14
-----------------Numpty_DDorg-----------------
Numpty_DDorg - Nomega : 259,5/537 227-245-65 (...) 48% -14

The percentage is very stable for last few hundred games.

Will run the tournament longer to see how things go.

[FB_Numpty]

Thanks again frisian, well spotted - some of these things happen so rarely it can be difficult to identify not only the problem but the cause.

In hindsight, the issue with root = 0 would explain the odd instance where Numpty would lose on time in the endgame in cases with few moves available - I had thought that with few available moves, search depth was obviously much greater and Numpty was just timing out without completing an iteration. In reality this looks like it was now the result of root being reduced to 0 and of course no move being recorded. This issue influenced my settings for the conditions to terminate the in-search so I may need to recheck this also.

Your longer test results look promising and now are more in line with what I would expect given the speed increase in the code (what are the latest results?). From your post, it seems the latest Nomega hasn't lost any games on time so presumably the above fixes have sorted this also in the newer version. Did you get to the bottom of the illegal move in my previous post or do you want me to look at this?

In terms of the latest version, this is now looking pretty stable, what is your thinking about further development and improvement? From my perspective, sorting the gen gcc opimisation issue would be the biggest gain - not only in terms of the speed increase itself, but also because, the material increase that seems possible, would also allow scope for better and more sophisticated evaluation (eg esp king safety). I always found in testing that given the shallow search depths, adding additional knowledge wasn't productive as it couldn't compensate for the resulting slow down in speed (and strength) from adding it. Might be a different issue if the average search depth was at least one ply more. Of course, the elephant in the room is Numpty's rudimentary search itself, more sophisticated move ordering (well, even some ordering as there isn't any beyond the root!) and further search enhancements (eg killer moves and null move pruning) would have a big impact. But some of these changes I think would need a more fundamental re-write.

Anyway, thanks again for your excellent work on this project! :)

[frisian]

Your longer test results look promising and now are more in line with what I would expect given the speed increase in the code (what are the latest results?). From your post, it seems the latest Nomega hasn't lost any games on time so presumably the above fixes have sorted this also in the newer version. Did you get to the bottom of the illegal move in my previous post or do you want me to look at this?

The tournament has finished and the result was Nomega won 552 times and Numpty_DD won 448 times, 122 games ended in a draw. Numpty_DD had 18 forfeits on time (all with white ???), Nomega had no forfeits on time, there was no game that had a illegal move. If there is a problem with illegal moves they will be rare, it will be hard to identify what will be causing them. It is possibly that the changes I made has corrected the problem, need to run games to see if the still exist. (The perft tests are correct so if there is a problem it has to be something like a check(mate) that is overlooked).

I have made some improvements here and there but the speed gain is minimal, the best option is getting to get a GCC compiled version running under Arena/Winboard. The things that could be done to gain speed have been applied. I be working on the program but at slower speed due to the fact that I have some other things I need to spend some time on.

At the moment I trying to find opportunities for speed ups that I have overlooked/neglected.
Hope to have a newer version of Nomega ready in a week, can't say if I can fix the problem with GCC.

[frisian]

I got a GCC compiled version running under Arena.

In CommandLoop remove (or comment out) the following line
SendCommand ("feature done=1")

Ok Nomega would work but as it dropped out of the opening book (after 3 moves) it would again stop working.
Freebasic is not very strict about array boundaries but GCC is very strict.
In RepCheck there is a for next loop that goes from the current moveno to moveno - 7 but if moveno is smaller then 7 it gets outside the lower boundary. The for next loop should only be executed if moveno is greater then 7.

'trip though positions from last 7 moves and compare with current board position
If MoveNo > 7 then
For t = MoveNo to (MoveNo - 7) Step -1 '
if ingame_posit$ = Pos_State_W$(t) then wht_ingame_rep_pos = wht_ingame_rep_pos + 1
if ingame_posit$ = Pos_State_B$(t) then blk_ingame_rep_pos = blk_ingame_rep_pos + 1
next
End If

BTW the check is not correct, the 3-fold repetition is more complicated.

These two alterations are needed to get a GCC (-O max) compiled program to run under Arena. The program is two times faster than a GAS compiled program. Running a tournament to see if illegal moves or something else pops up.

I also found a error in the beginning of computer_move .
if fix_depth = 0 then ply_start_time = timer
when fix_depth is not equal to 0 the ply_start_time is not set, when using fixed search depth it will produces something like it needed 7 hours for finding a move resulting in a average of a few hundred nodes per second while it is capable of doing 1.4 millions nodes per second
Remove the IF THEN part, just leave ply_start_time = timer to fix it.

[FB_Numpty]

The tournament has finished and the result was Nomega won 552 times and Numpty_DD won 448 times, 122 games ended in a draw. Numpty_DD had 18 forfeits on time (all with white ???)

Well, this looks good for the new version - i am surprised about the number of Numpty_DD losses - I haven't seen this level before (> 1%) so will run some games myself, thanks for the heads up.

Well done on getting gcc version working, this is excellent news and I will look forward to the results of your testing!

BTW the check is not correct, the 3-fold repetition is more complicated.

Yes, this is true - there are a couple of issues here:

1) I selected 7 moves arbitrarily - of course it should track back all moves in the game, but I judged practically this would be too much of a hit on performance to do - from practical observation, I just wanted some simple test to stop Numpty aimlessly falling into repeating moves especially when it was winning against weaker opponents.

2) As per earlier post the 3 move rep code does need re-looking at wrt the winboard protocol - I will do this, but there is a broader issue also in that the existing does not check castling and ep rights - these are factors also in determining equivalence of position, but again from practical perspective I ignored this on the grounds of the hit to performance given the need to calculate and keep track of these variables - arguably it wouldn't be difficult to do, as this info is captured by the the setboard routine in another context.

I also found a error in the beginning of computer_move .
if fix_depth = 0 then ply_start_time = timer

Hmm, not sure about this - will have to have a look - the point of putting in the condition is that the timer isn't needed when the search depth is fixed (ie no time control is selected) so on first glance i'm not sure why this should have an impact? (I will use 'original' Numpty to test this).

[frisian]

I have run a tournament with Nomega (GCC compiled) against Numpty_DD. Needless to say the Numpty_DD lost most of the time. I had 1 forfeit on time by Nomega, I was able to find out that it was caused by the following code in computer_move.

Code: Select all

if fmove(depth) = 100 then  'score = if 50 move rule is tripped
    score = 0
    goto cm2x
    end if

The problem is that the claim for a draw can only made after 50 moves (100 half moves). To solve this it very easy just change if fmove(depth) = 100 into if fmove(depth) > 100.

Also found out that when Arena does not understand or is not agreeing to a claim it will send a question mark (?) it was just there but I failed to notice it.

I had look at some code that does some evaluation.

Code: Select all

 ' trapped piece penalty
 
 If B(26) = 7 and (B(27) + B(28) = 4) THEN  Pos_Eval = Pos_Eval - 25  'trapped white king rook
 If B(27) = 7 and  (B(28) = 4 or B(38) = 4) THEN  Pos_Eval = Pos_Eval - 50

 if B(23) = 7 and (B(21) + B(22) = 4) THEN  Pos_Eval = Pos_Eval - 25
 If B(22) = 7 and  (B(21) = 4 or B(31) = 4) THEN  Pos_Eval = Pos_Eval - 50

 If B(96) = -7 and (B(97) + B(98) = -4) THEN  Pos_Eval = Pos_Eval + 25 ' trapped black king rook
 If B(97) = -7 and  (B(98) = -4 or  B(88) = -4) THEN  Pos_Eval = Pos_Eval + 50

 If B(93) = -7 and (B(92) + B(91) = -4) THEN  Pos_Eval = Pos_Eval + 25 ' trapped black king rook
 If B(92) = -7 and  (B(91) = -4 or B(81) = -4) THEN  Pos_Eval = Pos_Eval + 50

 If B(88) = 3 and B(77) = -1 and B(86) = -1 THEN  Pos_Eval = Pos_Eval - 25 ' trapped white bishop
 If B(81) = 3 and B(72) = -1 and B(74) = -1 THEN  Pos_Eval = Pos_Eval - 25

 If B(38) = -3 and B(47) = 1 and B(36) = 1 THEN  Pos_Eval = Pos_Eval + 25 ' trapped black bishop
 If B(31) = -3 and B(42) = 1 and B(34) = 1 THEN  Pos_Eval = Pos_Eval + 25

If w_cas(1) = 1 and (B(36) + B(37)) <> 2 then Pos_Eval = Pos_Eval - 20 'penalty for lack of pawn protection if castled O-O
If b_cas(1) = 1 and (B(86) + B(87)) <> -2 then Pos_Eval = Pos_Eval + 20

Starting with the last lines ((B(36) + B(37)) <> 2 , 1 + 1 = 2 also 0 + 2 = 2 or 2 + 0 = 2 or even 4 + (-2) = 2
If one of the pawn was moved and an other piece was placed on free square then that would also provide protection. You need to think about it. Also at the top you add two squares don't think that is wise.

Trapped bishop.
If there is a white bishop on B(88) and a black pawn on B(77) and that pawn is protected by a black pawn on B(86) then you could speak of a trapped bishop.
But when there is a white bishop on B(81) and a black pawn on B(72) then there should be a black pawn on B(83) supporting the pawn on B(72), a pawn on B(74) leaves the pawn on B(72) vulnerable and could also block other pieces from protecting the pawn on B(72).

[FB_Numpty]

Ok, in looking at the fix_depth issue you raised, I found a problem which probably still exists in your latest development version. If you set fix depth search for anything above 5, Numpty will move instantly and not search to the required depth.

To correct this, in addition to the change you mentioned (ie deleting fix_depth = 0 condition for the timer (this needs to be done twice to ensure that the time is still recorded correctly). In the ab_search function - need to insert 'if fix_depth = 0....'

Code: Select all


if fix_depth = 0 and search_depth > 5 and (orig_root < 5 or (Move_Control - conv_clock_move_no) < 4) then 'sd criteria added to make sure move from last ply is available to play (21/6/10); added fix_depth criteria (Apr 2014)
    break = timer
        if (((break - start_time) * 100) > think_time) or (((break - start_time) * 100)  > = (0.4 * time_left)) then '(changed from 0.3  - 4/7/10)
            timed_out = 1
            exit function 'return 0'evaluate(side)
        end if
end if



Also need minor change to code to ensure that if fix_depth = 0 that the time control conditions are not engaged

I've also fixed the rep draw claim code and implemented the winboard 'draw' feature, though I just need to test this properly - essentially this involves offering a draw if rep_pos = 3 rather than announcing the game is over with 'send result' command

I have run a tournament with Nomega (GCC compiled) against Numpty_DD. Needless to say the Numpty_DD lost most of the time

Great!, not a surprise, do you have the results, so we have an idea of the current strength difference?

Starting with the last lines ((B(36) + B(37)) <> 2 , 1 + 1 = 2 also 0 + 2 = 2 or 2 + 0 = 2 or even 4 + (-2) = 2
If one of the pawn was moved and an other piece was placed on free square then that would also provide protection. You need to think about it. Also at the top you add two squares don't think that is wise.

I tested these evaluation terms in quite some detail and there wasn't much difference including/excluding them. I was aware of the ((B(36) + B(37)) issue and potential risk, but to be honest I judged this as unlikely to happen in practice (I've never observed it) particularly given that:
- these evaluation terms are only used prior to the endgame (after which they are not relevant)
- the pawn pst's encourage the pawns to stay where they are in front of the king with the size of relevant bonus.

Of course you are welcome to test this and prove me wrong! :)

(the reason I only included two criteria (pawns) here was that I wanted to make sure that the king wouldn't be subject to back rank mates that were beyond its search depth (this did use to happen rather too frequently). Arguably, it is riskier to ignore the 'h' file here but I reasoned that the pawn psts would encourage pawn to h3 which still provides a strong protection (ie f2, g2 & h3))

also at the top you add two squares don't think that is wise.

Is this the test for blocked rook ie - If B(26) = 7 and (B(27) + B(28) = 4) THEN Pos_Eval = Pos_Eval - 25 'trapped white king rook

In this case, I thought this was quicker than the equivalent 'OR' - perhaps not but I guess it isn't material

On the trapped piece, I think you are right, re-looking at this, when B(81) = 3 I think it should be when B(74) and B(83) which should be tested not the current B(74) and B(72). Again, I found the trapped code didn't make much difference in practice but of course it should still be corrected.

[frisian]

Some tournament results with Nomega compiled with GCC -O max and good old Numpty_DD.
100 games 40 moves / 5 min (repeating)
Nomega 55 wins and Numpty_DD 24 wins and 21 games ended in a draw.

400 games 60 moves / 1 min (repeating)
Nomega 232 wins and Numpty_DD 86 wins and 82 draws.

In general the most of the games are evenly matched until the game comes closer to the endgame, when Nomega's speed makes it possible to look deeper and to come up with the better moves.

Found out that by changing the way the castling is handled the following test does no longer works.
If w_cas(1) = 1 and (B(36) + B(37)) <> 2 then Pos_Eval = Pos_Eval - 20 'penalty for lack of pawn protection if castled O-O
If b_cas(1) = 1 and (B(86) + B(87)) <> -2 then Pos_Eval = Pos_Eval + 20
w_cas() and b_cas() have now two values "0" castling is allowed or "-1" not allowed.
Need to rethink the way to test that. Suggest w_cas(1) = 0 instead of w_cas(1) = 1

If you want more speed try the 64bit version of FreeBasic (GCC only), speed increase about 10-15 percent.

[FB_Numpty]

Thanks frisian, results equate to elo difference of between 100 - 130 which is pretty much what I expected and hoped for (perhaps not surprising given the speed difference that performance was relatively better at the bullet time control).

Please could you post up the latest development source so I can give this a go and also perhaps try 64bit version as you suggest.

Need to rethink the way to test that. Suggest w_cas(1) = 0 instead of w_cas(1) = 1

Interesting, what was the thinking behind changing use of w_cas/b_cas - ie what happens when castling has been completed?

I had wanted to distinguish between all castling states, so as to be able to add in the evaluation for protecting the castled king specifically. King safety is very rudimentary at the moment but is an area for potential development, especially with the speed increase. Using 'w_cas(1) = 0' would have the advantage of protecting the potential for (safe) castling (ie pawns would not advance if castling is possible).

An alternative I had previously considered but rejected as being too blunt (and therefore risky) as a generic evaluation criteria was using the relative offset of the king location to test for suitable pawn protection (eg if B(wkloc + x) = 1 ..... (problem is that if not castled you don't want pawns in front of king (typically d and e pawns) to be static, this may be solved by perhaps implementing the test after the opening (say if MoveNo > 15) etc.

[frisian]

Here is a newer version of Nomega (work in progress).

Will compile with GCC.
Changed the test for castling, the simple test are done first then the more complicated test like incheck and attack. If the simple tests trigger a break off the slower test aren't executed resulting in a small speedup.
Incorperated make_move and unmake_move in ab_search since both where only called from ab_search.
This gave a small speedup, I had hoped it would result in a more substantial gain.
I also have altered the test for break offs triggered by time, there is some potential by altering the double's into integers. I effort to get rid off multiplications a change the size of some multi dimensional array's to powers of 2 giving FB the change to use SHL instead of MUL.
And some small stuff I forgot about.

If you have the means to compile it with GCC 64bit then you can get a 10 to 15 percent speed up.

the link to the new version

[FB_Numpty]

Many thanks frisian! - I've got a gauntlet going with x64 compile and will have a look at the latest code.

One thing I think might need looking at is some of the move break time parameters - the existing values were the result of a lot of testing, but of course these were based on the typical speeds obtained prior to FB translation and resulting optimisation. Running much faster the search depths are correspondingly higher (especially in the endgame) and the current values which relate to pre-defined search depths might need a bit of tweaking.

Will report back some testing results at the weekend.

[FB_Numpty]

Well I've given the latest version a good run out at various different time controls against a range of different opponents and average elo gain seems to be around 90 - 110 which is not too far from your results. This would be consistent with the spped gain achieved. I tested this over a few sample positions - x64 compiled version ranged from 2.7 - 3.3 times faster than original DD version. Assuming 50-80 elo for doubling of speed, this would be consistent with the observed results.

Must say frisian has done a fantastic job- testing over a range of sample positions - the current version is now functionally pretty much identical to the last official release 'DD' version. Move choice and evaluations were the same by depth, the number of total nodes searched varied slightly (tending to be marginally higher for endgame positions).

I also gave the latest version a quick run out on FICS under the Numpty handle - this did give a few problems as the engine lost three times when opponent promoted a pawn - i've copied a sample game below:

[Event "FICS rated standard game"]
[Site "FICS freechess.org"]
[FICSGamesDBGameNo "355463484"]
[White "NumptyChess(C)"]
[Black "Bangthe"]
[WhiteElo "2008"]
[BlackElo "1927"]
[TimeControl "900+5"]
[Date "2014-04-27"]
[Time "04:31:00"]
[Duration "0:31:14"]
[WhiteClock "0:15:00.000"]
[BlackClock "0:15:00.000"]
[Result "0-1"]

1. d4 d5 2. c4 Nc6 3. cxd5 Qxd5 4. Nf3 e5 5. dxe5 Qxd1+ 6. Kxd1 Bg4 7. Nbd2 Rd8 8. Ke1 Bxf3 9. exf3 Nxe5 10. f4 Ng6 11. f5 Nh4 12. g4 Bb4 13. Bb5+ c6 14. Be2 Nf6 15. f3 O-O 16. a3 Ng2+ 17. Kf2 Bxd2 18. Kxg2 Bxc1 19. Raxc1 Rd2 20. Rhe1 Re8 21. Kf1 Rxb2 22. Rc4 Nd5 23. Re4 Rxe4 24. fxe4 Nc3 25. e5 Kf8 26. h4 Ra2 27. Bc4 Rxa3 28. e6 fxe6 29. fxe6 Ke7 30. Bd3 h6 31. Kf2 Ra4 32. Bf5 Nd5 33. h5 a5 34. Ke2 Rb4 35. Kd3 a4 36. Ke2 a3 37. Kd2 c5 38. Ra1 Ra4 39. Kc2 b5 40. Kb3 c4+ 41. Kc2 b4 42. Kd2 b3 43. g5 hxg5 44. Rf1 c3+ 45. Kd3 a2 46. Be4 b2 47. Rf7+ Ke8 48. Rf8+ Kxf8 49. e7+ Kxe7 50. Bxd5 b1=Q+ {White resigns} 0-1

I was watching and resigned this game for the engine - I've subsquently manually repeated the game playing the black side and doing this Numpty doesn't crash on the promotion, but thinks and then moves the king. So it doesn't seem to be a problem with the user entry code - which I've checked and seems to be ok (so don't think it is anything with moving this part of the code into 'Sub command loop' ).

It's not as simple as the original problem with lower/upper case characters and it doesn't seem to be a problem with movegen function as latest version is perfect on perft for the following position as far as i tested it (to d = 7)

8/PPP4k/8/8/8/8/4Kppp/8 w - - 0 1

I'm wondering if it is related to WQ/BQ values - in all 3 games by the time of the promotion to a new queen, the original Q had been taken. You're more familiar with this aspect of the coding having made changes, I wonder does it suggest anything obvious to you?