Leaderboard

Hey I see a lot of VirtualBox topics to run RR that is not necessary, i use a program called dg voodoo 2 is used to run old games. http://dege.freeweb.hu/dgVoodoo2.html download dgVoodoo v2.53 (released: 11.09.2016) and open the folder MS and take the 3 dll files and move them to your RR instal folder same place you put the d3drm.dll. and that is it, it worked for me and am running RR in 1080p now. If you want to use voodoo for extras options watch this video he does the same thing (this is not necessary) small note: I have never had a problem running RR on win 10, but the framerate was so bad (5 fps) and everything glitch in-game. but the 3 dll files fix everything for me Hope it help you guys NEW !!! POST FROM Chringelord with the missing pictures. I can absolutely confirm this. Works perfectly fine for me. Many thanks to Mikkel246 for this method. I'd suggest to sticky this thread since I think it is a true alternative to both Cafeteria and VirtualBox. Here's a written guide for people who prefer those over video guides: How to run Lego Rock Raiders under Windows 10 (and 8?) natively with the dgVoodoo wrapper (without Cafeteria or VirtualBox): Quick and dirty guide: Do a regular installation of Lego Rock Raiders Add d3drm.dll Download dgVoodoo 2.53 and extract dgVoodooSetup.exe and the DirectX .dll files (MS folder) into LRR's installation directory Should already run. Configure dgVoodoo DirectX wrapper through dgVoodooSetup.exe at will (If LRR was installed in C:\ you need to run it as Admin) Make sure to select LRR's installation directory as the place to save dgVoodoo's config Long and thorough guide: Get a copy of Lego Rock Raiders (physical disc or virtual disc image) Insert / mount the disc / image Install normally (If this doesn't work, refer to Cyrem's guide: Installer Not Working? You Can Salvage Your Game.) Download d3drm.dll. I could not find a working download on these forums, so I suggest using a download from the Machines - Wired for War community: http://download.wiredforwar.org/Game/d3drm.dll Got to the Lego Rock Raiders installation directory, usually C:\Program Files (x86)\LEGO Media\Games\Rock Raiders Copy the downloaded d3drm.dll to this Lego Rock Raiders folder Download the dgVoodoo 2.53 wrapper form http://dege.freeweb.hu/dgVoodoo2/dgVoodoo2.html Open the .zip file and extract the following files to the Lego Rock Raiders folder (C:\Program Files (x86)\LEGO Media\Games\Rock Raiders? dgVoodooSetup.exe From the MS subfolder: D3D8.dll D3DImm.dll DDraw.dll In the Lego Rock Raiders folder, right-click on dgVoodooSetup.exe and select Run as administrator (Running as Administrator is not necessary if the game was not installed on C:\) Perform all steps as shown below: Just copy the settings, and it should work - Just make sure the path leads to the RR folder where the game is. (marked with important) https://drive.google.com/file/d/1c-mi53PZC80V9qoXjK2847FOSy3hao7R/view?usp=sharing (voodoo - general) https://drive.google.com/open?id=1BK3XIR1UjDqX-CbQRuhqgwbfJ68EBO01 (voodoo - glide) https://drive.google.com/open?id=18QEyMIY9Runf7wOmFCwBjLDxsEniVJkR (voodoo - directX) The resolution should match your monitor's. VRAM and Antialiasing settings work fine on a GTX 970. Adjust if problems occur. Run Lego Rock Raiders A Mode Selection window should appear. Default settings should be fine. The seleced Device should be: Direct3D HAL (dgVooddoo Hardware Accelerated Device) Click Ok Lego Rock Raiders should now run in 1920x1080 fullscreen and high FPS. Textures and UI elements will look pixelated and stretched. This is normal because the game was made for lower 4:3 resolutions. No music will play in-game. There is no known fix for that. If you want the music, rip it off your disc and play it in the background with a music player. It took me many hours to figure out a way to properly run Lego Rock Raiders on Windows 10, so I made this guide to hopefully save some people a lot of time.

FlicTool Latest version: 1.1 (Updated 2014-09-27) FlicTool is an application used to compile and decompile Rock Raiders Flic Animation files (commonly known as FLH files), allowing you to edit existing animations or create new ones. This can be used to create your own animated menus, edit animated cursors, etc. Usage FlicTool is a command line program, which means you have to open a command prompt and run it from there. The application accepts two arguments, input and output. Example: FlicTool input_file.flh output_directory This would decompile the FLH file input_file.flh and place the individual frames in output_directory. The application will automatically detect that input_file.flh is a Flic Animation file, and will then try to decompile it. Inversely, it is also possible to write FlicTool input_directory output_file.flh which would take all the frames found in input_directory and combine them to create output_file.flh. (Frames are recognized by looking for BMP files with names matching frame####.bmp where #### is the zero-padded frame number, starting with 0001) If you leave out the output file/directory name, it will be assumed to be output.flh when compiling, and output when decompiling. Notes It should be noted that FlicTool is still in a very early stage of development. There may be lots of bugs yet to be discovered, and many features are still missing. This also means that I have yet to test FlicTool extensively. Remember to make backups of your FLH files before you start tinkering with it. Plans The current compression algorithm creates slightly smaller or slightly larger files when recompiling existing Rock Raiders FLH files, depending on the color data. This doesn't affect the loading of the files in Rock Raiders, but it is still something I wish to address properly when I find the time. Download Windows: Github - https://github.com/Merigrim/FlicTool/release RRU - https://www.rockraidersunited.com/files/dl-r11/ Linux, OS X: I might provide binaries later, but for now it's easier to build the tool directly from source. Source: GitHub - https://github.com/Merigrim/FlicTool (current source) RRU - https://www.rockraidersunited.com/files/dl-r13/ (v1.1 source) FLH format notes: Still need to write this, but I recon it could be of interest as well so I'll start working on it once the source is uploaded. Changelog -------------------- Hey everyone, first time posting here! I joined a while back, but was never an active member of the forum. Hopefully some of you will find this tool useful. Also, this post was written very late (almost 2am here) so I apologize if any parts are hard to understand. I will be back to edit this when I get home tomorrow.

Ok, so. Pushed an update that fixes hard edges appearing whenever vertices are split in any way other than by normals/shading - well, almost. Turns out that seams in UVs from a UV file will *always* cause hard edges in the shading. Why? Despite how the LWO and UV formats store things, at the end of the day, a vertex can only have one of each attribute - one position, one normal, one UV coordinate, etc. (Well there are such things as multiple UV sets but that's not relevant to how this works or the problem at hand pls don't nitpick I mean they're just yet another set of attributes anyway right so like it doesn't matter that they're UVs at all blarghghgh.) So when you have to have a seam in your UVs, or a hard edge on a corner, you'll actually ultimately end up with split/duplicate vertices - identical in every way, sitting in the same place, except they might have different UV coordinates for a seam in the texture, or different normals to form a hard edge. Here's a really nice visual explanation I always point to. Though in this case, the problem has more to do when this occurs with UV splits. So what's the problem exactly? Well, the LWO format doesn't store vertex normals - the game calculates them upon loading. If vertices are split, that'll result in a visible hard edge. That's a-ok. Except, when you add UV coordinates to the mix, suddenly you have to split some of your vertices for those texture seams. This is pretty much functionally identical to unwelding them to control the smoothing of your model. If you do this step *after* you've already calculated your UV coordinates, you're fine. Your new split/duplicated vertices will still have normals that line up with each other, and so there won't be any visible seam. This is what the game does for planar textures - after all, planar textures are just info on how to calculate UV coordinates. But when the game instead loads UV coordinates from a UV file, it splits vertices to accommodate them *before* calculating the normals. And so, there end up being a lot of split vertices - and thus hard edges - you didn't intend there to be, wherever there's seams in the UV map. That's what seems to be happening anyway. There could be more weird factors to it. God knows what the game's really doing. Have fun with that :DDD

There are a couple facts I believe I've established in my own research; From the User Interface in-game, we can determine that there is the ability to dynamically assign priorities; that is, what your Raiders should be focusing on before anything else. Different Raider units can do different tasks, and in normal conditions, when unclicked or not following a direct order, Raiders will immediately do a series of different actions until there's nothing left to do. Certain priority tasks cannot be auto-assigned to a Raider. Raiders will not automatically drill or reinforce walls unless instructed to. Speaking in a Discord chat (which actually prompted this topic), Cyrem poked at the idea that the array of todos is not dynamic, but has a max size. Cirevam discussed the nature of how todos are actually generated, probably by scanning active items that can be interacted with in the world from the origin (the top-left corner). I pondered the connection of the priorities setting. I suspect that from the collective of all Raiders on the level (whom I will refer to as the "Hive") every individual Raider (whom I will refer to as a "Peer") pull their orders (called "Tasks") from an array of all tasks to complete at any stage of the level. Tasks are created, stored in the array and then assigned to individual units when they require a new one. Giving a direct order to a Raider likely cancels their current task (or moves the current task back into the array) and feeds them the personalised order. I suspect that Idleness Syndrome sets in regarding the way every peer gets a new task and how the array of tasks is maintained. I have two predominate theories on how this could play out: One possibility is that new tasks are generated during play. An example, if you drill a wall, ore and sometimes crystals spawn. When these items are spawned, tasks are automatically generated and saved to the master array for handling these objects, such as bringing a crystal back to the Tool Store. This system might have a major oversight, where when a player gives a direct order, it is not checking to see if there already exists a task for that object in the master array. This creates a duplicate task which the Raider completes, and with enough of these, the master-array is filled with duplicate, incompletable tasks as the required object no longer exists. This system might have an oversight where the array, given that it has a max size, may simply have too many elements inside it, and so new tasks get lost and forgotten as older tasks (which might be blocked by paths that can't be crossed, for example) haven't been cleared out to make space yet. I shudder to think, but it might be a possibility that the system never actually cleans up the array or attempts to shuffle elements down or put new elements at the beginning, and once you've reached the maximum automatic tasks, gives up. The second possibility is that tasks are not generated dynamically, but at specific "intervals", at which point the game scans the level to determine what needs doing, and organises the master-array with all the tasks ordered by the current priority set (that, or there's a controller responsible for scanning through the master-array to determine the best task for an individual peer requesting something new to do). The system might encounter a scenario where it fails to refresh. If the system is setup to refresh based on a timer, when a unit requests a new order, when the master-array is empty or so forth, it might be possible that the system tries to determine if a task is actually accessible or not, or other factors. It's possible those factors are too strict, or the refresh functionality is designed to fail silently if it encounters something it didn't expect, leaving the array destined to never be fixed. If the system is setup to refresh based on a condition becoming true (as opposed to a regular interval timer), then if that condition never becomes true, no new tasks will be generated. For example, if a bunch of incompletable tasks are in the master-array and the system will only refresh when the master-array is empty. If the developers used some kind of "time-out" system to stop refreshing the master-array if it's taking too long, then maybe it's just that the time-out is too fast. The tl;dr of that whole chunk is that I think it's very likely an oversight on the behalf of the developers, possibly even a known bug they didn't have time to address.