Modding An Unreleased Game

[lol username]

For those who don't know, LEGO had a Bionicle game planned in 2001, but it was canceled before release. However, somebody with an Alpha disc is putting footage online, and we hope to eventually get the ISO from him. But there is a problem - due to a glitch, it is impossible to get past one of the platforming segments. A platform is positioned over a bottomless pit, but the game detects your fall too soon and you die as soon as you touch the platform. In hopes of modifying the game's save files to get past this segment, the person who has the disc (Deep Brick) has sent some sample save files. If you need more information on the game and now it works, read through the topic's last ten pages or so.

Skip to 7:08 for the glitch.

If you can please join BZPower and take a look, it would be appreciated. If you can't join, then post here and I will quote your posts on BZPower.

[Sonic322]

That is one bad glitch.

If only LEGO finished the game because that looked pretty fun.

[TheDoctor]

That is one bad glitch.

If only LEGO finished the game because that looked pretty fun.

Thank you Admiral Q. Useless for that riveting summary.

I'll look at the files, but I don't think we can do much about them without someone like Cyrem who knows what he's doing with file stuff.

SCRATCH THAT. I'M COMPLETELY USELESS.

[JrMasterModelBuilder]

Well, I'll go first.

I've been looking over the files and some of the things in the save files looks fairly simple.

Not sure what to do with that BIK file. 7-zip failed to open it, and game extractor doesn't seem to want to work on my computer (I'll have to trouble shoot sometime), so if someone else wants to give game extractor a try, that'd be good.

On the save files, I'm almost positive the UDD symbols are represented by strings of 8 characters.

FILE 1:

..tnrf0rts0kolauno.....<<.11tehceb.....................ú.

06 00 74 6E 72 66 30 72 74 73 30 6B 6F 6C 61 75 6E 6F 00 00 00 00 00 3C 3C 01 31 31 74 65 68 63 65 62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FA 00

FILE 2:

..tnrf0rts0kolauno.....<<.11tehceb31tehceb21tehceb41tehceb01tehceb61tehceb71tehceb51tehceb.....................ú.

06 00 74 6E 72 66 30 72 74 73 30 6B 6F 6C 61 75 6E 6F 00 00 00 00 00 3C 3C 08 31 31 74 65 68 63 65 62 33 31 74 65 68 63 65 62 32 31 74 65 68 63 65 62 34 31 74 65 68 63 65 62 30 31 74 65 68 63 65 62 36 31 74 65 68 63 65 62 37 31 74 65 68 63 65 62 35 31 74 65 68 63 65 62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FA 00

Look at these two files that are only different by the second one having 8 instead of 1 UDD symbols. The first 2 characters seems to be a number the denote which numbered UDD was collected. The last 6 chars seem to denote which area of the game they are from. For example, the 8 in the first game area are called tehceb, but in other scenes, they have different names.

I also see "auno" in the front of the file. IDK for sure if that has any relation the the character "onua" the person is playing as.

-Takua- seems to have realized the UDD thing as well, but supposedly his file didn't work.

P.S. Feel free to quote me in the BZP topic. I probably won't get around to it for a while, and this info might help them.

[Dovahn]

Well, I'll go first.

I've been looking over the files and some of the things in the save files looks fairly simple.

Not sure what to do with that BIK file. 7-zip failed to open it, and game extractor doesn't seem to want to work on my computer (I'll have to trouble shoot sometime), so if someone else wants to give game extractor a try, that'd be good.

On the save files, I'm almost positive the UDD symbols are represented by strings of 8 characters.

FILE 1:

..tnrf0rts0kolauno.....<<.11tehceb.....................ú.

06 00 74 6E 72 66 30 72 74 73 30 6B 6F 6C 61 75 6E 6F 00 00 00 00 00 3C 3C 01 31 31 74 65 68 63 65 62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FA 00

FILE 2:

..tnrf0rts0kolauno.....<<.11tehceb31tehceb21tehceb41tehceb01tehceb61tehceb71tehceb51tehceb.....................ú.

06 00 74 6E 72 66 30 72 74 73 30 6B 6F 6C 61 75 6E 6F 00 00 00 00 00 3C 3C 08 31 31 74 65 68 63 65 62 33 31 74 65 68 63 65 62 32 31 74 65 68 63 65 62 34 31 74 65 68 63 65 62 30 31 74 65 68 63 65 62 36 31 74 65 68 63 65 62 37 31 74 65 68 63 65 62 35 31 74 65 68 63 65 62 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FA 00

Look at these two files that are only different by the second one having 8 instead of 1 UDD symbols. The first 2 characters seems to be a number the denote which numbered UDD was collected. The last 6 chars seem to denote which area of the game they are from. For example, the 8 in the first game area are called tehceb, but in other scenes, they have different names.

I also see "auno" in the front of the file. IDK for sure if that has any relation the the character "onua" the person is playing as.

-Takua- seems to have realized the UDD thing as well, but supposedly his file didn't work.

P.S. Feel free to quote me in the BZP topic. I probably won't get around to it for a while, and this info might help them.

Yeah, that's what I was looking at (I'm -Takua- on BZP). I realize now, though, that the UDD symbol that I duplicated was the next one in the order found in the second save file (i.e. the one starting with "31"), but it may be that the symbols are added to the save file in numerical order (that the file with 2 symbols should have "11" and "21"). The only strange thing is the "01" which would seem to be the logical first symbol, but which doesn't appear in the first save file.

OH! I just realized that you've hit on something important! Check out all of the other save files, but read each initial string of characters backwards! The "onua" must indicate that we're in the onua level, but the rest of the characters also have meaning backwards: "str0frnt" in the first files, but then (more intelligibly) "str0cave" in one of the later save files. I'd guess that "str0" is defining a string variable storing your location, and the value is "cave" or "frnt" (probably short for "front"); locations in the level! Another save file (at the suva) is labeled "shrn" which probably stands for "shrine".

So possibly every larger zone in a level has a 4-character label that we'd have to figure out before we got there (bummer). However, I suspect that other Toas' levels have Suvas as well, so maybe the other levels also have a "shrn" as a zone.

In other words, as soon as DB is back, we should try a version of the save file where we keep the "nrhs0rts" part of the file (indicating it's at a suva) but changing the Toa's name (keeping it backwards of course), and see what we get.

And for further analysis of the save file, we should look at everything backwards. (emboldened for importance)

[lol username]

Perhaps the 4-character label is not the location, but the .blk file that stores the data for said location/object? "auno" might refer to onua.blk, and if there's, say, a frnt.blk file, it may be referring to that somehow. Keep in mind I know little to nothing about this sort of stuff - it's just a random idea. Feel free to shoot it down.

[Dovahn]

Further analysis using this backwards thinking has yielded some good stuff:

Each (what we think represents a) UDD symbol has six characters apart from the two numbers; the six characters backward always end with "et", but the first four also seem to be an area registration code. This way, I can find more area names than just the three different save file locations that we have. I found "bech" (beach), "cave", "atrm" (atrium), "pzzl", (puzzle), "clf1" (cliff 1), "shrn" (shrine)... I could go on, but I suspect that these are the same 4-character strings that represent the respawn location at the beginning of the file. We could try changing the location at the start of the file to something else and see if the player spawns in one of these other places (theoretically in the same location as where the UDD symbols were found corresponding to those codes).

Of course, we can't test any of this until DB gets his computer back, and my original modified save file didn't work, but maybe one of these will.

As I mentioned before, this means that until we know what a place's string is, we can't get there (they aren't represented as numbers that we could just increment). But hopefully some of the zone names are similar from level to level, so we could at least skip ahead to, for example, Gali's shrine zone using the code "shrn" and changing the "auno" to "ilag".

EDIT: jamesster, I think you'll see from above that the 4-char code is probably a location. Yours is a good thought (and it's possible that the .blk files have the same names as the locations). It seems pretty convincing though that the UDD symbols are labeled with the same locations, but they don't need to load data files for themselves; they just act as registration points.

Actually, now that you mention it, we could see if RQ can tell us some of the other .blk names. If they do line up with the locations (and that's a big if) then we can determine other location names without needing to guess or hope that they're the same.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

A few more strings at the end (possibly flags that indicate a completed puzzle or a collected mask or something), still split into 4 character segments. These taken from Steps.sav, and are similar to Suva.sav. They all had some non-readable characters in between them.

"spcv mskc pzzl mskv

cave disc atrm bbug l1a1 pic1 l1a1 claw

v101 vllg v102 vllg when shrn vlgr atrm v103 vllg whentura"

"mskc" and "mskv" I'd guess are flags for masks (concealment and vision). "pzzl" a puzzle completed? "bbug" - maybe a boss defeated? Was there a bug boss? Oh, silly me; it was a quest. "whentura" - possibly only one string, "Whenua Turaga", or maybe still split in two like the others.

I'm not sure what all of the "v" prefixed strings mean. Any ideas? Maybe there database structural elements or something, for whatever this file's original format is. Like a new column or row? I don't know. I figured it out now: perhaps some of these strings are actually 8 characters long, and v101vllg indicates that you've spoken to villager 101 in the village. "whenshrn" is after you've spoken to whenua at the shrine. So they store what conversations you've had. I still think the first few are 4 character strings.

Someone who is more familiar with the layout of the level and the videos could probably figure out what each flag indicates, if they are indeed flags. If we could figure out the flag for, say, giving you the makoki stone that you're missing or permitting you to go through one of the doors in the Suva room. Of course, changing the spawn location might work just as well, if we moved it along just a little bit.

Also, I suspect the number at the very end of the file ("FA" in hex in the file 245_1) is the number of fruits (RQ said that there were 250 fruits in that save file, and FA in decimal is 250). That would be easy to test.

I'd say I have about 80% of the save file figured out. When I have a chance I'll write up a description of where and what everything is.

[JrMasterModelBuilder]

O_O

Whoa! You've done a lot of work! Everything you said seems to make sense.

As for how to find the names of locations, a directory listing might help, or, maybe we could have Deep Brick open the files (probably the main executable) in a hex edit and search for the names we already know. They might be in a semi-visible list or something. Kind-of like how people most likelt discovered the undocumented Flash function fscommand save clearly visible in Flash 5 projectors along with all the other fscommands

trapAllKeys.showmenu....exec....=...&...save....allowscale..fullscreen..quit....FSCommand:

P.S. I knew you were smart.

[CTXXTC]

Some person claimed he could fix it, i saw it on a ShieldOfAges vid.

[Tracker]

I case you haven't figured it out yet, what you need to do in a nutshell is somehow lower the "trigger death" plane. And I have discovered that most people don't their messages. <looks at someone watching the topic>

[Dovahn]

Whoa! You've done a lot of work! Everything you said seems to make sense.

As for how to find the names of locations, a directory listing might help, or, maybe we could have Deep Brick open the files (probably the main executable) in a hex edit and search for the names we already know. They might be in a semi-visible list or something. Kind-of like how people most likelt discovered the undocumented Flash function fscommand save clearly visible in Flash 5 projectors along with all the other fscommands

trapAllKeys.showmenu....exec....=...&...save....allowscale..fullscreen..quit....FSCommand:

P.S. I knew you were smart.

Thank you!

As a matter of fact, though BZPower seems to be down, yesterday I posted asking RQ and DB whether they could check the folder structure for "atrm.blk" or any data files for the other locations, in case it's that simple. Your suggestion for checking the executable is a really good idea too, though I'm not sure how invasive DB will be willing to get with the main executable (of course you and I know it won't do any damage in the right hands, but maybe if he's not comfortable with a hex editor...) Maybe if the data files are distributed by koro (like a .blk for onu koro), opening those data files will give us a list of .x models that are properly named after the zone names. Like we see at the beginning of onua.blk. That's another possible location for the info.

I was thinking, too, though, that there are multiple spawn points in each zone (there are, right? I didn't watch the videos closely enough). So something in the save file must distinguish one spawn point from another, different from the actual model of the zone that you are in. Since I didn't find any other telling strings, it could be that the spawn point location is a simple number that we can increment (I can hope, can't I?) to get to the next spawn point after the platforms of doom. Of course, the respawn points might not be save points (as in, when you shut down the game you go back to the beginning of the zone no matter how far you made it), in which case it wouldn't really help us, but it might be worth a check.

Another shot in the dark: the name of the last zone (in which the stairs of doom are located) is "hk01". I don't know what "hk" stands for, but maybe immediately following the zone is an "hk02". It's worth a shot, I think, if we have no luck with other things. We want to make sure that wherever we skip the player to isn't very far ahead, or we might miss something important (like the elemental battle).

I case you haven't figured it out yet, what you need to do in a nutshell is somehow lower the "trigger death" plane.

That would be the ideal and least disruptive solution, but I think until we're able to reverse engineer the "blk" files and modify their contents (the "trigger death" plane data could easily be a proprietary data file, rather than a simple 3D model) changing the save file might be the easiest way to do it for now. In my opinion, if DB still had his computer we'd already have a new, usable save file that would take you beyond the stairs, maybe even to a different Toa's level.

[PWNZOR]

Is it really 'trigger death plane'? Or is a 'falling for too long trigger'?

[Dovahn]

Is it really 'trigger death plane'? Or is a 'falling for too long trigger'?

Well, I think we ruled out the falling too long death, because it's possible to jump down farther in other places. Relative to some jumps, it's pretty small, especially when he takes the jump from the next highest platform. I think it comes down to a question of whether there's an invisible death plane or whether the platform itself for some reason has the "die when hit" flag on it.

That's just what I've determined from the videos, though. I can't really be sure.

[JrMasterModelBuilder]

Whoa! You've done a lot of work! Everything you said seems to make sense.

As for how to find the names of locations, a directory listing might help, or, maybe we could have Deep Brick open the files (probably the main executable) in a hex edit and search for the names we already know. They might be in a semi-visible list or something. Kind-of like how people most likelt discovered the undocumented Flash function fscommand save clearly visible in Flash 5 projectors along with all the other fscommands

trapAllKeys.showmenu....exec....=...&...save....allowscale..fullscreen..quit....FSCommand:

P.S. I knew you were smart.

Thank you!

As a matter of fact, though BZPower seems to be down, yesterday I posted asking RQ and DB whether they could check the folder structure for "atrm.blk" or any data files for the other locations, in case it's that simple. Your suggestion for checking the executable is a really good idea too, though I'm not sure how invasive DB will be willing to get with the main executable (of course you and I know it won't do any damage in the right hands, but maybe if he's not comfortable with a hex editor...) Maybe if the data files are distributed by koro (like a .blk for onu koro), opening those data files will give us a list of .x models that are properly named after the zone names. Like we see at the beginning of onua.blk. That's another possible location for the info.

I was thinking, too, though, that there are multiple spawn points in each zone (there are, right? I didn't watch the videos closely enough). So something in the save file must distinguish one spawn point from another, different from the actual model of the zone that you are in. Since I didn't find any other telling strings, it could be that the spawn point location is a simple number that we can increment (I can hope, can't I?) to get to the next spawn point after the platforms of doom. Of course, the respawn points might not be save points (as in, when you shut down the game you go back to the beginning of the zone no matter how far you made it), in which case it wouldn't really help us, but it might be worth a check.

Another shot in the dark: the name of the last zone (in which the stairs of doom are located) is "hk01". I don't know what "hk" stands for, but maybe immediately following the zone is an "hk02". It's worth a shot, I think, if we have no luck with other things. We want to make sure that wherever we skip the player to isn't very far ahead, or we might miss something important (like the elemental battle).

I case you haven't figured it out yet, what you need to do in a nutshell is somehow lower the "trigger death" plane.

That would be the ideal and least disruptive solution, but I think until we're able to reverse engineer the "blk" files and modify their contents (the "trigger death" plane data could easily be a proprietary data file, rather than a simple 3D model) changing the save file might be the easiest way to do it for now. In my opinion, if DB still had his computer we'd already have a new, usable save file that would take you beyond the stairs, maybe even to a different Toa's level.

We could have him open only a copy of the file in read-only mode. You would be hard pressed to mess up anything then and a lot of hex editors have a read-only feature.

I'm not sure about the spawn points thing. I haven't had time to watch all the videos closely.

If there's one thing I've learned, in games, if there's a 1, then there's probably a 2.

[aLPHA]

What about using a memory hacking program and giving the player infinite health? Get past that glitch point, and once you get past it, turn infinite health off.

[Sonic322]

What about using a memory hacking program and giving the player infinite health? Get past that glitch point, and once you get past it, turn infinite health off.

The glitch kills you on the spot so that wouldn't work.

[Cirevam]

It could work. Infinite health, more often than not, will bypass killzones because most are programmed to drop the player's health to zero. Now, if it's something like an out-of-bounds zone and it forces a scripted death, which is different, then we can't bypass it with a simple infinite health code.

[Sonic322]

If that works then could we make the game only allow infinite health in that level?

And What would happen if you fall of a ledge with infinate health?

Would you die or just stand there or fall forever or some other thing?

[DrDeath]

noclip would be useful

[aLPHA]

Do please try to get the iso from him. Maybe he could upload it as a torrent so that it would be easier for us to download.

[JrMasterModelBuilder]

Also, I suspect the number at the very end of the file ("FA" in hex in the file 245_1) is the number of fruits (RQ said that there were 250 fruits in that save file, and FA in decimal is 250). That would be easy to test.

One other question. How do you figure that out? Seem like it would be useful to know.

Do please try to get the iso from him. Maybe he could upload it as a torrent so that it would be easier for us to download.

He/they have said many times that they won't without permission from LEGO & Saffire Inc. :(

[Dovahn]

Also, I suspect the number at the very end of the file ("FA" in hex in the file 245_1) is the number of fruits (RQ said that there were 250 fruits in that save file, and FA in decimal is 250). That would be easy to test.

One other question. How do you figure that out? Seem like it would be useful to know.

I knew that there must be some number somewhere in the save file that keeps track of the number of fruits, so I just looked for the number 250 in the first save file and made sure that number never went above 250 in other save files (because you can't get above 250 fruits). That was the only spot that fit those requirements.

[JrMasterModelBuilder]

I mean, how did you figure out FA in decimal is 250?

[Cyrem]

I mean, how did you figure out FA in decimal is 250?

It's HEX and easy to figure out. You can use Calculator to convert HEX to decimal if you wish.

[CTXXTC]

May I join YouTube and blackmail him into uploading a torrent? xD