Leaderboard

The big ship from Time Raiders has been reborn in the flesh. For those of you who don't know or need a refresher: the Time Raiders mod starts off not long after the events of Rock Raiders. The LMS Explorer sends out a distress signal as it falls into the wormhole. The LDS Geloden, being docked relatively nearby, is able to quickly load some construction equipment and respond (it's a warship, so it doesn't usually carry things like drills). It arrives at the location where the signal was sent but finds nothing. After searching for a while, its captain orders a jump-scan-jump search pattern while waiting for other ships to respond. The Geloden's FTL travel method is a wormhole generator, but the space where the Explorer disappeared is still heavily distorted by the first wormhole. When the generator spools up, space is torn apart in ways that aren't generally recommended, and the ship falls out of the universe. It is 55 studs long but I'm not exactly sure what scale this is. I'm using part 90398 as the minifigs inside (https://www.bricklink.com/v2/catalog/catalogitem.page?P=90398#T=C), so I think this is around 1:3.5. If true, that would put the 1:1 model at around 190 studs long. Compare to the Explorer's roughly 960 studs, if we go by Arthuriel's LMS Explorer 1:1 build. It has two ship-to-ship guns, five point defense turrets, a teleporter array that's much less capable than the Explorer's, and a shuttle bay. The rest of the pics are in this spoiler.

TTGames developers decided that they did not like modding and implemented a function in their game code which checks if the game is running in an unpacked state and if it is, then a FatalExit function is triggered (game crash). The developer m0xf first figured out how to patch around this check. This byte change is significant because EB is hexadecimal for JMP opcode (unconditional jump), while 74 is hexadecimal for JE opcode (jump if equal). So, it can be determined that at some point in the game code, it will jump if something is equal to something else and allow the game to run, but if the game is unpacked and no DAT archives are present, it will not jump and the FatalExit will be triggered. Now, by switching this to an unconditional jump, the game will always jump at this specific point and will always run. What exactly the game is checking for here is unknown, which is why that above paragraph is ever so slightly vague. The developers used the same function in all of the games that require an EXE patch, as can be seen by the below screenshot: Because of this, we can construct a pattern. ALL of the TTGames that have this DAT check will have the same pattern at some point in the EXE file visible in HxD: 74 ?? B9 ?? ?? ?? ?? E8 ?? ?? ?? ?? CC The "??" bytes are different across each executable, but the B9, E8 and CC bytes are always in the same position after the 74. This makes it rather easy to determine whereabouts your game executable needs patching! However, an even better solution has emerged thanks to acidicoala - Koalyptus framework. Composed of two binaries, Koalyptus is a framework that can be used to dynamically patch executables in memory. Such runtime patches have the advantage of keeping executables unmodified. The first binary is Koaloader, which hooks into the game process, and Lyptus binary is responsible for patching the executable at runtime. Project pages: https://github.com/acidicoala/Koaloader https://github.com/acidicoala/Lyptus All of the games load xinput9_1_0.dll, so we'll use this build of Koaloader as our proxy library. This means that all functions that the game would need from the actual xinput9_1_0.dll will still work since Koaloader can pass them to the actual DLL inside System32. Next, we need to configure Koaloader to load Lyptus64.dll, so we paste this config into Koaloader.json: { "logging": false, "modules": [ { "path": "Lyptus64.dll" } ] } Next, we configure Lyptus64.dll library with the following patch information: { "logging": false, "patches": [ { "name": "TTMagic", "pattern": "74 ?? B9 ?? ?? ?? ?? E8 ?? ?? ?? ?? CC", "offset": 0, "replacement": "EB" } ] } This instructs Lyptus to find that specific pattern and swap the 74 byte for an EB, which will allow our game to run. Now, you should have four files: xinput9_1_0.dll Koaloader.json Lyptus64.dll Lyptus.json And these four files go into your unpacked LEGO game folder. Run the DX11 executable and be amazed that the game now loads just fine!

This is a very detailed and important first post! Welcome to RRU, and I hope you stick around and give us more gems like this.