Closed ZiggerZZ closed 1 year ago
The current implementation should support Blue Chip Table Manager, as I had done the same work. Removing the dot's and added a few communications.
But As I also updated the Table_Manager_Client
with more meaningful output, and have implemented a lot of changes about configuration my best advice is that you take the latest version and test it against Blue Chip, and the we fix it together if you find any bugs.
I have checked your changes and 2 changes are not implemented 1; The delay of 0.2 second before sending 2: Uppercase of Pass, double and redouble
But the rest is implemented.
I'll test your version and tell you if I have any troubles. The delay of 0.2 second is because w/o any delay messages might get concatenated into one message, what we want to avoid. The value of 0.2 is arbitrary.
Yes, I had the same problem with my TM-integration to GIB, and started with 1 sec, changed it later to 0.1 sec, and have done some testing, where 5 ms seems ok, The delay should be after sending, and I have added the delay but only for send_card_played and specific places, where it was a problem
I have accepted your PR and agree, that BEN is not following the Blue Chip protocol fully, but be aware that most user are using Bridge Moniteur, that are not fully compatible with the Blue Chip Protocol.
BM available at http://www.wbridge5.com/bm.htm and we want BEN to support both BM and Blue Chip TM
I have never used Bridge Moniteur, I suppose it should be flexible enough to support BlueChip itself and BlueChip with some deviations. But so far my table manager is compatible with Ben and WBridge5, so it's fine.
Fine, I will then close this with your PR.
@ThorvaldAagaard How is the end of the board handled? According to the protocol at the end of each hand the Table Manager will send timing information to each hand in the form : "Timing - N/S : this board [minutes:seconds], total [hours:minutes:seconds]. E/W : this board [minutes:seconds], total [hours:minutes:seconds]".
However I don't see any timing handling intable_manager_client.py
. Also, what is is_continue
flag for?
I think is_continue
is Lorands implementation for continuing a match that was interrupted. I have removed it in the incoming version as the new version is able to handle the small difference between starting a match and continuing a match.
The timing is being ignored in this implementation, but I think we should print it.
How do start a new board, do I need to rerun python table_manager_client.py
?
No, that is managed from the Table Manager - table_manager_client
just listen and act according to the commands,. It will continue until being disconnected or getting "End of session"
Hi,
I had make corrections to Bluechip protocol implementation in ben but since then quite a lot of changes were made so it's becoming hard to resolve git conflicts.
Basically, I mostly removed dots in the end of the sentences (since the protocol defines them without dots) and added one or two missing communications.
I'm opening this issue and posting the code that worked correctly with a Bluechip table manager a few weeks ago. How would you like to go about it?