2 Modifications to FD/BBO required

[fred]

It seems there are 2 important areas in which the latest versions of BBO and FD need work. The purpose of this post is to solicit opinions about how best to implement these changes, especially from those of you who have had some experience using FD.

 

Note to FD file creators: Don't be nervous - the changes I am referring to will not have any impact on your existing files.

 

Note to everyone: No doubt there are other areas of FD/BBO that need improvement and no doubt this facility will continue to evolve. Suggestions are always welcome, but in this thread please let's stick to the 2 issues that follow:

 

1. "Floating conventions"

 

Given the way things are now, it is all but impossible to include a convention like RKCB in a .bss file. The reason is that there are MANY different auctions in which RKCB can arise and it would not be practical for an FD file author to try to define all of these.

 

The way things are now, FD files that represent conventions are currently added to one specific place in the tree that represents a partnership's bidding agreements.

 

I believe the best way to handle this is to define a new type of convention file that does not have a single specific location in the tree. For RKCB it would be nice to be able to express "use this file for any 4NT calls that are not explicitly defined as something else".

 

I am pretty sure that would work fine for RKCB, but you would need something stronger for a convention like "4S is RKCB when hearts is the agreed suit". For this to work, we would need a way to express to FD "this only applies when a given suit has been agreed" (maybe the much-maligned "outcomes" will not end up being useless after all!). Another example: "all undefined low-level doubles are for takeout". Here we would need a way to tell FD "this only applies when the last bid was at the 1, 2, or 3 level" (or whatever).

 

All of these things can be done through programming, but the more expressions like this that I need to teach FD about, the harder my task.

 

So the questions I have are:

 

Can you think of a better way to handle this issue?

 

Assuming you think that my approach is reasonable, what types of expressions NEED to be included in terms of defining when a floating convention applies?

 

2. Handling bids that have different meanings depending on the meanings of the opponents' bids.

 

Suppose your RHO opens 1NT and your partnership uses 2 different defenses to 1NT (depending on the strength of that bid). For example, if 1NT is weak you play DBL as penalty, but if 1NT is strong you play DBL as part of the DONT convention (that is, it shows a 1-suited hand).

 

The FD file structure currently supports this notion (by using the "qualify" field to create a label that describes an opponent's bid). However, there is currently no interface in BBO to allow a player to select which meaning from a call with multiple definitions should be used.

 

It would be nice if FD was smart enough to decide on its own which of 2 or qualified bids is being used, but I don't think that is practical. The only other solution is for the user to make this decision. So, for example, when an opponent opens 1NT and you have 2 (or more) qualified definitions of a 1NT opening for the opponents, you will be asked something like "Is that weak or strong?". The answer you provide would then be used by FD to help provide an appropriate explanation for the bids that your partnership makes.

 

I am not exactly thrilled with this solution since the programming with be awkward and since some users will no doubt find it annoying to have to answer such questions, but I can't think of anything better.

 

Any suggestions?

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[hotShot]

Well just some ideas ....

 

ad 1:

Allow to define a bidding tree fragment that is not yet attached to the bidding tree.

As for example RKCB:

 

basebid, question ( fitsuit ? ) can be attached to bids 4NT, .......

step1 0 | 3 aces of 5 counting K of <fitsuit> as ace

step2 4 | 1 aces of 5 counting K of <fitsuit> as ace

step3 2 | 5 aces of 5 without <fitsuit> Q counting K of <fitsuit> as ace

step4 2 | 5 aces of 5 with <fitsuit> Q counting K of <fitsuit> as ace

 

The bidding box should have a button "anker convention at this bid" showing the list of unattached conventions defined.

The programm can now attach "basebid" to the bid made ask for the fitsuit, and it can attach step 1..4 to next 4 bids.

 

ad 2:

Define a standard for alert messages:

 

HCP Range

min/max cardlength for each suit

free text field

 

This will make communication easier even without the use of FD, as dialog box and display can use the selected language of the player.

Additionally FD can read that information, and act on it.

It might be a good indea to cache this information as long as all players stay at the table or a partnership is playing a tourney. This way the players will have to answer the question just once.

 

Don't let it turn your hair grey .......

[hrothgar]

Regarding Floating Conventions:

 

There are an enormous number of different floating conventions that might crop up...

 

Precision type asking bids

Relay style auction termination mechanism

Redwood/Blackwood variants

yada, yada, yada

 

From my perspective, you are going to need to make a fundamental choice between

 

1. Running yourself ragged fielding requests to support "just one more" floating convention.

 

2. Biting the bullet and adding some kind of scripting utility so players can build their own floating conventions.

 

While I very much agree that this feature would dramatically improve the FD application, I think that it might be premature to add this functionality. If it were me, i'd take a wait and see approach. For the moment, don't add any support for Floating Conventions. Let players get more experience using the application. Listen to what they have to say...

 

My gut tells me that you'll be better positioned to make a well informed decision two to three monthes after roll out.

[cherdano]

Richard, regarding scriptability: I agree this would be nice, but I think it is just impossible to do this without an overly complicated user interface etc.

 

What I have been thinking of is doing this with external scripts. More specifically, I would like to write a python(*) module that can parse and write out FD files, has some understanding of auctions etc. Then you could easily write a python script that generates a full FD file for, say, the shape-showing relay auctions of a precision system. You could also easily do some simpler stuff just from the command line of the python interpreter.

 

It would also be useful to anyone writing a program to produce a graphical printable presentation of an FD file.

 

Unfortunately, I have little time to do this at the moment. Still I am convinced that something like a script language to describe a relay system should be done externally, and not by the FD GUI application.

 

Sorry for this somewhat offtopic post.

 

Arend

 

(*): Why python? Because

1. It has to be a script language, so that you can write both little programs to generate FD trees, and do smaller things from the command line

2. It is a very intuitive language, so that everybody who has ever done programming in any language will have no difficulty using it.

3. I think a python module works well for this.

4. Personal preference.

If someone else wants to do the same in a different language, I wouldn't mind helping and ignoring my own personal preference, however.

[hrothgar]

Richard, regarding scriptability: I agree this would be nice, but I think it is just impossible to do this without an overly complicated user interface etc.

 

What I have been thinking of is doing this with external scripts. More specifically, I would like to write a python(*) module that can parse and write out FD files, has some understanding of auctions etc. Then you could easily write a python script that generates a full FD file for, say, the shape-showing relay auctions of a precision system. You could also easily do some simpler stuff just from the command line of the python interpreter.

 

It would also be useful to anyone writing a program to produce a graphical printable presentation of an FD file.

 

Unfortunately, I have little time to do this at the moment. Still I am convinced that something like a script language to describe a relay system should be done externally, and not by the FD GUI application.

 

Sorry for this somewhat offtopic post.

 

Arend

 

(*): Why python? Because

1. It has to be a script language, so that you can write both little programs to generate FD trees, and do smaller things from the command line

2. It is a very intuitive language, so that everybody who has ever done programming in any language will have no difficulty using it.

3. I think a python module works well for this.

4. Personal preference.

If someone else wants to do the same in a different language, I wouldn't mind helping and ignoring my own personal preference, however.

I have no preference regarding embedding a macro language within the FD file versus using a macro language to create an FD file...

[luke warm]

i might be way off base here, tell me if i am, fred... right now we have to merge conventions, but i'm not sure exactly how that works... say for example that i play with arend and he likes bergen raises in a 2/1 structure... so i merge that in... now if i play with han and he hates bergen raises, what happens if i merge another major structure in to the same base 2/1 file? does it overwrite the first? can it even be done?

 

the reason i ask is, maybe there's a way to use different (is this what you mean by floating?) conventions for any number of base systems but not have the ones we use affect the overall structure... iow, no 'merge' command but a 'use' command.. it might mean that a person would have to add conventions to the base system every time s/he played, and i don't know if that's good or bad

 

with the 'use' rather than the 'merge' command, we can have two (or more) defenses to nt, for example, and just 'use' whichever we need at that time.. i can see 2 people agreeing on bbo 2/1 (the base system) and agreeing on any number of treatments to 'use' for that session... does that make sense? i reread it and it does to me, but maybe that's cause i know what i'm trying to say, heh

[DrTodd13]

The problem is inherently massive. Any attempt to dumb it down will yield incorrect results. When is 4N quantitative, when is it both minors, when is it RKCB? Unless you

specify the sequences and define the meaning in each sequence then you'll get wrong answers. If you are going to ask the user which one it is then what is the point of FD? If you tell people that they have to specify each sequence then they won't do it because it is too much effort. Pick your poison. Perhaps the right answer is something called a convention card.

 

Todd

[fred]

i might be way off base here, tell me if i am, fred... right now we have to merge conventions, but i'm not sure exactly how that works... say for example that i play with arend and he likes bergen raises in a 2/1 structure... so i merge that in... now if i play with han and he hates bergen raises, what happens if i merge another major structure in to the same base 2/1 file? does it overwrite the first? can it even be done?

 

the reason i ask is, maybe there's a way to use different (is this what you mean by floating?) conventions for any number of base systems but not have the ones we use affect the overall structure... iow, no 'merge' command but a 'use' command.. it might mean that a person would have to add conventions to the base system every time s/he played, and i don't know if that's good or bad

 

with the 'use' rather than the 'merge' command, we can have two (or more) defenses to nt, for example, and just 'use' whichever we need at that time.. i can see 2 people agreeing on bbo 2/1 (the base system) and agreeing on any number of treatments to 'use' for that session... does that make sense? i reread it and it does to me, but maybe that's cause i know what i'm trying to say, heh

Sorry if I misunderstood your question, Luke, but the idea is that you would save different convention cards in different files. So if you and Arend play, you might want to start with the base 2/1 file, add in the Bergen raises file (and files representing other "non-standard" conventions), and then save the file with a meaningful file name like Luke-Arend.bss on your hard disk. Then, when you play with Arend in the future you can open and use this file without having to select your base system and conventions every time. You can create another file that represents your system with Han, save it, and then open and use it in the sessions you play with him as your partner in the future.

 

If a given bidding sequence is defined twice, once in the base file and once in a convention file, the meaning in the convention file takes priority. If the user selects 2 or more conventions that try to define the same bid (Drury and Reverse Drury for example), FD will arbitrarily decide which definition to use. Probably the software should warn the user if this state of affairs exists.

 

Please clarify if the above does not answer your questions and I will do my best to explain things.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[luke warm]

no, i think you answered it... anytime a convention is added, the file to which it was added is changed..

 

i had wanted to know if we could 'use' different conventions with the base system file, depending on our partner or other factors, without actually changing the base, but your answer suggest this won't happen... thanks fred

[fred]

The problem is inherently massive. Any attempt to dumb it down will yield incorrect results. When is 4N quantitative, when is it both minors, when is it RKCB? Unless you

specify the sequences and define the meaning in each sequence then you'll get wrong answers. If you are going to ask the user which one it is then what is the point of FD? If you tell people that they have to specify each sequence then they won't do it because it is too much effort. Pick your poison. Perhaps the right answer is something called a convention card.

 

Todd

For sure the problem is massive, but:

 

1) Most bids in most systems are not like 4NT in SAYC or 2/1.

 

2) For most people 4NT is usually some form of Ace-asking bid. If you make an effort to define all the non-Ace-asking 4NTs and then use a "floating RKCB file" (or whatever) for all undefined 4NTs, I believe that this problem can be effectively managed.

 

3) We are fortunate in that there are a lot of talented and dedicated people who are working on these files and their numbers will surely grow once the general BBO membership is made aware of this facility. The initial files we release may be far from "complete" but they will evolve over time. I think it is likely that within the first 6 months or so that our files for the systems that are used by 99% of our members will display accurate information almost all of the time.

 

4) The only time you have to ask the user what definition should apply is when the meaning of the opponent's bid has an impact. No doubt it is possible to automate this process as well, but that goal is too ambitious for the first release.

 

5) "Average players" an unlikely to get involved in making FD files. They will use existing templates and add their favorite conventions. The people who create and maintain these files will be the sort of people who are able to deal with the challenge of this task.

 

6) Convention cards are not a good solution to this problem. Traditional CCs contain very little information and force the opponents to ask a lot of questions if they want to know what to expect from a given bid. For example, a quick glance at the standard ACBL CC (which is at least as effective as most of the other CCs I have ever encountered) reveals that there are exactly 4 checkboxes that deal with the 2nd round of bidding. These are checkboxes that specify forms of NMF and 4SF. Suppose the box for NMF is checked on your opps' CC. You have no idea if this applies over 1NT rebids, 2NT rebids, or both. You have no idea if the opener will show 3-card support first, 4 in the other major first, show hearts first, or something else. You don't know what method (if any) the opps use to check for 3-card support after 1H-1S-1NT or 1H-1S-2NT. I could go on, but hopefully you get the point: if you want to know the answers to any of these questions you are going to have to ask and the opponents are going to have to answer.

 

FD eliminates the need to ask and answer such questions. It also eliminates the possibility that either the questions you ask or the answers you receive will be misunderstood. Furthermore, I believe that this facility has tremendous educational potential. In my view it is easy to conclude that FD offers several important benefits over traditional CCs.

 

I agree with you that it is going to take a lot of work for FD to always display an accurate explanation and that "always" will probably never be achieved. However, the nature of FD is that it will never display an incorrect explanation (unless the author types one in) - it will display nothing if it doesn't "know" what a bid means. In these cases (which will become increasingly rare) the players can ask and be no worse off than they were when using traditional CCs. Furthermore, if there is a mistake in an FD file that causes an incorrect explanation to be displayed, the players can use chat or the standard alert explanation mechanism to inform the opponents of this state of affairs.

 

No offense intended, my friend, but (as you probably figured out) I think your post is way off the mark.

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[inquiry]

What i think would be helpful is a copy tree from here.. and then be able to paste anywhere....

 

Working example... I have full 1NT response structure. So after

 

1NT-PASS-the tree is complete... now if I wanted to use this same structure (system on) after we over call 1NT I should be able to copy and paste..after parnters 1NT and their pass to

 

(1C)-1NT-(Pass)- <<<----here

(1D)-1NT-(Pass)- <<<--- here

(1H)-1NT-(Pass)- <<<--- here

(1S)-1NT-(Pass)- <<<--- here

 

but you can not.... so just an extra paste option would be nice.

[hrothgar]

2. Handling bids that have different meanings depending on the meanings of the opponents' bids.

I hate to sound like a broken record, however, this strikes me as another case where delay might be more useful than not...

 

From my perspective, the best way to proceed would be to work on some kind of list documenting different examples where players would like to employ some kind of conditional logic. In an ideal world it might also be possible to estimate the frequency with which different different options are required:

 

75% of players use a "strong" NT opening / 25% use a weak NT opening

65% of players use a "natural" 1♣ opening / 20% use a "Polish" 1♣ opening / 15% use a "strong" 1♣ opening

 

I agree that it would be VERY difficult to automate any kind of conditional logic. Lets use a very simple example like a pair that uses a different defense to a weak NT opening as opposed to a strong NT opening... In order to develop any kind of conditional logic, you need to define a standard vocabulary that can be used to describe hand strength... What happens if pair 1 defines its strength based on a Milton Work type 4-3-2-1 scale but pair B evaluates hands based on a 6-4-2-1 system?

 

With this said and done, I suspect that there are some examples in which it might be possible to develop a standardized vocabularly:

 

Case in point: It might be possible to develop a heirarchy for 1♣ openings

 

1. Natural

1a. Promises 4+ cards

1b. Promises 3+ cards

1c. Promises 2+ cards

 

2. Artificial

2a. Strong

2b. Nebulous

3c. Transfer

 

In short: If you can standardize a heirarchy, you can automate the logic...

 

I think that listening different examples where people would want to apply conditional logic is the first step in determining whether you can create a heirarchy...

[DrTodd13]

Fred,

 

I'm saying the CC is useful for things like blackwood. I was not saying the a CC is better than FD for handling the automation of low-level bidding. My point was that if you are going to require someone to ask what 4N means and they say blackwood that perhaps a CC is a better way to find out the variety of blackwood. I'm just saying that FD is not a panacea that solves every problem and covers every situation. There may still be a need to some classic CC sections to handle other aspects of bidding/play.

 

Todd

[fred]

What i think would be helpful is a copy tree from here.. and then be able to paste anywhere....

 

Working example... I have full 1NT response structure. So after

 

1NT-PASS-the tree is complete... now if I wanted to use this same structure (system on) after we over call 1NT I should be able to copy and paste..after parnters 1NT and their pass to

 

(1C)-1NT-(Pass)- <<<----here

(1D)-1NT-(Pass)- <<<--- here

(1H)-1NT-(Pass)- <<<--- here

(1S)-1NT-(Pass)- <<<--- here

 

but you can not.... so just an extra paste option would be nice.

I will include this in the next version (most likely to be released within the next couple of days). Thanks for a good suggestion, Ben.

 

The next version will also contain a simple mechanism for including what I have been calling "floating conventions". I have made the necessary programming changes for this to work and it seems to work well (at least for the RKCB example we have been discussing).

 

Still not sure about the best way to handle opponents bids that are "qualified". I like Hrothgar's suggestion of a standard vocabulary (which would allow for this process to be completely automated). Thinking...

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

[hrothgar]

Still not sure about the best way to handle opponents bids that are "qualified". I like Hrothgar's suggestion of a standard vocabulary (which would allow for this process to be completely automated). Thinking...

One additional comment regaridng a standardized vocabulary:

 

Don't make the best the enemy of the good...

 

I doubt that its possible to create a vocabulary that will handle every possible case.

However, if you're able to handle "common" cases this will meet the needs to 90% of the users...

[hotShot]

What i think would be helpful is a copy tree from here.. and then be able to paste anywhere....

 

Working example... I have full 1NT response structure. So after

 

1NT-PASS-the tree is complete... now if I wanted to use this same structure (system on) after we over call 1NT I should be able to copy and paste..after parnters 1NT and their pass to

 

(1C)-1NT-(Pass)- <<<----here

(1D)-1NT-(Pass)- <<<--- here

(1H)-1NT-(Pass)- <<<--- here

(1S)-1NT-(Pass)- <<<--- here

 

but you can not.... so just an extra paste option would be nice.

I will include this in the next version (most likely to be released within the next couple of days). Thanks for a good suggestion, Ben.

 

The next version will also contain a simple mechanism for including what I have been calling "floating conventions". I have made the necessary programming changes for this to work and it seems to work well (at least for the RKCB example we have been discussing).

 

Still not sure about the best way to handle opponents bids that are "qualified". I like Hrothgar's suggestion of a standard vocabulary (which would allow for this process to be completely automated). Thinking...

 

Fred Gitelman

Bridge Base Inc.

www.bridgebase.com

The ability to 'Copy and Paste' is always usefull but wouldn't it be better to allow a 'multiple bid' at a position?

 

{1♣,1♦,1♥,1♠} - (1NT) - (pass) - ?

 

If the structure is changed one would only need to change it once! Otherwise one might forget to update all the copies.

 

How do you handle:

 

(1♣) - (1NT) - ?

 

If 1 NT natural (some range), or if it is polish (1♦ and a 4card Major) or something else?

 

I bet the bidding in 3rd place might be different.

 

 

If one wanted to cover all possible bidding sequences there are d * ( 36! )^4 of them. d stands for the average multiplicity of the meaning a bid. This is quite a lot .......

[david_c]

The problem is inherently massive.  Any attempt to dumb it down will yield incorrect results.  When is 4N quantitative, when is it both minors, when is it RKCB?  Unless you

specify the sequences and define the meaning in each sequence then you'll get wrong answers.  If you are going to ask the user which one it is then what is the point of FD?  If you tell people that they have to specify each sequence then they won't do it because it is too much effort.  Pick your poison.  Perhaps the right answer is something called a convention card.

I think Todd's point is a good one. FD works by looking at the bidding sequence and seeing whether is has any information about this sequence. In theory that's all you could ever ask for, because any bidding sequence can be given a meaning. But in practice there are some agreements which are impossible to describe to FD in this way. The algorithms for deciding what a bid means are just too complex.

 

Let's take a WBF convention card for comparison. It has a number of sections, including (in no particular order):

1. A summary of the system, and "things the opponents should know".

2. Carding methods.

3. Opening bids and responses.

4. Defensive and competitive bidding.

5. Slam conventions.

6. Doubles.

7. "Other agreements".

 

FD files currently have separate sections for (1) and (2). Everything else has to go in the "main" part of the file. This works excellently for (3). It's more problematic for (4) because you have to define what the opponents' bids mean, but still OK here. But it's fairly hopeless for (5), (6) and (7).

 

IMO, the only way to solve this problem is to give our FD files separate sections for things like (5), (6) and (7), written essentially in plain text, which the opponents can look up if they want to. Then FD would not give specific information about each individual slam try sequence (say), but I think we have to accept that it's not possible to write a file which does this. (Sure, you could make it work adequately for some particular conventions, but I bet that whatever trick you use to do this, it can't be applied for other sorts of conventions.)

 

Basically, as Todd says, make it work more like a convention card. You can keep the nice pop-up explanations for simple sequences like 1NT - (pass) - 2♣, but if the opponents want to know your agreements about a 4NT bid on the third round of a competitive auction, they have to look at your general notes (which would be readily available in some way).

[Chamaco]

I think it would be nice to have a popup window with all the PREALERTS at the table when u sit down.

 

Things such as: NT range, ultralight openings/response, unusual 1/2/3 level openings, special carding, and other specific toys.

 

the popupwindow would appear automatically at the table as opps sit down

[hrothgar]

I think it would be nice to have a popup window with all the PREALERTS at the table when u sit down.

 

Things such as: NT range, ultralight openings/response, unusual 1/2/3 level openings, special carding, and other specific toys.

 

the popupwindow would appear automatically at the table as opps sit down

I believe that is what the "Convention Card Summary" is intended for...

[Chamaco]

I think it would be nice to have a popup window with all the PREALERTS at the table when u sit down.

 

Things such as: NT range, ultralight openings/response, unusual 1/2/3 level openings, special carding, and other specific toys.

 

the popupwindow would appear automatically at the table as opps sit down

I believe that is what the "Convention Card Summary" is intended for...

I guess so, but it's fundamentally different the summary from the prealert.

 

in the prealert you give info of unusual leads, and, at least at the real table, the prealert is displayed immediately BEFORE the hand, so that opps can quickly try to create meta-agreements for unusual situations.

 

====

 

For example:

in every REAL paper copy of a CC, there is an initial summary of the system and general approach.

 

Yet, specific treatments or unusual methods REQUIRE an ADDITIONAL prealert to opps, despite the fact that there is a written summary in the CC.

 

Reason for this requireent is to allow opps to prepare a method BEFORE the play starts vs our unusual treatments

[hrothgar]

I think it would be nice to have a popup window with all the PREALERTS at the table when u sit down.

 

Things such as: NT range, ultralight openings/response, unusual 1/2/3 level openings, special carding, and other specific toys.

 

the popupwindow would appear automatically at the table as opps sit down

I believe that is what the "Convention Card Summary" is intended for...

I guess so, but it's fundamentally different the summary from the prealert.

 

in the prealert you give info of unusual leads, and, at least at the real table, the prealert is displayed immediately BEFORE the hand, so that opps can quickly try to create meta-agreements for unusual situations.

 

====

 

For example:

in every REAL paper copy of a CC, there is an initial summary of the system and general approach.

 

Yet, specific treatments or unusual methods REQUIRE an ADDITIONAL prealert to opps, despite the fact that there is a written summary in the CC.

 

Reason for this requireent is to allow opps to prepare a method BEFORE the play starts vs our unusual treatments

I don't think that we're actually disagreeing on anything:

 

1. I agree that some form of pre-alert is strongly desirable

2. I am noting that the "Convention Card Summary" can be used to record this same information

3. The only question that remains is how said info should be displayed to end users

 

Option 1: Information is stored in the convention card summary. End users are expected to consult the convention card prior to the start of play

 

Option 2: Information from the convention card summary is automatically sent to the user in a secondary window

 

I can see advantages and disadvantages to either approach.

I prefer Option 1, simply because you have WYSIWYG formating

[han]

What You See Is What You Get??

[Chamaco]

I can see advantages and disadvantages to either approach.

I prefer Option 1, simply because you have WYSIWYG formating

 

I don't know abroad, but in Italy, for specific conventions/treatments, you cannot play them unless Prealerted.

 

It is the responsible of the player playing an unusual method to MAKE SURE that the prealert is done with anticipation before the actual play starts, and simply offering the CC is not enough.

 

I think an automatic popup window would replicate this procedure without too much hassle, no ?

[pigpenz]

Fred is our ultimate goal to be able to let us make our own cards with our regular partners so we can load them ourselves or to just have a database that we have to use that is stored on BBO and we use what they have there?

[hrothgar]

I don't know abroad, but in Italy, for specific conventions/treatments, you cannot play them unless Prealerted.

For better or worse, the FD system will not be compatible with the specific disclosure regulations used by various zonal authorities.

 

Case in point: Consider the whole topic of "alerts".

 

As currently implemented, FD is based on announcements. The concept of an "alert" doesn't exist. Accordingly, FD isn't compliant with ANY alerting regulations currently in existence.

 

At some point in time, Fred might chose to add an alert mechanism to the FD system. Until then, players will be forced to either manually alert bids or ignore the regulations.