Jump to content

Tutorial: No JAM Archives


Cyrem
 Share

Recommended Posts

Note: This is only known to work with the original 1999 release of LEGO Racers, not the 2001.

Running without the JAM Archive allows you to easily change files without having to re-build the JAM archive, it also allows you to change files while the game is running.

To do this:

1. First extract the JAM archive.

2. Make sure the folders: 'GAMEDATA' & 'MENUDATA' are in the same directory as 'LEGORacers.exe'.

3. Rename or remove the original 'LEGO.JAM file'.

  • Like 2
Link to comment
Share on other sites

I'm now pretty convinced most games work like this, but I'm too lazy to test on the variety of games I have reason to believe would work like this. All I know is that LegoRR, LEGO Racers and F.E.A.R. all use this behavior.

Link to comment
Share on other sites

I guess this would negate the need for a JAM Compiler if it hasn't been completed already. If I get LR1 on this computer I'll definitely use this no-JAM method.

Link to comment
Share on other sites

JrMasterModelBuilder

SWEET!!!!

And here I was pulling out my hair on how to re-curse through the folders and append all the files properly. I should have just tried this. Great find!

Link to comment
Share on other sites

Oh heck yes! Easy modding here I come! :D Edit: Not working for me, crashes on startup.

Different versions perhaps? I dunno, you extract it all?

Link to comment
Share on other sites

The same happened for me. I didn't change anything about the extracted GAMEDATA and MENUDATA folders, but I do have an extra folder in the installation directory that's storing backups of the extracted files and the JAM.

Link to comment
Share on other sites

  • 2 weeks later...
Fluffy Cupcake

When doing this I get

"Fatal Error

Unable to set message drain"

On start up, it has a different reaction when I add -novideo to the parameter. It just simply says "LEGORacers.exe has stopped working"

Also note, that whereas I would usually get UAC (User Account Control) on game start up (I use Vista :P), when I remove the jam it doesn't ask for it. I did try running the game as administrator, but still got the same problems.

Link to comment
Share on other sites

  • 5 months later...

The last post on here was in September, and it was by me, eh? Well, I'm going to bump it because I have new info, and because Cyrem just said he would rather bump old topics than start a new one on the same subject.

I was just looking into this. Everyone (myself included) says that the method posted by Cyrem doesn't work, LR1 just crashes on startup (DOA, you might say). And it just did the same thing for me, as shown by this picture:

(NOTE: I had to complie these pics. The messages were not really where they are.)

mrfkn4.jpgkey05aec3a7360e4b0004799d6c287

But if I put the files into a folder named LEGO.JAM, I get this message:

2a0dy4n.pngkey3fcf84f4097862695245387865

It says GImages.idb is missing, and thus cannot load.

Perhaps origamiguy can help out with this, but could the extractors be missing this one file? It would seem that way, but I don't know how both of them would miss it, unless origamiguy used JMMB's code and ported it to C++. That would do it.

Also, I found that if I rename a real jam back to LEGO.JAM while having a folder by the same name, I get the message saying "There is already a file with that name". So something is up here.

(How did that first pic get saved as a .jpg, and the second one a .png? I always use .png! Oh, Paint and it's default settings. *sigh*)

EDIT: I found some more info about this error. GImages.idb is missing at all. It's located in the root of MENUDATA. Yet LR1 says it's missing and it won't load because of that. I moved it to the folder named LEGO.JAM and in the same folder as the exe (neither of which make sense because it's supposed to be inside MENUDATA which is inside the .JAM), and I got the same error. GImages.idb is 751 bytes, that is the same size that the demo has. Even the demo fails with this error. What could be going on here? It seems this "missing" file is blocking us from modding LR1 without recompiling the .JAM everytime.

Link to comment
Share on other sites

JrMasterModelBuilder

The last post on here was in September, and it was by me, eh? Well, I'm going to bump it because I have new info, and because Cyrem just said he would rather bump old topics than start a new one on the same subject.

I was just looking into this. Everyone (myself included) says that the method posted by Cyrem doesn't work, LR1 just crashes on startup (DOA, you might say). And it just did the same thing for me, as shown by this picture:

Actually, I said it works, which it does for me. ;)

Let me clear some things up:

Also, I found that if I rename a real jam back to LEGO.JAM while having a folder by the same name, I get the message saying "There is already a file with that name". So something is up here.

I assume this is a error from Windows, and not LEGO Racers, correct? Windows (and every version of Mac and Linux I've ever used for that matter) do not all a file and folder of the same name to exist in the same folder. They would both have the same path reference /folder/file.ext (the folder) and /folder/file.ext (the file) so it's impossible.

But if I put the files into a folder named LEGO.JAM, I get this message:

It says GImages.idb is missing, and thus cannot load.

Perhaps origamiguy can help out with this, but could the extractors be missing this one file? It would seem that way, but I don't know how both of them would miss it, unless origamiguy used JMMB's code and ported it to C++. That would do it.

EDIT: I found some more info about this error. GImages.idb is missing at all. It's located in the root of MENUDATA. Yet LR1 says it's missing and it won't load because of that. I moved it to the folder named LEGO.JAM and in the same folder as the exe (neither of which make sense because it's supposed to be inside MENUDATA which is inside the .JAM), and I got the same error. GImages.idb is 751 bytes, that is the same size that the demo has. Even the demo fails with this error. What could be going on here? It seems this "missing" file is blocking us from modding LR1 without recompiling the .JAM everytime.

Here's what I think is happening (I say that I think because it does seem a little strange to me). The game allocates memory to the LEGO.JAM file, or folder in this case, then starts the game, loading files from memory as it needs them (my guess being that GImages.idb is the first it needs). Because it loaded a folder into memory (completely invalid), it fails to load the file.

I know origamiguy made a C++ extractor, but if he doesn't create a recompiler before I get time, I'll rewrite my extractor in Python (which I've been teaching myself, so it would be good to actually make a program with it). Python should be much faster (not as fast as C++, but . . .), portable, small size, etc.

Link to comment
Share on other sites

Actually, I said it works, which it does for me. ;)

How? If that is another thing that was changed from the 1999 to 2001 version (I have the latter), I really need to start looking for a 1999 version more! (The only thing is my Birthday is next month, and it's a family rule that, if it's my Birthday, I can't buy anything about a month before it, and the same goes for rio, and Christmas.)

I assume this is a error from Windows, and not LEGO Racers, correct? Windows (and every version of Mac and Linux I've ever used for that matter) do not all a file and folder of the same name to exist in the same folder. They would both have the same path reference /folder/file.ext (the folder) and /folder/file.ext (the file) so it's impossible.

Yes, it's an Windows error.

Here's what I think is happening (I say that I think because it does seem a little strange to me). The game allocates memory to the LEGO.JAM file, or folder in this case, then starts the game, loading files from memory as it needs them (my guess being that GImages.idb is the first it needs). Because it loaded a folder into memory (completely invalid), it fails to load the file.

I know origamiguy made a C++ extractor, but if he doesn't create a recompiler before I get time, I'll rewrite my extractor in Python (which I've been teaching myself, so it would be good to actually make a program with it). Python should be much faster (not as fast as C++, but . . .), portable, small size, etc.

That does sound really wierd. But then how can your copy run like that but the 2001 version cannot?

You're making another extractor? :P That's great! Hopefully it will be smaller than the Air version. But I still want to run my copy without the JAM.

Link to comment
Share on other sites

JrMasterModelBuilder

Actually, I said it works, which it does for me. ;)

How? If that is another thing that was changed from the 1999 to 2001 version (I have the latter), I really need to start looking for a 1999 version more! (The only thing is my Birthday is next month, and it's a family rule that, if it's my Birthday, I can't buy anything about a month before it, and the same goes for rio, and Christmas.)

Here's what I think is happening (I say that I think because it does seem a little strange to me). The game allocates memory to the LEGO.JAM file, or folder in this case, then starts the game, loading files from memory as it needs them (my guess being that GImages.idb is the first it needs). Because it loaded a folder into memory (completely invalid), it fails to load the file.

I know origamiguy made a C++ extractor, but if he doesn't create a recompiler before I get time, I'll rewrite my extractor in Python (which I've been teaching myself, so it would be good to actually make a program with it). Python should be much faster (not as fast as C++, but . . .), portable, small size, etc.

That does sound really wierd. But then how can your copy run like that but the 2001 version cannot?

You're making another extractor? :P That's great! Hopefully it will be smaller than the Air version. But I still want to run my copy without the JAM.

Mine works just like Cyrem explained. Them changing it would be my guess, that's actually why I thought you were trying to get the 1999 version. I'm sure they set it up to load single files from the hard drive for faster development. Maybe they decided to remove it like the trophies for some reason.

Yeah. I want to teach myself the binary processing capabilities of Python, and I think this would be a good way to go about it.

Link to comment
Share on other sites

I was actually trying to get a 1999 copy because I wanted to see the trophies myself, and I found out that, in the 2001 version, the loading screens are put into a yellow frame and the menu background is around that. But now that I know that it can run without a JAM, I want it even more.

Well, go knock yourself out with that extractor. :P

My brother (known as rioforce or rio) and I were talking about this last night because I told him... well, about this topic. He mentioned something that may explain why the 1999 version can run without a JAM but the 2001 version has to. Did you happen to beta-test LEGO Universe? If so, you'll know what I'm talking about.

When Beta launched, the most of the game files were sitting on the hard drive uncompressed. They could be viewed, swapped, and modded. This was probably done so the devs could work on the game easier. It wasn't until mid-beta that they were compressed. After that, they only way to run LU was with the compressed files (until there was a patcher bug and someone figured out how to run the game without the compressed files).

Rio thinks this same thing might have happened with LR1. The game was designed to run without the JAM for easier development, and the code to run it like that was not removed at launch (the 1999 version). When XP came out and it was updated for it (the 2001 version), they removed that code and made it where it has to run with the JAM.

Link to comment
Share on other sites

Rio thinks this same thing might have happened with LR1. The game was designed to run without the JAM for easier development, and the code to run it like that was not removed at launch (the 1999 version). When XP came out and it was updated for it (the 2001 version), they removed that code and made it where it has to run with the code.

I'm going with this theory.

Link to comment
Share on other sites

I just bought the 1999 version and mine works as well!

I think that le717's theory is correct. So what is the big advantage of having the jam

arcive being open for the game to locate anyway?

Link to comment
Share on other sites

I just bought the 1999 version and mine works as well!

I think that le717's theory is correct. So what is the big advantage of having the jam

arcive being open for the game to locate anyway?

Having an extracted JAM meant that during development the developers didn't have to recompile the JAM every time they changed something.

Link to comment
Share on other sites

  • 4 months later...

Well it's good to know I wasn't going insane and there was a reason not many could get it to work.

Probably should add the version thing to the topic.

Link to comment
Share on other sites

  • 5 months later...

It says GImages.idb is missing.

Check the MENUDATA folder for it.

I get the message saying "There is already a file with that name". So something is up here.

Rename the folder.

Link to comment
Share on other sites

Flex (AKA LUModder), did you even finish reading the topic before you posted that? The reason that error message came up has already been discovered. In fact, rio and I figured out the fix, and in the process, helped out thr LR modding research... :/

Link to comment
Share on other sites

  • 3 months later...

Just wanted to report that, while, yea, 2001 Racers cannot run without a JAM, if MENUDATA and GAMEDATA are present in the folder along with LEGO.JAM, it ignores it. I just tested this (it has been bugging me for two days now, related to PatchIt). I forgot I had Rock Racers installed into 1999 (I still haven't played it... :/), and after I loaded Racers 2001 with the folders, it loaded with Redbeard on the front.

 

2zgc034.png

Link to comment
Share on other sites

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.