Version : 8.3
Table Of Content
For recent changes see actual release notes :
The purpose of this browser extension is to reduce to the absolute minimum the manual operations due to the alerting procedure while playing bridge on BBO (www.bridgebase.com).
All you need in the beginning, is to install BBOalert and play normally. BBOalert will :
Thereafter you can decide to use advanced features if needed:
If you you decide to use BBOalert, join the users community on Facebook
https://www.facebook.com/groups/706384146770707/
Facebook should be used to :
We assume that you are familiar with BBO.
Tired of repeating the same story while alerting your bids on BBO? If yes, this browser extension is your friend.
During the bidding, conventional calls must be alerted and explained to the opponents. Playing artificial bidding systems on BBO is not practical because explaining each alerted call is time consuming and therefore frustrating for all participants.
BBOalert solves this problem. Artificial bidding sequences can be predefined in a table. Opponents get the explanation automatically and immediately. Explanations entered manually during the game are recorded for future use.
BBOalert has similar functionality as "Full Disclosure" which is no longer supported by BBO. One difference should be emphasized :
The program can read "Full Disclosure" old BSS files. This will enable many users of the old Windows Flash version of BBO, to migrate to the HTML version without loosing the Full Disclosure functionnality.
BBOalert is useful for all types of BBO users :
This extension can be installed using the link :
If you discover a serious bug in the program :
follow this link to revert to previous version
After you start BBO, the screen should look like this (note red/blue panel at the right) :
At the right side of the page, an additional 'BBOalert' tab is created. Clicking at this tab will toggle BBOalert panel display. This tab is only partially integrated with the regular BBO tabs :
BBOalert creates four panels :
The panels can be selected by clicking the corresponding buttons at the top of the panel.
The "Data" menu contains commands related to the data input/output :
The "Settings" menu contains commands to enable/disable features :
You will find detailed information later in this text but before you continue to read it it is recommended to get familiar with the basic BBOalert functions by following the tutorial.
BBOalert uses the clipboard to import or export data. Using the clipboard instead of direct file access gives the user the freedom of choice of text editing tool. The code can be edited as a simple ASCII file or with any text processing tool like Word. To read the data from a file :
BBOalert requires the BBO in split screen mode (Account + Settings + Split Screen).
It is recommended to enable 'Confirm Bids' (Account + Settings + Confirm Bids). This will give you the opportunity to verify if the explanation is correct, before sending it to the opponents. The chat part of the long explanation text will be sent automatically.
Data is saved in browser's cache and is recalled automatically at the next session. You should use 'Paste (New)' only if the data has changed or if the cache has been cleared.
'Paste (Append)' command allows you to add code to the previously pasted code. This allows splitting data into separate files for openings and development, overcalls, and the keyboard shortcut, as examples.
Only BBOalert native code can be appended, not BSS data. However, appending BBOalert native data to the previously imported BSS data is allowed.
With the 'Copy New' command you can copy the manual alerts to the clipboard and paste them at the end of your data file. The records imported this way will contain a timestamp and the deal number. You can retrieve from BBO the deals to review the manually alerted calls before committing the changes in your data file.
BBOalert was designed initially for BBO in English and then adapted to other languages. If you discover incompatibilies of BBOalert with BBO in your language :
We use the "You only alert once" principle. All you need to do in the beginning, is to play and alert if necessary. Your explanations will be recorded in the browser's cache and in the clipboard. The next time, when the same situation occurs, your call will be alerted automatically. Because cache is a temporary storage, you should paste the clipboard content from time to time in a text file as backup.
It is more efficient to prepare data in advance with a editor and paste this data into BBOalert. It is needless to code your entire system at once; it is a huge task. In each bidding system there are sequences which almost never occur.
You and your partner should use the same data. The simple but ineffcient method it to edit the data locally and share the file as mail attachment. The best way of sharing data is by using the cloud storage. See the "Web storage support" section for details.
Turning 'Alert' ON and OFF OFF will erase the explanation text. Thereafter you are free to enter eventually a new explanation text that will be recorded.
Comma separated value (CSV) format is used for each record.
The file must begin with the header record :
BBOalert[,
Where :
Alerted calls should contain at least three text fields separated by commas :
<context>,<call>,<explanation>[,optional text ignored by BBOalert]
where "context" is the bidding sequence preceding the "call". In those two fields we use two-character self-explaining tokens :
1C 1D 1H 1S 1N Db Rd 2C 2D ....
To increase the readability of the code :
,1N,12-14p balanced
Note :
1N--,2C,Stayman can be weak
1N--2C--,2D,No 4 card major
Note : -- codes mean pass by opponents
1HDb,Rd,9+p misfit !H penalty redouble
1D,2D,Major two-suiter
An empty "context" field means seat-independent opening. By using leading -- codes you can define seat-dependent opening. Placed after seat independent opening code, it will override it for the specified seat. Example
,1S,12-21p 5+!S, This is the normal opening for all seats
----,1S,8-21 5+!S, except after two passes. It can be weaker
----1S--,2C,Drury, in such a case Drury is used
The alternative prefered method of coding seat-dependent openings is presented in the section "Optional code".
If the context is identical with the previous record, the '+' character can be used in the "context" field
Example : instead of code
1N--, 2C, Stayman
1N--, 2D, Texas !H
1N--, 2H, Texas !S
you can use code
1N--, 2C, Stayman
+, 2D, Texas !H
+, 2H, Texas !S
Bidding sequences can be coded in form a hierarchical lists. Markdown language unordered lists syntax apply. Example :
,1N,15-17p
- 2C Stayman
- 2D no 4-card major
- 2H weak major two-suiter
- 2D Transfer
Following rules apply :
Starting point of the tree is to be coded in the normal way (context,call,explanation)
Indentation
Within the list the call and its explanation should be separated by space(s) and/or tab(s), not by a comma
By default opponents are assumed to pass. If they don’t, add their bid before your bid separated by a comma. Example of a 2C response after RHO’s double :
,1N,15-17p
Asterisk may be used instead of hyphen
To increase the readability, it is possible to split a long record over more than one line. When a record ends with a backslash, it is cancatenated with the next record. Example : instead of
(1N--|2N--|2C--2D--2N..), 3C, Puppet Stayman
you can write :
(1N--|\
2N--|\
2C--2D--2N..), 3C, Puppet Stayman
If you need more than 69 characters to explain the alerted call, the solution is to place in the middle of the text the '#' character. It will split the text into two parts : the first part will be used in the explanation field of the bidding box. The second part will be set in the chat box. In the second part
code may be used as line break to split the text over multiple lines when it is sent.
Example :
1S,2C,Please read chat for explanation#Natural overcall with at least a decent 5-card suit
The chat message will be sent automatically. Make sure that the chat messages are adressed to the opponents. Your partner is not supposed to read your auto-alert.
In the cases where the meaning of the call is not influenced by an eventual overcall, wildcards can be used in the "context" field. This can make the code more readable and more compact. Two characters are allowed as wildcard '*' or '_'. They match one character and have the same effect. In this example :
1N__,2H,Transfer->!S
the code means : whatever the opponents do, 2H remains a mandatory transfer to 2S. Otherwise code should be provided for all possible overcalls made by the opponents.
Both, "context" and "call", fields can be also formatted as regular "RegEx" expression in the process of matching with the actual bidding context.
RegEx can be used in two forms :
RegEx is a very complex mechanisme, but in BBOalert we use primarily one type of expression : groups of string matching patterns. The example below can be used as template :
(1N--|2N--|2C--2D--2N..), 3C, Puppet Stayman
This means that 3C call is defined in one record, instead of 3, as Puppet Stayman in three similar situations :
Further development can be coded as :
(1N--3C--|2N--3C--|2C--2D--2N--3C--), 3D, at least one 4 card major
+, 3H, 5 card !H
+, 3S, 5 card !S
+, 3N, no 4+ card major
For matching a single character, brackets should be used as in the example, where after either 1H or 1S opening, Jacoby 2NT raise is used :
1[HS]--,2N,+12HCP and 4+ card fit
Asterisk wild card must be avoided in the regular expression. It matches strings of any length and will lead to unpredictibles results. If used, asterisk (and also underscore) will be internally converted to a dot (single character match).
If the ‘context’ field starts and ends with a slash, it is interpreted as a pure RegEx. Any regular expression is allowed, but 4 patterns are relevant for context matching
// match any string
/^startString/ match starting string
/endString$/ match ending string
/^startString.*endString$/ match both
/^String$/ exact match
Examples :
//,4N,Blackwood 5 key cards ,after any bidding sequence 4NT is Blackwood
/^1N/,4N,Quantitative slam try ,except after 1NT opening
/4N--$/,5C,1 or 4 key cards ,response to Blackwood
/4N--$/,5D,0 or 3 key cards
/4N--$/,5H,2 key cards without trump Queen
/4N--$/,5S,2 key cards with trump Queen
/Db$/,--,to play doubled ,in any case pass after double is to play
/Db$/,Rd,forcing; may be SOS ,but redouble is forcing
/^(1N|1N----)$/,Db,for penalties
When the
Example :
1N--,(2C|2D|2H|2S),Stayman,Texas !H,Texas !S,Texas !C
Wildcards and regular expressions are powerfull features to get more compact code, but must be used carefully.
To use this feature the knowledge of RegEx and JavaScript is required. Portions of the text can be replaced by the result returned by a user definable script. The script name is enclosed between two % characters.
Scripts may be used in fields :
An example of data file :
BBOalert
Script,X,R = C.match(makeRegExp(CR))[1];
Script,Y,R = C.match(makeRegExp(CR))[2];
1([HS])--,2N,+12HCP and 4+!%X%
1([HS])2([CD]),2N,11-12HCP misfit !%X% stopper !%Y%
Note : X and Y are arbitrary script names,and there are no specific limitations.
More information about scripting can be found in the "Scripting in BBOalert.pdf" file.
Scripting allows custom data syntax. This feature is experimental : see this folder for details
Almost everyone on BBO is using the SAYC bidding system. But SAYC is not the world standard and some opponents will use another bidding system such as ACOL or French Standard. If you play on BBO with your partner to practice a sophisticated defense system - with particular agreements that depend on the conventions used by the opponents - you must be able to switch on-the-fly between different defense options during the game.
To solve this problem, the keyword 'Option' followed by the option name are used. The optional block of code is ended by another optional block or by bare 'Option' keyword. The selectable options will be displayed on the red "Options" panel.
The subsequent options with the common prefix word will be grouped automatically. Within the group only one option can be selected to avoid conflicting codes (mutually exclusive options). You are free to disable any option. Initially the first member of each group is enabled. This feature is typically used for :
Option,vs1NT weak
... code for overcalls after weak 1NT opening
Option,vs1NT strong
... code for overcalls after strong 1NT opening
Option,Recorded OFF
Option,Recorded ON
Optional blocks of data can be used also for :
seat-dependent openings by using @1 @2 @3 and @4 tags. Seat dependent overcalls must be coded explicitely as in the example :
--1D,1H,<explanation text>
This is 3rd seat overcall not 3rd seat opening.
The selection is done automatically if the block name contains any @ tag. This selection can be then manually overridden by the user during the game. Combining tags is allowed.
Spaces should be avoided in the option names containing @ tags. I recommend to use underscores instead.
In this example :
Option,Opening_@v@3@4
the option will be enabled if vulnerable in 3rd or 4th seat.
Example :
Option,NT 15-17
1N,Db,any 6 card suit (DONT)
Option,NT 12-14
1N,Db,for penalties
Option,2H weak
... code specific for the defense against weak-2 opening
Option,2H weak 5!H and 4+m
... code specific for the defense against Muiderberg opening
Option,MyOpenings_@n
,1N,12-14 balanced
Option,MyOpenings_@v
,1N,15-17 balanced
Option
In this example three separated groups of options are created.
Options can contain also other types of records (Shortcut, Button, Trusted, Untrusted, Script, Alias). Those records will be active only if the option is enabled.
Fragmentation of options is allowed. If two or more options are defined with the same label, they are all concatenated inside of BBOalert. But if you want to define partnership, you have to do with the first occurrence of an option. This way empty options can be declared in the beginning of the data. The code for each option can be provided later in the file not necessary in the same order. Example of a construct :
Option,A,me+partner1
Option,B,me+partner2
Option,C
Option
……..
Option,B
… code part 1 for option B
Option
………
Option,A
… code for option A
Option
……..
Option,B
… code part 2 for option B
Option
Sometimes it is useful to insert a separator between different groups of options. To achieve is declare a dummy option ending with the @s tag. The separator should be immediately followed by a regular option record.Example :
Option,Overcalls@s
Option,vs1NT Strong
.... some code
This will create a supplementary button with centered "Overcalls" text at cyan background.
Let us assume that you play different conventions with different partners. The option selector enables you to use certain options only when playing with a given partner. Example : you play weak NT with John and standard NT with Joe. This affects the NT rebid after the opening in a minor. The BBO user-id's of your partners can be specified in supplementary fields of the Options record. More than one name is allowed separated by a comma. When two user-id's separated by a + are specified with an option and both players are present, the option is activated automatically. Sample data :
Option, 1NT 12-14, John
, 1N, 12-14p balanced
1[CD]--1*--, 1N, balanced 15-17p
Option, 1NT 15-17,smazur+stanmaz
, 1N, 15-17p balanced
1[CD]--1*--, 1N, balanced 12-14p
Option
If you choose John as partner the 1NT 12-14 option will be enabled and 15-17 disabled :
If you play with a partner who is not specified with any option, you may choose options manually (first Options-All) or select the options of another partner.
It is possible to disable all options by chosing 'Options-None' from the dropbox. This feature can be used to disable also your entire bidding system if you declare it as an option.
The code between the keywords 'Trusted' and 'Untrusted' will not require to be confirmed, even if 'Confirm Bids' toggle switch is ON. The number of occurences of trusted code blocks is not limited. In the example below, the explanation of 1C and 1D opening will be sent immediately, whereas 1N will required confirmation by pressing the OK button.
Trusted
,1C,16+HCP any distribution
,1D,11-15HCP not 5 card major
Untrusted
,1N,13-15HCP balanced
Shortcut format :
Shortcut,<token>,<full text>
In this example :
Shortcut,TH,Texas->!H
TH string will be immediately expanded to the "Texas->!H" during text entry in the Message or Explanation text box. The tokens can be of any length , but we advise to use uppercase two-character tokens to avoid confusion during normal text entry.
You are also allowed to define Alt-key shortcuts as shown in this example :
Shortcut,AltA,this text will be inserted if you press Alt-A key
The \n token within the shortcut text will split it and each part will be sent immediately. Example :
Shortcut,WC,Welcome\nwe are playing SAYC\nItalian discard\n
This should be used only in the chat box only to increase the readabilit of the message by subdividing it separate lines.
Note : check for potential conflicts with Alt key shortcuts of the browser.
Shortcuts can be defined as buttons displayed on a panel. Pressing a button will have the same effect as keyboard shortcut. The panel is disabled by default. To enable it press 'Shortcut' button on the blue panel. It will turn from red to green. The button panel will be displayed when clicking the explanation or chat entry text field. Clicking again will toggle button panel display.
At the top of the panel three buttons are predefined to erase single character, word the whole line of text.
The data format is similar to keyboard shortcuts :
Button,<token>,<full text>[,optional properties]
This will create a button with
Example
Button,Hello,Hello; We are playing ACOL
You don't need to duplicate keybord shortcuts into buttons. Keyboard shortcuts will be displayed together with button shortcuts.
The default button properties are :
You can override the defaults with the optional properties. Properties should be separated by a space character. Properties can be also appplied to keyboard shortcuts. Example :
Button,Hello,Hello; We are playing ACOL,width=100% backgroundColor=green color=white
Button,♣, !C,width=18% fontSize=40px borderRadius=100%
Button,♦, !D,width=18% fontSize=40px borderRadius=100% color=red
Button,♥, !H,width=18% fontSize=40px borderRadius=100% color=red
Button,♠, !S,width=18% fontSize=40px borderRadius=100%
Button,NT, NT,borderRadius=20% width=28% fontSize=40px
Button,Texas,Texas,width=50% backgroundColor=orange
Button,Transfer,Transfer,width=50% backgroundColor=lightgreen
The list of color names can be found on page : https://www.w3schools.com/colors/colors_names.asp
The full list of property names (only a few apply to buttons) : https://www.w3schools.com/jsref/dom_obj_style.asp
Shortcut records wiil be also automatically displayed on the "Shortcuts" panel as buttons. The same attributes can be assigned to shortcuts as to buttons.
Shortcuts,HO,Hallo opps,width=50% backgroundColor=orange
If you do not want a shortcut to appear on the buttons panel you may use the "Display" attribute as in the example :
Shortcuts,HO,Hallo opps,display=none
The format of an alias record is :
Alias,<string1>,<string2>,<tags>
If any explanation text record contains
Optional
,
should be used instead.Examples of the use of tags :
@C@B : prevents to substitute the character “m” in the explanation text
Alias,m,[CD],@C@B
The @G tag allows using the plain language to make the code more readable
Alias,Opening 1 club : ,,
1C,
,@G
Opening 1 club : 16+p any distribution
The @G tag allows to use a custom field separator. E.g. : he vertical bar can be used as a field separator instead of a comma. This technique allows to present the list opening bids as a table in markdown format.
Alias,|,,
,@G
| 1D | 4+!D |
The main purpose of aliases is to solve the problem of national bridge events where the usage of the local language is required. Maintaining two different data files for two different languages is not practical. The aliases can be used to translate expressions depending on the selected language. Example of code :
BBOalert
Option,Lang EN
Shortcut,HH,Hello
Option,Lang FR
Shortcut,HH,Bonjour
Alias,balanced,régulier
Alias,game forcing,forcing manche
Option,MySystem
,1N,15-17p balanced
,2C,game forcing
Sorting aliases by
Alias,without,sans
Alias,with,avec
The word ‘without’ will be translated to ‘avecout’ which is wrong. Reversing the order will give the correct result.
Aliases may be used also in the bidding context or in the call field. Example :
Alias,#,2C--2D--
#2N--,3C,Puppet Stayman
Is equivalent to
2C--2D--2N--,3C,Puppet Stayman
The same alias may be reused later in the file with a different definition.
This technique may be useful when the same long context prefix is used at different places. The alias may not be combined with + in the same context field.
BBOalert can read BSS files in the same way as native BBOalert :
BBOalert converts BSS data internally to the BBOalert native format. Vulnerability-dependent calls are supported (@n or @v tag in the optnion name). Seat-dependent openings are set in separate optional blocks (@1 @2 @3 or @4 tag in the option name).
The converted data is available in the clipboard. You can paste it into the text editor and use it as a starting point for further modifications. Another possible scenario is to keep importing the original BSS file and to create an overriding code (in BBOalert native format) in a separate file to be appended later ('Append' button).
Note : this feature has been disabled
To share the data with your partner via the BBO server :
Note : while editing the "Defensive Carding" text, do not alter anything beyond the large square character which separates your text from the BBOalert data.
This convention card together with the BBOalert data will become available for your partner. To load data into BBOalert
BBOalert allows to store data on a file hosting server and to import it dynamically at the beginning of each session. This facilitates the file sharing making sure that both partners use the same data. Actually three sites are supported with their specific limitations due to the particular data security implementation :
We assume that you are familiar with the tool of your choice.
Notes :
To access the data BBOalert needs a public URL link to the file. For each site the procedure is different.
GoogleDocs documents can be used to contain the data. BBOalert recognizes only paragraphs with the 'normal text' attributes. Also buletted lists may ne used to represent a hierachical bidding trees. Other document elements (headers, footers etc) are ignored.
The public URL can be obtained in the following way :
More details can be found in the document :
https://docs.google.com/document/d/1XTma7fZbI0pRU3TtNFOLAG0sUKyBaXFtkQAu90rwfRY/edit?usp=sharing
Support discontinued
The data can be imported from text files stored in GoogleDrive cloud. The URL link for public viewing should be used with the “Import” record. Note : the file size is limited to 260k bytes
The public URL can be obtained in the following way :
The data can be imported from text files stored in OneDrive cloud. The .txt file extension must be used. The URL link for public viewing should be used with the “Import” record. Note : the file size is not limited.
The public URL can be obtained in the following way :
Note : This section is under development
Your data can be split in separate files.
Each piece of data can be loaded into BBOalert with the Import statement as follows :
Import,<file URL>
Hierarchical nesting of linked files is allowed (Each file may contain a link to another file)
In extreme case one can define locally the whole bidding system with only two lines of code as in the example of our system :
BBOalert
Import,https://github.com/stanmaz/BBOalert/blob/master/Systems/stanmaz/wholeSystem.md
The rest of the data will be loaded by following the link above.
Handling a large data file is not easy and subdividing it into smaller linked pieces is a great help. This enables collaborative editing and easy sharing of effort. Each module can represent a convention that can be published within the users group on Facebook and reused by others.
The URL’s used in the “Import” records are long and cryptic because instead of real file names the cloud service providers use file ID’s to identify the file. It is possible to create an alias using an arbitrary short name. The advantages :
Example : instead of
Import,https://docs.google.com/document/d/e/2PACX-1vSz8gq9LwJQ2UY5El6czdaElyvzSjQMx1dvrIh9Ss_0-muXDwr9-7N8bAblEryG0QwkKcgWIivR3WXs/pub
First define an alias at the data beginning
Import,1C_Opening,https://docs.google.com/document/d/e/2PACX-1vSz8gq9LwJQ2UY5El6czdaElyvzSjQMx1dvrIh9Ss_0-muXDwr9-7N8bAblEryG0QwkKcgWIivR3WXs/pub
And then use
Import,1C_Opening
Note :
Until now all Javascript code was included in the data file. With this release it is possible to save every piece of Javascript code in separate files and use the public link in the data file as in this example:
Javascript,https://github.com/stanmaz/BBOalert/blob/master/Scripts/stanmazLib.js
Storing scripts on the web has two advantages :
Note : this feature has been disabled
The drawback of the generic convention card (templates : “BBO Advanced (2/1=GF)” “SAYC - Standard American Yellow Card” or “Simple Modern Acol”) is the lack of text formatting features. The problem is that BBO software removes new line characters and elimines multiple spaces or tabs. The text displayed to the opponents is very hard to read.
This problem can be solved by using underscore characters instead of spaces. BBOalert replaces then underscores by non-breaking spaces before saving data on the server. To be correctly displayed to the opponents each line of text should be approximately 25 to 40 characters long.
The BBO convention card editor is not easy to use. With BBOalert the CC text can be prepared in advance and included in the data in the format :
CC,<fieldID>,<text>
Then :
You can use this template to prepare your data (hint : set the keyboard to overstrike mode to preserve text line length). The field ID’s are self explanatory.
CC,summary
… text for “System Summary” section
CC,ntopen
… text for “Notrump Openings” section
CC,majoropen
… text for “Minor Suit Openings” section
CC,minoropen
… text for “Minor Suit Openings” section
CC,level2open
… text for “2-Level Openings” section
CC,other
… text for “Other important notes” section
CC,doubles
… text for “Doubles” section
CC,ntocalls
… text for “Notrump Overcalls” section
CC,socalls
… text for “Simple Overcalls” section
CC,over1nt
… text for “Over 1NT Openings” section
CC,jocalls
… text for “Jump Overcalls” section
CC,overtox
...text for “Over Takeout Doubles” section
CC,directq
...text for “Over Takeout Doubles” section
CC,slam
...text for “Slam Bidding” section
CC