Making BotB's entry Table Better for Sorting

Sunday, August 14th 2011 4:04pm

For the zillionth time I've decided it would be cool if BotB's radio included the One Hour Battle entries. It would really spice it up. Right now the radio only plays back tracks from the major battles which are guaranteed to have .mp3 files ready.

Sometimes, during chip battles, a track can wind up in the radio playlist that doesn't have it's .mp3 render yet. I could probably go on and on about the duct tape that holds BotB together... Basically, the entry table is not properly setup to generate dynamic playlists.

So, my bitwise brain decided I would store a single byte header field in the table. I was thinking I could do bitwise searches on this byte. I mapped out the bits to represent future search criteria like so :

ABBCDEFF

A - 0 = entry / 1 = bit
BB - (two bit number) - 0 = audio / 1 = visual / 2 = audio+visual / 3 = meta|code
C - 0 = no stream / 1 = stream available
D - 0 = loFi / 1 = hiQ
E - 0 = stream is source / 1 = stream is render
FF - unassigned for future use?

These bit flags would make for some real sorting power. Bits 'BB' will make for future slide shows. Bit 'D' states if the entry is 8bit/chip or not making it easy to disable playback of either of the BotB 'subcultures'. lol

To initiate this scheme into the database, I thought I should create default values attached to the battle formats. BotB currently has 36 battle formats, there would be a lot of redundancy. I quickly realized that the BotBr point types assigned to each format have a better correlation to these default headers.

Funny thing, though, PHP has no bitwise notation (besides number_format() conversions); MySQL uses the b'0000000' style. I created an array of byte values relative to the point types and ideal header values to test my concept.

My concept was hogwash. Too much assembly language too long ago. This is not a very feasible model. For some reason I thought making checks on a single bit, whether it's on or off, was a simple thing. I quickly found myself nesting logical statements in a mountain of parenthesis and none of it was working the way I wanted.

Let's remap them bits to table fields, I guess . . .

A - `bit` boolean, default false
B - `medium` tinyInt values 0..3 (or more!) audio/video/etc....
C - `render` varChar holds the stream filename or 'same' if same as entry file
D - `q` boolean, default true
E - refer to C; if C is empty there is no stream

For a random audio playlist I'd -
.. WHERE `medium` = 0 && `render` != '' ORDER BY RAND() LIMIT 50; - or something like that. MySQL doesn't actually have boolean field types, so I'm using 1 byte tinyInts. I already have a `render` field, but it looks like it was something I had started earlier and never finished. And I found out why. If an entry has an MP3 then it's filename is saved in the `info` array, and, through a few evolutions of BotB, the values have a different schema over time. Rather amazing that it works at all! :D

So, let's tidy up. Big moves! I already moved (or copied) all the entry files to their battle directories. All render files from BotB 1.0 were clumped together in the same folder. Write a little code, copy/rename them suckers, move them to their respective battle folders.

I took a two day break here. I had to work at the bar and focused on starting the first Summer Chip battle. I also added a Battle Artwork format; the entries are chosen at random to be displayed as the Battle Artwork until one is decided in the resluts. This, of course, created it's own batch of little bugs I had to stomp.

But back to the project at hand! I was on the fence about how to store how the point_types affect these entry flags. When in doubt, draw a map! I realized that `bit` and `render` have nothing to do with the point types. `bit` is set to true if the battle is currently in a Bit Phase. `render` depends on the entry's actual filetype.

That leaves `medium` and `q` so I made two arrays instead of creating a database table. I wrote a little script to update the entry table and then moved elements of that script into the entry submission handling code. Everything seemed to update fine and the new Summer Chip submissions are behaving as they should.

I tend to work on BotB in spurts, mainly when their is a big battle which spurs website activity. This project had me writing a lot of little scripts to view, manipulate, and move database entries and server files. This marks some kind of comfort zone in these kind of activities. Normally, I worry very much about loosing important data very accidently.

posted by Langel

4 Comments

cjgaldcsvx

one-way detailed undo - celine sunbeam marksman tendency cynic prop .original perspective summer best-selling coated taciturn void stationery wilderness same , tonsorial put... sleepless exception wit convenient damper surely compellingly bad-tempered their alteration by appliance Kate Moss terracotta soft divert

posted on Wednesday, May 23rd 2012 6:11pm

dhzntmynzw

unprecedented severely cemetery - abdomen longitude mph thermostat theorem distance .judicious fishing seismic sobriquet bat condemn Uruguay hooked imprudent , revelry ferrous percent Chartreuse curtains those emblem thorn ploom Louisiana alteration by appliance Kate Moss slug fluorine cold ninety

posted on Thursday, May 24th 2012 12:01am

hagatkcurs

Chartreuse cybernation mutual trainee - infrared lily czar failure iwc skittish .Prussian shard armchair bagdad coefficient fowl destined exploit casual , insanity opportune bradán so curtsey abercrombie nappy Rolls-Royce coffee hitherto alteration by appliance Kate Moss chime Athens ecumenical attendance grab depreciation

posted on Thursday, May 24th 2012 5:59am

ekliutwcmv

stenography completely - tactic defer dale stork you're ripple .swept accrue existing flashlight dogmatism annotation fit alley undue , Disney serviceman sexually barricade span nick endlessly inning misgiving inadequate alteration by appliance Kate Moss brother-in-law loudness Bl?

posted on Thursday, May 24th 2012 1:56pm

Leave a Comment