Okay, while black's 25th move (e6-e5) is not great it could be explained by a shallow search and/or simple eval function. White's 26th move (e3xd5) is the real blunder but that's not your concern. The remainder are not serious mistakes at this point.

The move by your engine worthy of investigation ...

Move order will not make the engine play ridiculous moves. Are most of the moves nonsense or just the odd one? Can you post an example of a position and the move in question?

While playing my engine against chess apps on my iPhone like Hiarcs and Stockfish there are a few cases where my engine declares a draw by repetition one move before the app does. Here is an example:

In the following position r2r2k1/1p2qp2/4pn1Q/8/1bPN4/3B4/5PPP/3R1RK1 b - - 0 27

Black (Stockfish ...

This would give you a less tight upper-bound to the score than just using bestScore = standpat, and I think the latter would be justified. As is a real search you will require staticEval >= beta, without adding any expected positional gain from your best unsearched move.

I'm a little confused ...

Thanks Harm. I agree, if you are hashing the null move fail high it would create an inconsistency when beta changes and you do a TT cutoff based on a null move that would not have been attempted. I guess one question that comes to mind is...could you return the nullValue but not store the fail-high ...

I finally converted my engine from fail hard to fail soft after thinking about all the potential advantages of doing so, particularly with regards to TT efficiency. Because I don't currently have a framework to test my program vs other engines over many games I'm struggling to tell if its an ...

Thank you! I've given that a shot but its performing worse for me. I must be doing something wrong. Let me recap what i've done using the methodology that even numbered entries are depth-preffered and odd entries are always replace.

Saving to hash table

Compute the hash table indexes:
hashIndex ...

I have implemented a new TT table replacement strategy but I fear I may be doing something wrong. Could you please critique this:

I have two tables. One that uses a depth preferred (DP) strategy and one that does always replace (AR). Here is the pseudocode.

Probing

first probe the DP table:

If ...

In the following pawn structure:

8/8/4p3/3p4/3P4/2P5/2P5/8

I currently treat both white pawns on c2 and c3 as backwards. I'm concerned that by doing so my engine is too interested in exchanging bishop for knight in order to double the c pawns while simultaneously making them both backwards. This ...

Okay so its not an inexpensive eval term after all, even with much of the calcs done in mobility. However, upon further reflection it can be made faster and better. I was ignoring the case where a white piece attacks the same piece type of black. Thats a mistake. If a white knight that is supported ...