stev_hav

I definitely agree that the system-file format needs to be standardized, and that there should be specific methods for recording some additional information. Minimum and maximum expected strength, complete distribution, etc., restrictions/negative inferences, etc., ranking among the higher-priority candidates. I have already made a posting to this effect, to which Fred replied on 9/10 05:14. (in "Full disclosure"). Briefly summarized, he feels that such information belongs within the "comments" area; due at least partially to opponents' convenience in reading the information. And that his posting of 9/2 07:26 more fully explains his reasoning. Whether or not I totally agree, it does appear that Fred has developed and published a functional editing facility, and that his primary interest at this time is in being able to display the resulting files in actual BBO play. It appears more constructive, at this time, to concentrate efforts upon actual development--in the current format--of a fairly-comprehensive system file. Bridge Base - Basic would be one good candidate. Due to its relative simplicity, system-file length (and effort to create) would be minimized; all of its methods are relatively-well understood. In the interests of developing a usable version with minimal delay, perhaps best to begin by defining only uncontested sequences. Hopefully, leading to actual display of something meaningful, in actual BBO play, in the relatively-near future. One logical approach, to involving multiple developers, would be to allocate the various opening bids to different individuals: A. One of a minor. B. One of a major. C. NT openings. D. 2C opening. E. Preemptive openings. I'm definitely interested in contributing to system-file development . . others' comments?

Where did Fred actually come out and request volunteers? He mentioned an intention to do so in his original post, but I haven't seen a post which actually contains such a request. I'm definitely willing to help create a system file, but I would like to be fairly certain that I'm working on a unique section of it. One possible way to subdivide the effort would be to set up sections corresponding to each heading in the "Bridge Base Advanced" summary. Some sort of agreement, concerning file naming conventions, would probably be helpful; so that the name carried a little information about file content. (BBO_ADV_1C1D, BBO_ADV_1H1S, BBO_ADV_1T, . . ). IMO, would probably be wise to agree upon a "coordinator", whose responsibilities would include merging individual contributors' work into a "combined" version.

IMO, the current (1.0.5) file format of "full disclosure" (hereafter FD) needs to be enhanced in three areas: A. Promised distributions. B. Promised HCP ranges. C. Opponents' conventions. 1N (P) 2C (P) 2D (P) 2N (P) 3N (all pass) Opponents, and especially opening leader, tend to have two questions: 1. Is responder promising at least one 4-card major? 2. What HCP does 1N promise? (2) is so common that ACBL procedures require immediate "announcement", by responder, of the promised HCP. (1) depends primarily upon bidding side's agreements as to an immedate 2N response. Current FD format, as to agreements concerning length in specific suits other than the actually-named one, appears inadequate. Transfer responses to NT openings, two-suited overcalls, etc., tend to promise such length; this can be disclosed ONLY in the "comment" area.

I'm trying to get some discussion going, concerning a "generic" format for recording/interchange of partnership agreements. First two posts, to this, go into some detail as to my rationale. I've also created a "first try" version, using XML, of such a format. Subsequent posts go into some detail concerning this. Including both my reasons for "feeling" that entry of an entire "convention card" should be a fairly-simple process, and a few aspects with which I am far from entirely satisfied. I'd really appreciate some feedback, concerning what I've accomplished to date. Group URL: http://groups.yahoo.com/group/Bridge_Metho...ods_Disclosure/ Steven P Haver/602-242-9708/8330 n 19th av 1083 phx az 85021

Primary intent, of my original post, was to advocate standardization of one-line "greetings". Presumably desirable--and feasible--in ordinary FTF competition. Undisputed that implementation of automated methods-disclosure procedures is also "desirable". But, in view of player-acceptance and cost, at best "questionably", near-term, feasible.

It appears that current procedures, in this area, are less than ideal. In my opinion, two changes would do much to improve the situation: A. Use of a standardized "one-line system summary" message. B. Pre-registration (most likely electronic) of "unusual methods". The "system summary" message has become fairly-common practice on OKBridge; basic intent to disclose the "most significant" methods: "2/1, UDCA, Multi, CAPP . . " "Precision, Roman 2d, . . " Opponents are thus placed "on notice" that an artifical 1c and/or 2d opening is "definitely possible"; absent prior agreement on defenses, they are well-advised to (briefly) discuss same. Ideally, there would be standards, concerning what should be included, specific abbreviations, and the sequence of entries. There'd be no requirement that such standards be complied with, nor that any form of message be issued. It would, however, be "strongly presumed" that a standards-compliant message, which included mention of a convention, constituted compliance with any applicable pre-alert requirements. . My primary interest, at this time, is to determine whether there's significant interest in promoting use, and appropriate "standardization", of such messages. Consistently, I am cross-posting to rec.games.bridge, rec.games.bridge.okbridge, and the Bridgebase forum.

Last sentence, of first paragraph of prior (8/15/03 1708) post, reads: "There's really no true method to accurately predict someone's true skill level or playing ability." I fully agree that, as long as four human players are involved, there's no clearly-valid way to determine a given player's skill level. In the fairly-recent past, competence of bridge-playing programs has improved, to at least the "weak intermediate" level. Able to bid reasonably well, at least while both sides are restricted to playing SAYC. NEVER guilty of clear-cut failure to count to 13. Events in which all of the human players were South, partnered and opposed by the same program, might be of considerable interest.

IMO, something along the following lines might be a good way to "get started" with use of computers for FTF play. It assumes the use of already-implemented software; no new development would be required. Supporting software could be either a "public" network (Bridgebase, OKBridge, etc), or a "small group" arrangement (Bridge Baron, etc). Former would probably be "preferable", IF security could be adequately addressed. What follows more-or-less assumes one "non local" player; would also be feasible (and perhaps best in earliest stages) with all four players physically at site. Practical benefit, of allowing off-site player, is that at least some such would be willing to pay a surcharge covering additional expense. Intent of this is to permit one member, of a Swiss or KO team, to be physically remote from the site of a "live" tournament. At least in my opinion, this can be accomplished with minimal impact upon the interests of other contestants, and with very little exposure to any form of cheating. In the interest of brevity, some specifics related to the online software will be omitted. The "online" team will be responsible for provision of the following setup; some of which will require pre-arrangement with the site: A. 3 Laptop computers, each with an Internet connection suitable for online play. Physical setup such that three onsite players can see each other's faces and converse normally; low-profile barriers to keep each player's screen, keyboard, and mouse pad concealed. Preferably, also the ability to make or receive phone calls to the offsite player. B. Pre-duplication of all boards required for play; entry of such boards into one of the onsite computers. C. Having a fifth member of the team physically onsite; to be able to "take over" for absent player should it become impossible to continue online play. At time of entry, every other team will be asked whether it has one pair which is "willing and able" to play one match online. A "no" reply may be made, at this time, without specifying any reason. The Director will attempt to match only "willing" teams against the online team; if integrity of contest requires matching of an "unwilling" team, both tables of match will be played onsite in normal manner. (Fifth member participating). To begin play of each match, Director will make the board images available to the computer. Fifth member of team--or perhaps a knowledgeable caddy--will be available to assist opponents with computer usage; both before, and during, play of any board. "In principle", offsite player has the right to have opponents' convention card faxed; this may not, in practice, be necessary. Specific form of "alert" procedure will be at opponents' option. If both are familiar with "self alerts" (customary online procedure), these should be used; probably best that anything which would need to be alerted/announced at the table be self-alerted. If opponents prefer, standard verbal alert procedure will be used, with minor changes: A. Onsite player will give all required alerts and announcements for his side's calls. B. Opponents "should" give an indication, at time of making an alertable call, that an alert is involved. If this is not done, altho a verbal alert is given, onsite player may require corrective action. In event of mid-hand connection failure at tournament site, fifth player or caddy will be immediately available to help re-establish; in event of offsite player connection failure, some two minutes will be allowed for corrective action. If problem cannot be resolved, Director will determine whether to cancel the board or assign an adjusted score. Tending to cancel the board, unless play has progressed to the point where final outcome is reasonably clear. Should be "presumed" that it's not feasible to continue play of interrupted deal using cards; exceptions--when failure occurs during auction--are conceivable. At least initially, Swiss Team would appear to be most practical. Pair events would tend to involve too many separate individuals; unless a pretty-high percentage of the "willing" pairs were also familiar with the procedures, it would be difficult to finish rounds in timely manner. Knockout would afford Director somewhat less flexibility in matchmaking. Under some circumstances, it might be necessary that BOTH opposing pairs be "willing". Might be viable, however, in bracketed events; if Director were allowed some leeway to deviate, from strict use of masterpoint totals. Offsite player would be "expected to": A. Be one specific and identified person; changed only when it would be permitted to do so in normal play. (Between swiss matches, or after comparison in KO). B. Refrain from any consultation. IMO, however, possession and reference to own convention card ought to be permitted; enforcement of rule against this is difficult enough at table . . C. Ideally, have a phone connection which is usable while online; ability to receive faxes might also be "desirable". Use of any form of "instant messaging" would be prohibited while cards remained concealed, and probably "should be avoided" even between deals. Case of KO opponents also wishing to use an offsite player, assuming software compatability, should be simple enough. Should probably, however, permit only ONE member of each team to be offsite, except perhaps by mutual consent. Fact of expected offsite-player participation should "tend to" be disclosed in pre-tournament publicity; with mention of a url at which details can be viewed. This might well help attendance; something new and novel.

Gold LM -- several Blue Ribbon quals -- available for playing lessons on OKBridge, Bridgebase, or e-bridge. Username -- on all -- is stev_hav. Primary emphasis is avoiding "stupid" mistakes . . more detail is posted at http://members.aol.com/sphboc.

Definitely agree with the basic idea. Would seem best for this to REMAIN in view, and NOT roll off like other chat messages. Might want to "recommend" use of standardized abbreviations, and the sequence in which these should appear. Ex: 2/1, 15-17, PST, 5CM, BGN, J2N, RDRY, INVM . . PST = Puppet Stayman. A few highly-frequent conventions (Stayman, Negative doubles, etc) might be OMITTED; in interest of brevity. Whether or not anything specific is done on this, WOULD seem highly advisable to implement "stored" messages (as are available on OKB).