At this point, I would try to make sure that what you've written so far is working correctly. Is it still the case that the program doesn't play better at higher depths?

I still have problems with the loop. The 4000-6000 moves searched was because the recursive function was search up to 1 depth. That has been fixed but the AI plays worse than without ID. For example, in some cases it loops for 99 depths but finds nothing.

I tried changing the aspiration delta but it didn't help.

Could it that the best move is placed to the top of the list and the search keeps searching the path?

I've finally managed to implement ID into the search and it's working. I have a couple of questions:

1. Killer moves are local to the current search. Should the TT also be local to the current search or should it be for the whole game?

2. I also implemented transposition move in the search (before normal negascout search starts). However an assert is failing on makeMove because the current position doesn't belong to the current player on turn. Should I even bother with an assert there?

3. I would like to implment history heuristics. Are these local to the current search or should they be for the whole game?

I've finally managed to implement ID into the search and it's working. I have a couple of questions:

1. Killer moves are local to the current search. Should the TT also be local to the current search or should it be for the whole game?

The TT should be for the whole game, or you'll forget what you learned in the previous search, which is not a good idea.

2. I also implemented transposition move in the search (before normal negascout search starts). However an assert is failing on makeMove because the current position doesn't belong to the current player on turn. Should I even bother with an assert there?

So you have an assert that fails for reasons you don't quite understand? It sounds like removing it is a horrible idea.

3. I would like to implment history heuristics. Are these local to the current search or should they be for the whole game?

I make them for the whole game, but I divide every entry by 4 at the beginning of each search, so old entries that are no longer relevant can decay. If you were to make them local to the current search, I think they would work just fine too.

I've finally managed to implement ID into the search and it's working. I have a couple of questions:

1. Killer moves are local to the current search. Should the TT also be local to the current search or should it be for the whole game?

The TT should be for the whole game, or you'll forget what you learned in the previous search, which is not a good idea.

>2. I also implemented transposition move in the search (before normal negascout search starts). However an assert is failing on makeMove because the current position doesn't belong to the current player on turn. Should I even bother with an assert there?

So you have an assert that fails for reasons you don't quite understand? It sounds like removing it is a horrible idea.

3. I would like to implment history heuristics. Are these local to the current search or should they be for the whole game?

I make them for the whole game, but I divide every entry by 4 at the beginning of each search, so old entries that are no longer relevant can decay. If you were to make them local to the current search, I think they would work just fine too.

good answer for question 2!! nah I will need to find out what the problem is and solve it.

for the history table and in the case of nine men morris where you have just placement of pieces, moving, and also placement+capture and move+capture is it wise to have a 4d array in this case or should I have a 2 3d arrays (one for each player).

when sorting the history, i would assume that the moves are sorted based on the array of player whose turn it is at that stage of the search. right?

small question about iterative deepening... I have a time limit of 2s and it goes 7 plies deep but sometimes it goes even 8 or 9 but because the time required to complete the search at that depth is more than 2s, it can take up to 6s to complete. should i also quite searching in negascout by checking outOfTim() in the move loop or is it wise to let it finish the search at that depth?

for the history table and in the case of nine men morris where you have just placement of pieces, moving, and also placement+capture and move+capture is it wise to have a 4d array in this case or should I have a 2 3d arrays (one for each player).

For nine men morris I would use history heuristic only for non-mill-forming moves, similarly to how history heuristic is used only for non-capturing moves in chess. You can deal with placements as moves with a special `from' value, or by setting `from' and `to' to the same value.

when sorting the history, i would assume that the moves are sorted based on the array of player whose turn it is at that stage of the search. right?

Yes.

small question about iterative deepening... I have a time limit of 2s and it goes 7 plies deep but sometimes it goes even 8 or 9 but because the time required to complete the search at that depth is more than 2s, it can take up to 6s to complete. should i also quite searching in negascout by checking outOfTim() in the move loop or is it wise to let it finish the search at that depth?

This is tricky. It depends on how you want to control time. I can tell you what I do, but there might be better solutions.

In my chess engine I use UCI to communicate with the GUI, and time control is part of the protocol. So I have to be flexible and be able to respect several different clock types: Infinite search, fixed time per move, fixed depth, a certain time for the next certain number of moves, a certain time for the rest of the game, perhaps there is a time increment every time you move (a.k.a. Fisher clock)... In the end I translate all those things into four numbers: A maximum depth, a desired time to spend in this move (which I use to determine whether I dare to search one ply deeper or not), a hard time limit in case I get stuck in a deep search (this is set to 5 times the desired time, and it's useful when the transposition tables bring you immediately to some large depth and then you don't have time to finish the next one), and a hard time limit to avoid running out of time. I have two hard limits because I modify the desired time per move when I detect a difficult situation (basically when the score drops), and I scale the first hard limit with it, but not the second hard limit.