Talk:About Formal Specs

Mike: Eh? Why bother fixing it if no one uses it? Besides, it really is an int, unless I'm very much mistaken. QB doesn't do Bytes.

TMC: I changed it back. I'm trying to figure out what all these composite string types are (how many of them are actually used somewhere?). I might scrap actually using BBSTR on .DT6 to simplify.

TMC: these strings are really confusing me. By the length of the string, you mean the length in bytes? I better go change the string lengths on .DT6

Edit: Wait, what about BBSTR? That is one character per INT, so should that length be in INTs?

NeoTA: There are only two string styles in lumps: (8bit len, chars), (16bit len, chars). for 16bit strings, you have like these byte sequences: 8 0 'A' 0 ' ' 0 'S' 0 't' 0 'r' 0 'i' 0 'n' 0 'g' 0

and maybe some trash following (you must always know the max. length for the field.) So yes, it is in INTs.

Mike: Yeah. The length you put in (here) is the byte length, including the "header". The reason it's bytes instead of ints is because if you're trying to sum up the length of a lump, and you're looking at BBSTR (34), it's easier to say "Oh, that's a string which takes up 34 bytes", rather than "Ok, it takes up 16 characters, each of which is two bytes... Ooh, and the header... ok, it's 34 bytes"

NeoTA: 'it takes up 17 16bit characters' works. Since it is conventional to have these types of strings, you can also use the convention of specifying stringlengths including the actual-length value at the start.

Mike: Wait, if a 16 int-character string (with one int as length) is written as 17 characters, that's more confusing.

NeoTA: more confusing than specifying string length in units of bytes when it is actually in units of shorts?

Mike (written at the same time as the NeoTA's next statement) Yes, more confusing. A 16 Character string does take up 34 bytes. It does not, however, take up 17 characters. It takes up 16 characters, plus the descriptor, which comes to 34 bytes.

Note that I'm not specifying the length of string, I'm specifying how much room it takes up in the file.

(If you want to get picky, and specify things in terms of their unit size, then feel free to add a BIT type to the list, for all the bitsets, and put offsets in like 12.125)

NeoTA: Too, these VSTR/FVSTR/BBSTR names are redundant. And no (length byte + character bytes + trash) type is specified. I'll remedy it.

Mike: Actually, that gives me an idea. How about we set up strings like this:

??STR (1i+16i=34b) That means 1 INT header, with 16 INT characters, with a total length of 34 bytes.

NeoTA: Good idea! Then we need.. NSTR, VSTR and FVSTR types in all. (one nullterm, one length+characters but no junk, one len+chars+junk.)

Mike: Traditionally, NULL is represented by "Z", and null-terminated strings are called ZStrings, so we should do the same. I fixed that up, and renamed NSTR to ZSTR.

TMC: Unfortunatly, when I said that the length of a BBSTR is stored in either an INT or a LONG, I did not make a mistake. For some stupid reason, some of them actually use LONGs (or at least - that is what appears to be the case. Seems to be the "best" explanation for an extra unused INT)

Edit: On second thought, it's not stored in the same way as nonsensical QBASIC LONGs. The source describes the format as "extra badly stored string(by word with gap)"

Mike: I'm currently working on a side-project which is a utility for the OHR (details are secret for now!). I have two functions to read the INT-Strings, one which reads the length-INT, then reads the rest of the string. The second one reads the length-INT, reads (and discards) the second INT, and proceeds like the first. So far, it seems to work ok, suggesting that it's just a random stupid thing that we have to live with.

NeoTA: TMC, so write like 'FVSTR(1i+1i+20i=44b)' and add a note 'second int is wasted' to the desc. These are exceptional, much like PLOTSCR.HSD's length+data+no junk strings, so it's better to mark them like that than have a different typecode for a slight deviation.

Bob the Hamster (talk) 10:15, 24 August 2013 (PDT): Ichiro mentioned that when he was implementing RELOAD in Java, that the endianness of the VLI's needed to be the opposite of what is indicated in the examples:

"Finished the routine that interprets a RELOAD file! Turns out that a VLI in the RELOAD specification is little-endian, as opposed to the big-endian pseudocode in http://rpg.hamsterrepublic.com/ohrrpgce/About_Formal_Specs. Next step for me is to present a releasable project: a GUI RELOAD structure snooper."