Leaderboard

Had a ton of money left over from after Christmas, so I got myself 10243 Parisian Restaurant (I may or may not have an addiction to modulars ) and 70312 Lance's Mecha Horse. I'm actually rather surprised at how nicely the horse transforms between the two modes (horse and bike), so I'm kinda tempted to get more of the sets when I get more cash.

Hey everybody! I want to wish you all a happy new year! May this year be good for you! As of december 2015, it was my 7th year of being a user on RRU. Can't believe the time has gone by that fast! I remember coming here to find out how someone changed the ice biome pink on the image I saw on google Pff, this year I want to get a lot done for Return To Planet U. It won't get finished, but hopefully it will get to a state that is presentable. It would be about damn time too, this project has been in progress since 2009 haha. In some time, I will make the first official teaser for Return To Planet U as soon as I can make some gameplay videos and the anthem song is done. Have a nice day, Rockraider cadet Pascal.

That's awesome! Is this the board game that was sold in stores, or the one that came with the magazines we've been discussing? We've got a couple of different dates and locations for Exploriens, though as a galaxy-spanning exploration team it shouldn't be surprising that they show up in different times and places. The earliest known date is 3147, from this catalog, Pereki already sourced the year 3200, and while the Time Cruiser audio dramas didn't provide an exact year, it did state that Dr. Cyber was in their history books for inventing time travel--a new invention in the Time Cruiser's home year of 3777. Could be John King. Thank you so much for tracking these down and making them available to everyone! It's great to see this proto-theme story transform into the Time Cruiser's we've always known--I never expected that to happen! I think my favorite piece of Time Cruisers art is the Flying Time Vessel's arrival at Jupiter--cool stuff. TC

Hi! Newbie here, but I got bored and made a thing: I used to love this game as a kid, and recently I found the disk buried under a pile of, well, other disks. (I used to love RR and LI1+2 too, but not as much as this - I can't even remember if RR/LI1+2 had a theme, but I can hum LR's theme and the building room song without even thinking!) So now that I have more free time the idea popped into my head to reverse-engineer the game, because why not! Currently it can read the JAM file and create the main menu (well all apart from the man in the corner: just need to look at animations then once that's done it seems like a simple 3x3 matrix maps it into screen space) with sound playing (albeit in a very quiet and crackly way because I messed up the ADPCM converter and cba to redo it yet), but nothing is interactive yet. I wish I'd seen http://www.rockraidersunited.com/topic/6624-lego-racers-in-unity/ before I'd started working on this, but ah well. Almost all of this is from reverse-engineering/guesses (no copy-pasta of libLR1 or anything else, except possibly the BMP format) and I prefer to work out and implement stuff myself rather than rely on other peoples implementations, so everything you can see I've written in C or C++ (it originally started in C as a JAM dumper but then expanded into a full C++ project with a single C file that doesn't want to change into C++ (Logging.c)). It relies on LEGO.JAM being in the same folder (although it also searches the parent folder as it makes the build folder setup easier) and the .tun files being in the same folder if you want audio. If it finds the folders "MENUDATA" and "GAMEDATA" next to it then it'll read from them and ignore the JAM file since that's what posts on here seem to suggest happens (note that I haven't been running the actual LR at all - only looking at the data and guessing what each bit does - and hence never needed to modify a file, but I guess having those folders would make that easier). Currently the only command line args from the original game it accepts are "-horzres" and "-vertres" (no support for "-fov" yet, although can't wait to add that!), and additional ones are "-runtests" that runs unit tests (currently all #if 0'd out in the code, except for the image dumping) and "-headless" which was used when I used to dev on my really really old machine (had lower specs than a raspberry pi) but should probably be removed now. It requires OpenGL 3.1 because that's the highest version my machine with an Intel GPU using the Mesa drivers can go, although it doesn't actually need that high a version and I should probably lower it, but chances are most machines nowadays can run it. Maybe if I lower it back down we can get LR running on a raspberry pi or phone... maybe one day. Binaries are attached (debug and release in both Windows and Linux formats - the Linux one was built on Ubuntu 14.04 LTS, but the code requires no dependencies other than SDL2 (I think)) so have a go at running it if you feel like it, although all it does is draw what the picture shows. I think I have the 2001 re-release of the game, and from brief looks at libLR1's code when I got stuck reverse-engineering the file structures it doesn't seem to match my data exactly (unless libLR1 has never been tested against the 2001 data?). Also note that since most of this has been developed on Linux there might be subtle bugs in the Windows version - I gave it a test run and it all seems OK, and seeing as it doesn't do anything yet I don't see how it could go wrong Anyway, thought you lot might want to know about this, and don't expect regular updates at all on this or even from me (I busy). Although if you want a statement of progression: on Friday morning it wasn't drawing anything, on Saturday morning it was drawing the images (so background and the logo in the top left), and last night I added the ability to print text on the screen, albeit in a bit of a hacky way (only 1 of the fonts works "OK" since they do something weird with glyph locations - just look at the location of the "Q" in "QUIT"). Oh and the reason the labels don't match what's in the game is I haven't found the mapping between what the internal names are (ie those shown atm) and where the translations are stored in the string files, but once I've found that out then it should be fine contents.zip

Thanks Cirevam. That's great. I've compared it with the colors I had manually looked up before and 60 files say you are right.

Unfortunately, I haven't been able to figure out how LRR determines which colours are supposed to be transparent. The closest thing I've been able to do is create transparent particle effects which works by treating pure black (000,000,000) as fully transparent, pure white (255,255,255) as fully opaque, and everything else inbetween partially transparent. Then, in the Surface Editor in Lightwave Modeler, you have to go to the Advanced tab and set Additive Transparency to 100%. That won't work for what you're trying to do. There's probably a variable in the LWO files that tells the game which color should be transparent. I'm going to guess it just looks at the index number in the texture. I can help you test this if you want. Too bad you're getting my help anyways. I'm choosing the Slimy Slug's eye for this example. Please open your textbooks to Data/Creatures/Slug/A014_SlugEye.BMP I know the transparent colour for the slug's eye is 14 from previous research. Let's mess with it a bit and see if the game looks at the index or at just the color. Here I moved index 14 to 240 just to get it out of the way. 14 is now some shade of orange. Now I moved 0 (which is white) to 14 and changed the green background to white to see if I could force that to be transparent. It worked! Great. Let's look at the model, which is Slug_Eye.lwo in the same folder. We'll open it with a hex editor (I use XVI32) and look for instances of 14. Oddly enough, the only instance I found was in the filename: A014_SlugEye.BMP This is really interesting. There are other textures that start with A###, but most of them start with A000. I think that this specifies the alpha index. To test, I looked at a few other textures, like A068_LightX and A227_headtop2, and guess what? The index in the file name always matches the index of the background colour. I can further test this by making some new models and textures and seeing if this hypothesis holds up, but that will have to be later.