Jump to content

Joe9412
 Share

Recommended Posts

I see... so if you (or someone) sent me the new icd and exe files, then I could put that in my LRR folder and it would run without the cd? (assuming that's the only thing that was changed)

That is correct. Or if it is somehow possible to unencrypt the exe, that would be a possibly also.

Link to comment
Share on other sites

That is correct. Or if it is somehow possible to unencrypt the exe, that would be a possibly also.

Well why hasn't it been decrypted yet? We could debug it, give it 32bit support, and then possibly make it run-nonencrypted and still read the game data as normal.

Edit: If it DOES get decrypted, I would like to know how the method came about as I've loooonged for a way to decrypt the exe for SW:FOC... lol

Link to comment
Share on other sites

That is correct. Or if it is somehow possible to unencrypt the exe, that would be a possibly also.

Well why hasn't it been decrypted yet? We could debug it, give it 32bit support, and then possibly make it run-nonencrypted and still read the game data as normal.

Edit: If it DOES get decrypted, I would like to know how the method came about as I've loooonged for a way to decrypt the exe for SW:FOC... lol

I have the de-crypted version. All disc-less versions of the game are not encrypted. Giving the game 32bit support is next to impossible without changing the game's source code.

Link to comment
Share on other sites

Anonymouse

That is correct. Or if it is somehow possible to unencrypt the exe, that would be a possibly also.

Well why hasn't it been decrypted yet? We could debug it, give it 32bit support, and then possibly make it run-nonencrypted and still read the game data as normal.

Edit: If it DOES get decrypted, I would like to know how the method came about as I've loooonged for a way to decrypt the exe for SW:FOC... lol

I have the de-crypted version. All disc-less versions of the game are not encrypted. Giving the game 32bit support is next to impossible without changing the game's source code.

Yep. Amauros, you need to decompile it to actually edit it to support 32-bit colour.

Link to comment
Share on other sites

Well I still would like to have a method of decrypting exe files lol. I'm more interested in modding foc than lrr :P ...but I would still like to have a look at the unencrypted version of lrr.

Link to comment
Share on other sites

Anonymouse

Well I still would like to have a method of decrypting exe files lol. I'm more interested in modding foc than lrr :P ...but I would still like to have a look at the unencrypted version of lrr.

Unencrypted is just runnable without the disc.

I'm pretty sure you mean the source code of LRR.

Link to comment
Share on other sites

ive got some probs too, ive got the funzone release of the game *bought it last night in case my old disk broke or even lost it, i know u can run it without disk but i need it for playing at home whilst on my laptop ive installed it for diskless play in areas like cafes* on the defending rr hq it crashes when i get out the sonic blaster

Link to comment
Share on other sites

Well I've been editing the cfg file for almost a week now... and I had noticed an increase in the rate of crashes the more I edited the cfg file. I thought that was strange since I was only editing the stats... (that's why I came here in search of a solution which apparently there isn't lol) Unfortunately, my game started crashing at startup, and didn't know why. So I replaced the cfg file with the backup, and now my game works smoothly. Although I did play a little easier on the game, keeping around 12 RR's instead of maxing them out. Oh and that brings me to the fact that somehow I broke the RR cap while editing the cfg. >.>

I guess I'm gonna have to mod a little slower since this game is so touchy... and I thought foc was bad lol.

Link to comment
Share on other sites

Anonymouse

Well I've been editing the cfg file for almost a week now... and I had noticed an increase in the rate of crashes the more I edited the cfg file. I thought that was strange since I was only editing the stats... (that's why I came here in search of a solution which apparently there isn't lol) Unfortunately, my game started crashing at startup, and didn't know why. So I replaced the cfg file with the backup, and now my game works smoothly. Although I did play a little easier on the game, keeping around 12 RR's instead of maxing them out. Oh and that brings me to the fact that somehow I broke the RR cap while editing the cfg. >.>

I guess I'm gonna have to mod a little slower since this game is so touchy... and I thought foc was bad lol.

Yeah... It never complains, only crashes (bad CFG or other files) or doesn't work (in the case of some bad level files).

You have to mod the values one-by-one, and if it doesn't work, check the last, see if you can fix it, and if not, revert. It's a slow process, but it's the only way to really get anything working.

Things to make sure:

  • A value that previously had a . in it (e.g. 1.0000) MUST still have the point in it after modding
  • Spaces in names must ALWAYS be replaced with underscores (_)

I may add more and post a full list at some point.

Link to comment
Share on other sites

  • 4 months later...
  • 2 months later...

New here, and getting this problem quite a bit.

I want to say it's a performance issue, and it has nothing to do with your hardware. I think the icd is what is constantly updating threads in the game (tasks for each RR, monster, vehicle, etc). When you max out your RR cap and start drilling/cleaning like there's no tomorrow, that creates so many threads that the icd can't keep up. The reason is because it's 16bit software, which is much much slower than 32bit and 64bit software.

I've been studying the .cfg file, and I've noted that there are goal-update times. There are trigger update times for each level, goalupdate times for the bats (and probably a few other creatures), and a few other such items. It may be that if we "slow" down these times, the icd won't have to work so hard and the crashes might happen less often or even stop. I'll test this sometime and let you guys know how it turns out.

Where'd you get that information? I don't know much about how the game works, but are you sure that it is multithreaded? I don't recall computers in 2000 having multiple cores, and so I doubt the programmers would have based it around multiple threads, as this would run slower on a single core architecture.

Using a JIT debugger, it seems to be that the crash is due to accessing memory that wasn't allocated by the program. Modern OS are very good at being safe and crashing anything that is accessing invalid memory, and so I assume this is why the program crashes. Haven't checked the dissassembly, but I doubt it is fixable.

Link to comment
Share on other sites

You can allocate more memory for LRR to use. In the CFG, find the TextureUsage variable. Increase it. You can teleport more raiders into the caverns this way. Some people have teleported up to around 200 raiders at once without the game slowing down, and lowering the variable decreases the quality of the game's textures, so we know it works.

Link to comment
Share on other sites

  • 3 weeks later...
 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.