Weird issue: PDA in range 7-8 causes no move to be played (only on FoxGTP, works fine on Lizzie)

[SakuraGoH]

Hello KataGo developers and community,

I've been experimenting with handicap compensation by modifying playoutDoublingAdvantage (PDA) in my custom build of KataGo, and I've encountered a very strange phenomenon.

First, a question: Has anyone else experienced issues specifically with FoxGTP (the official FoxWQ/Weiqi server connector)?

I'm using FoxGTP to connect my modified KataGo to the Fox server. The problem is that when the PDA value falls in the range of approximately 7.0 to 8.0, KataGo refuses to play a move – it simply doesn't output the play command. The engine searches normally, shows analysis output, but then gets stuck without making a move.

Here's the really bizarre part:

· On Lizzie (the GUI/analyzer), everything works perfectly at any PDA value

· On FoxGTP, PDA values below 7.0 or above 8.0 work fine, but anything between 7.0 and 8.0 fails

Examples with different compensation formulas:

1.5 × handicap: 5 stones → PDA 7.5 → ❌ fails

1.2 × handicap: 6 stones → PDA 7.2 → ❌ fails

1.1 × handicap: 7 stones → PDA 7.7 → ❌ fails

1.2 × handicap: 5 stones → PDA 6.0 → ✅ works

1.2 × handicap: 7 stones → PDA 8.4 → ✅ works

1.5 × handicap: 9 stones → PDA 13.5 → ✅ works

The pattern is extremely consistent: the problematic range is strictly 7.0 to 8.0. Nothing outside that range causes issues.

Is this a FoxGTP-specific problem? Could it be related to how FoxGTP parses GTP responses, timeouts, or command ordering? Since Lizzie works fine, the issue seems to be in the interaction between KataGo and FoxGTP rather than KataGo itself.

Is there anyone familiar with the internal logic of FoxGTP and Lizzie who could explain the difference in how they handle GTP commands?

I've already tried:

Adjusting PDA calculation to avoid the 7-8 range (works as a workaround)

Adding debug output to confirm the search completes successfully

Ensuring GTP response format is standard

I'm not sure if this is a bug in my understanding of the code, an issue with FoxGTP, or something deeper in KataGo. Any insights would be greatly appreciated.

Thank you!

[SakuraGoH]

One more important detail: This issue only occurs on the first move of the game. If I manually play the first move (bypassing the engine), then all subsequent auto-generated moves work perfectly fine with the same PDA values. The engine only gets stuck on the very first move when PDA is in the 7-8 range.

This makes me even more confused - if it were a pure parsing or timeout issue, why would it only affect the first move and then work normally afterwards?

[Dreamygo]

Does 'the first move not working' refer to a pass? Your PDA values is set too high; you should lower it.

[SakuraGoH]

Does 'the first move not working' refer to a pass? Your PDA values is set too high; you should lower it.

It's not a pass, but rather not outputting the "play" command, meaning the search results won't be reflected on the board of FoxGo when using FoxGTP. Furthermore, this issue only arises when the PDA is at 7~8; it doesn't occur at higher or lower values.

[SakuraGoH]

Perhaps it's due to the impact of my compensation algorithm, but I'm not entirely sure. Nevertheless, I have already circumvented this issue