Leaderboard

These are 100% custom. This overwrites smile head with orange hair, white racing helmet, blue jacket with star and red legs (don't put PLAYER FIVE LEGS.MIP if you don't want 2 green legs pair in your character builder). PLAYER FIVE FACEs goes to: characters/heads/textures. PLAYER5.MD2 goes to: characters/heads/models. PLAYER FIVE LEGS.MIP and PLAYER FIVE TORSO.MIP goes to: characters/bodies/textures. Remember to backup your files! Download

https://www.youtube.com/watch?v=Kq4XlauEwfE

Well, it seems I've forgotten about this place once again. Sorry for the random disappearance, this was literally just a small one-day project idea which I had and I kinda forgot about it. Although coming back to it, I really want to figure out how this stuff is compressed and stored, as well as the sounds since they seem to use compression as well. I might work on it tomorrow if I can and get to the bottom of this format. If I can get some sort of idea of how this format works by comparing the bitmaps I extracted vs the compressed versions, I might get somewhere. EDIT: Some things I'm noticing after getting a more fresh view on things: The first value in the header seems to be a 32 bit unsigned value, denoting something in terms of length (ie uncompressed size/decoded size). Depending on the file, this value gets marginally larger or smaller (ie the train carts and sounds have much larger values than things like houses and whatnot which only have one frame or many smaller frames) The table at 0x408 seems to be a sort of lookup table, with each value being 32 bits long (4 bytes). The amount of entries in this table from 0x408-0x808 come out to 256 entries, or multiplied by 4, 0x400 bytes. As for what looks up entries in this table, I have a small feeling that the data at 0x808 is just a bunch of byte values referencing this table to make a set of data to be read. Don't have anything official yet, but I do believe that this is a very good hunch considering that while I was messing with the values everything was seemingly random despite the values only being messed with by a tiny bit. This could expain that. It also could explain how this format could be used for sounds as well since this area has been confirmed to not be a palette, but rather a sort of 'palette' of 32 bit values available to use. Again, not entirely sure at this point, but it seems to be a good hunch for now. Once the bitmaps are decompressed, it might be possible that there's another bit of fluff to go through to figure out what format the uncompressed data is in. I'm praying that it's just an uncompressed raw 8bpp bitmap, but with how things are going that might not be the case. I'd also like to test this against sounds as well since it might be easier to figure out the sounds vs the images since sounds are more likely to just be raw data. EDIT 2: I think the table might be in a slightly different format than I thought initially. I'm thinking it might actually be a sort of table which specifies bytes and the number of repetitions of that byte, perhaps in the format <byte> <repetitions> <byte> <repetitions> EDIT 3: I think I'm getting somewhere with this. I'm doing comparisons between the ripped version of house12.bmp I have vs the house12.bmp which is compressed, and it seems to be that I'm somewhat correct. I counted 305 transparent pixels before reaching actual data, and based on the number of 0x55 bytes present at the end of the file, if you counted them and multiplied by 4 you'd get 304. If you add in the other 05 prior to the 55 array it might equal the 305 we're looking for. Now, since each entry in the table is (gasp!) 4 bytes long, we might be able to assume that one of the two hypothesis I had are correct. I'm actually placing my bets on the byte + repetitions because it seems that it would make the most logical sense seeing that every other byte is usually less than 4. EDIT 4: This might be, once again, a little more complicated than I thought. I almost wonder if it's not even a compression format but just an encryption format or something, because this format is used on just about everything from bmp's to wav's even to a file called ee.ini. Honestly at the moment I think that this so called ee.ini might be my best bet on cracking the format since the wav's and bmp's could be under another layer of proprietary formatting, while an INI is a little more easy to guarantee what it will produce. I might actually be able to find a copy of the uncompressed version in RAM while the game runs, or find out how it's uncompressed and go from there. Since it's an INI file it's probably easier to track down than other files. The main issue I've run into is that the data at 0x808 can have values over the length of the table. The table obviously seems to have values used to create the uncompressed data, but I cannot figure out the exact relationship. EDIT 5: Apparently there's an uncompressed EE.ini. Might try to do some comparisons here... EDIT 6: The values used in the table at 0x404 consist only of the values used in the INI, albeit in a slightly different order. However, every value is there. EDIT 7: Not much real progress so far, but, I have found the file loading function in IDA. Apparently the weirdly formatted files are actually supposed to be handled through the resource file extractor. Oddly enough, it was mentioned once by Cyrem, the guy who made the extractor: Luckily I actually found the check for compressed and uncompressed files, so now it's just a matter of reverse engineering the function which decompresses the file. If anyone's curious, the file header is formatted as such: <32 bit word: amount of space to malloc, aka file size> <8 bit byte, something with decompression/compression> <8 bit byte, if 1 file is read as compressed> All compressed files are normal files underneath, with normal file headers and easy-to-edit stuffs. So once I can write a decompression program you can keep the files uncompressed for as long as you please. EDIT 8: This compression... I literally can't even. It's the weirdest compression I've ever seen in my entire life. It might be because I'm looking at in in assembly but I have no idea how I'm even going to attempt to recompress any of these files. Decompression maybe, but how in the world does this work... EDIT 9: Witchcraft. That is the only answer here. Pure witchcraft. EDIT 10: Success has been had. Documentation and a tool will be coming shortly... EDIT 11: While I'm still kinda messing with things, here's an image file I extracted of the launchpad in it's full frameset: This was actually one of the ones I was having difficulty ripping manually. I'm not sure if this is an error with me adding a header to the headerless bitmap, but one of the frames seems to be cut in half on each end for some reason.

[10:44:49 AM] Cyrem: I was hoping to amass car and landscape wallpapers which I usually get off there... seems I have just amassed boobs.

@ Ayliffe : (18 July 2014 - 09:55 PM) I have come up with a theory about Shadowblaze's country. @ Ayliffe : (18 July 2014 - 10:04 PM) (probably) @ Shadowblaze : (18 July 2014 - 10:08 PM) I'm listening. @ Ayliffe : (18 July 2014 - 10:29 PM) Whenever someone guesses his country correctly, he moves instantly to the country next door so we're always wrong @ Ayliffe : (18 July 2014 - 10:31 PM) And his house probably has robot legs on the bottom powered by dubstep

Greets all, So it's been a while since my initial research on the "mysterious bitmaps" from LEGO LOCO, and after a small splurge of research and coding I finally figured out this mysterious format. First and foremost, the format used by the bitmaps is not bitmap specific at all, it's a compression format used by any and all files which appear to be 'unreadable'. The loading order of the game appears to be as such to detect the difference between the two types of files, compressed and uncompressed: Find requested file If it doesn't exist, return 0 If it does exist, request a file handle and copy it to RAM Check the value at 0x5. If it's 0x1, it's compressed. Otherwise, return RAM offset of already copied file Load 32 bit word at offset 0x0, malloc that amount of space Pass compressed file and malloc location to decompression function Now for the good stuff: The compression format and the entire file format demystified. The file is stored with an 8 byte large header and as large of an actual file space as allowed (limited to highest 32 bit value in this case). While the file is being decompressed, the file is considered to actually start at byte 0x8. The file is divided into two parts: The table and the data. The table is technically only 0x400 bytes large starting at offset 0x400 (0x408 with the initial header), but it can extend larger if needed. The data goes as large as needed. The data and table itself use a Huffman compression method, with the table being the Huffman tree and the data being the binary array. The word value at 0x4 in the header determines the seed position in the huffman tree. The seed position is multiplied by 4 to get the actual offset of the seed. This offset does not include the header. Once the seed is loaded, each 32 bit word is loaded from the data and is divided by 2. If the far-most right bit was a 1 before division by 2, the next tree offset is shifted by 0x2. The next offset is determined as such: (((seed * 2) + flag) * 2). A 16 bit value is then loaded from that offset and used as the next seed. If this seed value is less than 0x100, it is interpreted as a byte and the byte is written and the seed reset to the bottom of the tree. This processes is done continually until all bytes have been written. If that was a bit difficult to grasp, you might be able to tell it a little better by viewing the source code of the decompression tool. With that said and done, the compression tool. It's written in Java and is executed from the command line using java -jar locodecomp.jar <infile> <outfile>. You can download the precompiled version here or view the source code on my GitHub here. The source code is fairly straightforward so if anyone wants to port it to any other languages feel free to do so. As a note, I included a small bitmap fixer which can patch in a header for certain bitmaps. How it works is it takes a blank bitmap header and stitches certain pieces of the raw bitmap together to form a readable bitmap. Since the bitmaps are a bit inconsistent in terms of defining width and height in the raw file, it calculates it using the .dat file associated with it. The width and height can be adjusted in a hex editor. Since it uses .dat files to get width and height, it usually only works with buildings due to the buildings being the only bitmaps that define it's size inside the .dat file. For sounds I'm not sure what header information is missing, but I do know that most of the sounds can be played in Audacity by importing it as a raw file and changing the format to use unsigned 8bit PCM and a frequency of 22050. Questions, comments, concerns? Feel free to let me know. I'm pretty excited for this myself since if we can convert all the bitmaps to a normal format we could potentially open up more expansive modding between the bitmaps and the .dat files.

Fun Facts: There are skid sounds for different surface types, but only one is used globally, gravel. There is a unused fanfare called CARUP which sounds similar to the fanfare when you get a car bonus. (Unused feature anyone?) In Time Trial mode, your vehicle speed increased by the equivalent of 0.5 of a power upgrade. Those random curb bricks you find in the water, lava, and other random places were not accidents, they were intentional! You can glitch underwater in water bordered worlds by riding the Corkscrew Professor Voltage was planned to be in this game, but instead got replaced by Sparky. The Lighthouse Keeper who is only found in the bonus game still has dialouge for outside the bonus game, it is just unused! The game devs didn't care if this game was for kids, they used vulgar language in the comments of scripts! Tips: You can get a race startup boost by holding down the acceleration key/button starting from the last red countdown light. Having trouble beating The Berg? Just after the checkpoint in the first small cave, head up the exit slope and take a left over the curb, you can cut the track and get a lead on The Berg! The AI racers won't fix their vehicle if it is 50% damaged or more. Use this to your advantage and hit them with a weapon that can do 50% damage right after the area of the repair pit, they won't turn back! The Stealth weapon doesn't just allow you to dodge blood hounds and see what weapons other racers hold, you can steal the weapons too by having contact! You can shoot a Bloodhound that is following you with the Slizer Disc. As soon as you hit it, the missile explodes, but the disc will stay intact, allowing you to hit another target. Shooting a car that is just coming out from repair pit will lose some of their bricks that have already been placed down, and the other bricks that are still coming in will be placed in mid-air. On-foot racers can steal weapons from cars, but cars can't steal weapons from them. Have anything else to contribute? Then by all means tell me!

Because I was bored and had the song stuck in my head? Yeah, that sounds about right.

This tutorial assumes you already know how to >access and use modded versions of the LEGO Racers game files and have downloaded WillKirkby's >LR1 Binary File Editor. As the title suggests, it is possible to use any of the game's existing tracks as the Test track. Here's how to do that. Note: All line numbers refer are based on a clean, unmodded file. Load the Binary File Editor and open MENUDATALEGORACE.RCB Scroll all the way to the bottom of the file or press Ctrl + F and search for the word "test" (with or without quotes, both will work). You should end up at line 426. The Test track's location and strings are located in this small structure. k_27 // Track "test" { k_2B // Name Index (/MENUDATA/<lang>/CIRCUIT.SRF) 16 k_29 // Folder (/GAMEDATA/<this>/) "test" } As can been seen from the comments the tool adds, the string "test" (line 447) below the k_29 keyword (line 446) controls from what folder the Test track files should be loaded from. If we were to take a quick peek at the GAMEDATA folder, we would find there is a folder that has the same name. To use any of the available tracks as the Test track, we simply need to change the string to be the same as any of the track folder names. If wanted to practice on Rocket Racer Run for example, the same code would now read as so: k_27 // Track "test" { k_2B // Name Index (/MENUDATA/<lang>/CIRCUIT.SRF) 16 k_29 // Folder (/GAMEDATA/<this>/) "racec3r0" } You can also enter "RACEC3R0" (matching the case of the folder). I have tested both and either work. It comes down to personal preference, but I lowercased the name for consistency with the rest of the file. Be sure the folder name is surrounded in a single pair of double quotation marks! Single quotation marks will crash the Binary Editor, multiple pairs will not work at all, and omitting them all together will halt LEGO Racers with an error message. Save the file and load the game. If your edit went well, you should now be able to practice on your favorite "Test" track! Demonstration video coming soon!

[5:47:21 PM] McJobless: Do you think there's a certain type of lamp you have to rub to make Kir(k)by or Addict appear? [5:48:48 PM] Alcom1: Kirkby's is a flourecent desk lamp with a USB cable. Addict's is actually a torch. [5:49:13 PM] McJobless: I may have just dump()'d.

Spot the mistake.