structure of DLM files

[Gerben42]

Hi, I was wondering if any of you could tell me what the structure of DLM files is.

 

I have noticed that there is a checksum and then some lines which look like:

 

Board 01=cgcajjjnakpkchipnjhmbmbpbh022

 

What's annoying is that these files always seem to go to 100 when we generate them and then our scoring program tries to find the optimal contract for all 100 boards even though we only need 27 :( I would like to know how this file is built up so I can edit it and perhaps write a script to throw out the "extra" boards that our Duplimate puts in it.

 

And as a bonus, try to figure out how I can read the cards from this piece of letter mess.

[RMB1]

Hi, I was wondering if any of you could tell me what the structure of DLM files is.

 

...

 

Board 01=cgcajjjnakpkchipnjhmbmbpbh022

 

...

 

And as a bonus, try to figure out how I can read the cards from this piece of letter mess.

 

Are there strings of 26 letters, each letter between a and p (16 letters)?

If each position in the string represents two cards C2,C3; C4,C5; C6,C7; ...

then the letter would tell you which two hands the two cards are in a=N,N b=N,E c=N,S upto p=W,W

 

?

 

Robin

[Gerben42]

Are there strings of 26 letters, each letter between a and p (16 letters)?

If each position in the string represents two cards C2,C3; C4,C5; C6,C7; ...

then the letter would tell you which two hands the two cards are in a=N,N b=N,E c=N,S upto p=W,W

 

?

 

Robin

 

That's great, thanks :) You don't happen to know how to build the checksums as well?

[blackshoe]

The pbn standards are found here. Various programs for dealing with pbn are found here.

[gordontd]

Are there strings of 26 letters, each letter between a and p (16 letters)?

If each position in the string represents two cards C2,C3; C4,C5; C6,C7; ...

then the letter would tell you which two hands the two cards are in a=N,N b=N,E c=N,S upto p=W,W

 

?

 

Robin

I think it starts at the other end, with SA, SK ...

[BumJr]

The following information was posted in rec.games.bridge in 2011. It confirms what has been said here, but doesn't answer the question of how to calculate the checksum:

 

DLM is the easier format of the two to understand. It uses the Windows

INI text-based structure:

 

[sECTION]

KEY=VALUE

KEY=VALUE

.

.

.

[sECTION]

KEY=VALUE

.

.

 

If you're looking to decode it, everything you want is in the

[Document] section. The key fields you need are:

 

From Board=X

To Board=Y

Board NN=<board data><checksum>

 

There should be Y+1-X "Board NN" key/value lines.

 

<board data> is always 26 characters long. Each character is an

alphabetic letter between a and p, representing the numbers 1 to 16.

Each number encodes two hand positions (1="NN" through to 16 ="WW").

 

Once decoded, you have a 52 character string of hand positions

(N/E/S/W) that maps to a card deck, organised SHDC (4 x AKQJT98765432).

 

eg:

 

Board 01=jlifaelnecgmoldfjmcflinlap023

 

This decodes like this:

 

j l i f a e l n e c g m o l d f j m c f l i n l a p

SE SW SN EE NN EN SW WE EN NS ES WN WS SW NW EE SE WN NS EE SW SN WE SW

NN WW

 

And now you have the mapping between hands and cards.

 

I didn't work out the checksum (but I know both the board data and

board number are incorporated), but that's only critical if you're

trying to _write_ a DLM file.

[gordontd]

What's annoying is that these files always seem to go to 100 when we generate them and then our scoring program tries to find the optimal contract for all 100 boards even though we only need 27

I'm surprised by this. The information is in the dlm file as to how many boards have been used. Sounds like an issue with the scoring program rather than the dlm file format.

[PeterAlan]

That's great, thanks :) You don't happen to know how to build the checksums as well?

As I understand it, the "checksums" aren't proper checksums:

 

• There's a so-called “Checksum” field at the top of the file - I'm told it's just #Boards+1 if #Boards is even, but #Boards-1 otherwise!
  

• The two checksum digits at the end of each deal line are apparently just the deal number successively XOR-ed with each card coding - I've not attempted to verify this.
  

[writerman]

As I understand it, the "checksums" aren't proper checksums:

 

• There's a so-called “Checksum” field at the top of the file - I'm told it's just #Boards+1 if #Boards is even, but #Boards-1 otherwise!
  

• The two checksum digits at the end of each deal line are apparently just the deal number successively XOR-ed with each card coding - I've not attempted to verify this.
  

 

 

Just tried to calculate checksums using the above then comparing with the original. The result for the board checksums is always 1 out from the original - ie last bit set in original => not set in mine and vice versa. In other words, the seed for the XOR checksum is 1, not zero. In the case of the main checksum it's just the XOR of the lowest and highest board no.

 

Also note that the individual board checksums are three digits not two. These digits are the decimal representation of the single byte checksum.

 

Keith

[JmBrPotter]

Just tried to calculate checksums using the above then comparing with the original. The result for the board checksums is always 1 out from the original - ie last bit set in original => not set in mine and vice versa. In other words, the seed for the XOR checksum is 1, not zero. In the case of the main checksum it's just the XOR of the lowest and highest board no.

 

Also note that the individual board checksums are three digits not two. These digits are the decimal representation of the single byte checksum.

 

Keith

 

Thanks to all of you. I've been working on a dealing machine file verify and translate utility. This discussion helped me add Duplimate for Windows *.DLM format to the library. The current version accepts two input files, verifies them to determine whether they represent the same board set, and when there is a third file and the board sets match reformats the inputs to create an output file in the specified format. Now, the supported formats are as follows:

 

*.ALL: DEAL305 format ( rw )

*.BRE: Autodealer format ( rw )

*.BRI: Duplimate format ( rw )

*.CSV: Comma Separated Values text format ( rw )

*.DGE: Duplimate format ( rw )

*.DLM: Duplimate for Windows format ( r )

*.DUP: Duplimate format ( rw )

*.HRF: Duplimate Hand Record Format ( rw )

*.HDM: Hand Dealer for Macintosh ( r )

*.PBN: Portable Bridge Notation format ( rw )

*.RBN: Richard's Bridge Notation format ( rw )

 

Any help with adding *.LIN, *.GIB, or other interesting formats would be appreciated.

 

The intended objective focuses on dealing machine operations. Given two files for the same event and session, the utility can verify them against one another---potentially helpful if there is some confusion about the correct file to use for dealing the boards. Also of occasional helpfulness, possessed of a dealing machine file in a format alien to one's dealing machine, this utility may provide a reformatted file for the same board set in a form acceptable to the dealing machine.

 

Thanks,

[Briand1]

I'm new to this forum, hence the rather late reply. I have spent a while decoding all the lines in a dlm file and written the results up in a short word doc. Most of what has been said here is correct - all the checksums are sequential bit-wise exclusive ORs (XOR). The reason that the checksum line that shows the file checksum as #boards +1 if the number is even and #boards -1 if it's odd is only true if the low board number is 1. As follows:

1 XOR 32 becomes 000001 XOR 100000 = 100001 i.e. 32

1 XOR 31 becomes 000001 XOR 011111 = 011110 i.e. 30

 

However if you play board 10 to 32

10 XOR 32 becomes 001010 XOR 100000 = 101010 i.e. 42

 

Actually, even this is only part of the story because 2 other factors, the dealing method and next board to be dealt are also included in the checksum.

 

If you're still interested I'd be very happy to send the .doc with all the details explained.

 

Brian