rich_wil

Updated to Firefox 3 - problem has not recurred. Will let you know if it happens again. Thanks.

Seperate servers but the problem is one of priority - I am using an older laptop so not especially fast. When an opponent claims - the system reveals all hands and then nothing further happens. My screen reports continuously "getting data from add server" . No button to accept claim is shown. Chat continues to be shown so I can see my opponents comments on the delay. Again when I complete a tourney, I am as I expect, in the tournament area with the ongoing tables shown. However, none of this updates from this point forward. I cannot go to any of the tables. No tourney results are posted. "Getting data from ad server" comes on repeatedly.

A problem with the new browser based version - the ad server has higher priority than a number of essential services. Examples: When opponents claim, it continues to refresh ads but does not display "accept claim" option. Eventually server times out the attempt to claim and play resumes. Similarly, results are not displayed at tournament end and no update is done of active tables screen. Attempting to join tables shown as active will bring error message - "Cannot join table". The only way to get tourney results is to back out and re-enter tourney.

The current BBO system provides no information and limited feedback for those wishing to serve as subs on tourneys. It could easily be improved by using the same signup interface as currently used for tourney registration. ie. when sub button is pushed a window for sub registration comes up with the current subs listed and the option to click on registered subs to see profile. This allows the user to know/estimate how desperate is the need (how many there already ) and the chance to play (what is quality of already registered subs)

I am having some difficulty in character interpretation by the BB server in chat messages between myself and a Turkish player. Messages are in English but I becomes an accented Y, G becomes a funny sort of D and S is realy weird. I think the problem is that ISO 8859-1 is being used to interpret data entered in ISO 8859-9. There is only 6 characters which were changed when ISO 8859-9 was derived , from ISO 8859-1. In ISO 8859-9, the characters DD,FD,D0,F0,DE,FE are approximate to I,G and S but with accents. In ISO 8859-1, these codes were used for Icelandic letters. I am using the bridge base software under the windows 2000 pro operating system. Has the problem been encountered by anyone else? Is the server failing to give the proper character set for the chat, or is the operating system on my computer unable to properly construe the characters sent to it?

>"Scco: bhttp://www.tistis.nl/bbn/index.htm" Sccob, thank you for posting a site offering a bridge bidding systems editor which has been implemented using this technology. >"Barmr - None of the problems you mention would be solved by using XML for the CC files. XML is a file format specification, but it doesn't address the logic of the applications that use the data. And all those problems are with the logic of Full Disclosure." Barmar, thank you very much for replying to my post. xml is a method of transferring data between applications in a very flexible but standard way. It also has a suite of standard tools and extensions for transforming that data into other forms including the type of operations required to replace a single bidding tree for "Majors" with two trees "Hearts" & "Spades" with appropriate substitutions for "other major" or "raise". The logic required for ease of implementation on the playing server should not dictate the design of the editor & user interface. "Barmar - Another issue is that the FD file format was deliberately designed to be terse, and XML is a pretty verbose file format. Many BBO users have poor, slow Internet connections, and anything that minimizes the amount of data that has to be downloaded is important. " That issue should have nothing to do with this. If the data is stored at both ends, it may need to be synchronized no more than once or twice a month and posibbly as low as every six months? The question of minimizing the data exchange at sign on is a very important but seperate topic. The main problem with the current system is uploading/downloading information that is not required. This might be greatly reduced by the following: 1. storing all user preferences on the server and on the client with a synchronization/version code. 2. downloading only the information on users that would be immediately displayed. - in the lobby, only those online members on the users display preferrences - at a table, only the other three players - on viewgraph, only the commentators/hosts - downloading the table information only if the user wishes to view it

Bridge Bidding Systems These observations arise out of my efforts to update and enter a Precision bidding system for use on BBO. Bidedit.exe I have very seldom seen the current convention card function used in play. I think there are very good reasons for the resistance to the adoption of this new feature. Problems The present bid editor has a number of difficulties: 1. The data must be fully and explicitly entered for every branch and node. There are no facilities to make general statements about a class of things i.e.. over all major suit openings, all minor suit raises, etc. Thus it is very tedious and time consuming to enter what may be very redundant values for every node. 2. Error checking is extremely difficult, as the editor does not provide a view of the entire tree structure. Thus each individual limb must be explored and all of the data in it checked branch by branch, node by node. 3. It does not provide a convenient overview for reviewing bidding agreements with prospective partners. 4. It is subject to random change (i.e. lacks version control for included convention files). 5. Cannot be used to describe defensive bidding if it is used against more than one set of opponents. The starting point of a defensive bidding sequence is a bid by opponents. The branches from that bid must be changed if new opponents have different meaning assigned to the opening bids. i.e.: I. For a 1NT meaning 15-17 hcp, you fully describe DONT but the next opponents play 1 NT as 12-14 hcp and you use Cap vs. weak NT. A third card would be needed if 1 NT’s strength varied with vulnerability. II. A Double of 2C could show a weak hand with the majors against a strong 2C opening but be an intermediate to strong three suited takeout against a precision 2C bid. Each change in opponents bidding system requires a new card. Characteristics of desired solution What would be nice is a consistent way to exchange descriptions of bidding systems over the Internet. Ideally, the same system description should be available in a tool to assist partnership discussion and system agreement. It should facilitate disclosure to opponents both prior to commencement of play and during the auction. It should also be accessible to a number of editors and communicate with the software of various tournament organizers and national Bridge bodies. Multiple applications should be able to import and export the data including the common bridge playing programs – Bridge Baron, etc. Both online and real world tournament organizers should be able to use it. Bridge broadcasters should be able to easily and automatically import convention card data into their system. Solution: There is a tool that is designed specifically for exchanging structured information of this type over the Internet -- XML. It may be well worth the effort to create a bridge bidding system style sheet or template. Editing XML There exist many XML editors including a number of good freeware ones. Some of these are optimized for tree data structures. One of these, with a bridge style sheet, would be ideal for entering or reviewing systems. It may be possible to avoid the time and resources required developing a specialized editor from scratch.