BTLT

BTLT isn't anything special, it's just a combination of a couple very complicated libraries, FUIST-STIUF and TLT. FUIST-STIUF is an extension of FUIS-SIUF which is an extension of FUI-IUF.

History

Please excuse any slight errors in the timeline. In the beginning there was a scripter who wanted to be able to store floats in a lossless format to be moved through strings. The first attempt at solving this problem was Float to Scientific Notation; this function was too slow because of how it operated. Soon after that the scripter embarked upon a project to write an LSL bytecode interpretor written in LSL. Around this time the scripter discovered by accident that LSL supported HexFloats, and set about writing the encoder Float2Hex in the style of Float2Sci. To store the floats for the interpretor the FUI-IUF functions were written. During the written of those functions the scripter realized two things, that the process for encoding floats for FUI could be applied to Float2Hex and that writing a interpretor in LSL wasn't worth the work. The process of matching the techniques of each function pushed the thinking forwards to the benefit of both Float2Hex and FUI-IUF. For grins the scripter modified FUI-IUF into FUIS-SIUF and found that it encoded and decoded floats faster then Hex2Float. Time passes and the scripter returns to a mothballed project: Hierarchical linking. This project had a couple of problems, how to store rotations in a tight format in notecards and ugly quaternion math. The problem with notecards is that if a script is going to read them, the lines can be no longer then 255 characters. This is problematic. One solution was FUIST-STIUF, it added trimming to FUIS-SIUF and was designed to be dropped into TLT. Before Float2Sci was even in the works the scripter was looking for a list-string transport functions. Not finding any satisfactory solutions the scripter laid out the TightList standard. It was integral part of the Strife Combat System and the functions were given the names "parse" and "dump". It wasn't until the development of TLTP and TLML did TightList become the official name of the functions. During the development of TLML did there become a need for a version of TL that could restore the type informations. After much thought TLT was created. Because of the memory restrictions of TLML(TLML's extensive feature set and tight syntax resulted in huge amounts of bytecode), TLT had to support drop-in encoders at compile time. Consequently TLT was written with ESL in mind (everything the scripter was writing at that time was written and still is written in ESL).

Why Use BTLT?

BTLT was designed to be a tight format to be used for mostly float based datatypes. It wasn't intended to be particularly fast but it won't be unreasonably slow.

How It Works

Encoder:

• A TLT encoder outfitted with the FUIST family of functions gets first crack at the values.
  • FUIST family of functions encode floats, vectors and rotations to strings.
    1. The float is converted to an integer with the FUI technique.
       • If you took the memory representation of a float and read it as an integer you would have the same output as FUI.
    2. Then the integer is turned into a Base64 string.
    3. Then the any trailing A's and ='s are trimmed off the end of that string.
    4. For Vectors and Rotations a size field is attached to the front. Vectors use a 1 char field, rotations 2 chars.

Decoder:

• A TLT decoder outfitted with the STIUF family of functions.
  • STIUF family of functions do the inverse of FUIST.

Notes: The FUIST-STIUF functions used are revision 2 of the library. R1 was intended as standalone functions from TLT, R2 was optimized to take advantage of TLT, allowing for the stripping of a character from the vector size field.

Code

Haven't finished writing it. The TLT encoder has to be retrofitted and it's not a pretty retrofit. The big issue is how the encoding is performed. The current TLT encoder doesn't abuse memory or CPU time too badly. But to do this encoder properly the encoder will have to be less hackish. --Strife Onizuka 00:05, 19 April 2007 (PDT)