Bliss format byte controversy

From Stunts Wiki
Revision as of 07:59, 13 March 2019 by Cas (talk | contribs)

This article refers to the arguments and problems that resulted from a series of events related to Bliss' handling of metadata and the format byte/extra byte in track files and how this is being solved.

Historical background

Around 2006, Cas was developing a track editor call Castunts for DOS that was to become the inspiration for Cas-Stunts 2.0, which later evolved to Bliss. Castunts included just a handful of the features present in Bliss, but one that it did not have was the ability to store metadata in tracks. Cas knew it was possible to embed extra information by overlaying these files, so it was in his plans to do this. He created a few tracks with his editor that he touched manually with a binary editor to add a track title and author's name to the files.

The fields were placed right after the 1802 bytes if the raw track files, but because this overlay could be lost should the track be edited with the internal editor, Cas also modified the last byte of the raw files, that's normally a zero, to make it 149, making this value an ID for what his editor would become. Castunts 1.0 was never finished and never had the ability to insert metadata in track files.

In May 2015, Cas has agreed to post a track to ZakStunts for the race of that month. He chose to submit 4:00am (4AM.TRK), a track he had made near 2006 and that had already been raced in Paleke's World Stunts Championship, but never free-style. It turned out that this happened to be one of the few track files that had an overlay from the times of Castunts 1.0. The track got uploaded to ZakStunts without a problem, but when racers began trying to post their first replays, they weren't able to. Nobody knew what was going on until Dreadnaut saw the file was longer than expected. Then Cas remembered and explained about the overlay; the track file was truncated and re-uploaded. Problem solved.