Something to test out to solve memory map errors

[kegetys 2]

Despite my efforts, I have been unable to get myself to intentionally have a memory map error, so I dont know if this will really help, but it should...

So, what I would need someone to test out, is to do the following:

Find a big addon PBO you are having memory map errors with, for example the res\addons\o.pbo from Resistance.

Unpbo it, extract the whole PBO under your OFP directory into a directory that has the same name as the PBO, so for example c:\ofp\res\addons\o.pbo contents are extracted to c:\ofp\o\ directory.

Copy the config.cpp/config.bin, and stringtable.csv from that directory, and put them into their own PBO file, and replace the original addon pbo (c:\ofp\res\addons\o.pbo for example) with this one (Take backup of the original first though).

So now you should have a very small addon pbo which has only the config, and all other files from the addon in the directory under your OFP dir. Test it out, everything should still work as before, but there is no longer need for OFP to map the whole huge file into the virtual address space as the files are found from the regular file system.

This should help to memory map problems, but as said I cant test it myself... Also note that if some multiplayer server has this addon in its checklist you will get a modified datafile message.

Technical mumbo jumbo:

The problem apparently comes from Windows/OFP hitting the 32bit integer limit that all 32bit systems have. When OFP starts up, it uses a windows file mapping feature to map the addon PBO's into virtual memory addresses (it will not really allocate any memory as far as I know, so free memory amount has little to do with it). It works so, that OFP just tells the file name, and windows gives back a virtual memory pointer, that when accessed like "real" memory is the same as reading/writing the original file. Its a quite fast and easy way to access files, but the problem comes from the 32bit integer system, which can only point to maximum of 4 gigabytes of memory. And this all is not for OFP to use, Windows eats a fair amount of it and also the video card, especially if you have set a large AGP aperture size, and/or alot of memory in the video card or buggy video drivers in general or other software which eats it. When we take off the files from the PBO, there is no longer need to map the huge PBO files into the virtual address space, but OFP will just use regular file functions to access them. It will propably cause a little decrease in file access speed, but should be a fair trade off for not being able to run OFP at all.

Note that im no windows memory management expert, so there could be some mistakes on my explanation but it should be about right :P

[blackdog~ 0]

I'm not having memory-map errors on large files, rather on a single player mission (that is installed by default by the OFP installer).

What should I do in this case?

[kegetys 2]

I'm not having memory-map errors on large files, rather on a single player mission (that is installed by default by the OFP installer).

I would assume that they use the same memory address range, so doing this thing to some big addon pbo (o.pbo for example) should reserve enough address space for quite many missions or whatever gives the error...

[Gen.Carnage 0]

your explanation sounds solid to me, and it might well work.

This is good news for the addonmakers and users, larger

pbo's (addonpacks) may run on more systems using this method.

[drewb99 0]

I just tried this and I'm pleased to say it works like a charm

[Major Fubar 0]

A friend of mine at our LAN session the other night was having the memory map problem, so I suggested a fix someone here at the forums posted a while ago - he moved o.pbo from res/addons to the addons directory, and didn't have the problem again...just thought I'd let you guys know.

[waffendennis 0]

Yep this works and thnxs again for the tip Kegetys

[shadow 6]

<span id='ME'><center>Shadow grabs glue and makes this a sticky </center></span>

....in the Troubleshooting-forum btw

[BAM 0]

I have another success story to add to this thread, kegety's tip works a treat!

I was having a memory map error with the Winter1985(ofpr).pbo campaign, but when I dePBOed the O.pbo and followed the instructions, it worked great from then on.

Happy days, another great contribution from Kegetys

BAM.

[Guest]

Something else I tried that it would be nice to get someone to confim for me is I think you can get rid of your Operation Flashpoint/Dta/Data.pbo if you are using Resistance. Like I said, I tried it, and it worked for me, but I don't know if this is just because I have a strangely modified version of OFP (as tend to happen when you are working on a mod). Anyway, if it does work, there's another 100mb out of the start-up

[Gothico 0]

Since I use "MOD" Folders, this error never appeard again...  

[berghoff 11]

Thanks for this topic. I DID work for me still canplay on nogova. Now I'm gonna to download the FDF mod to test it.  

OK FDF is up and running! THX! THX!

[malick 0]

I think you saved my life today !

I was ready to jump off the nearest cliff... This problem has been poisoning my life for the last 6 weeks.

Thanks Kegety !

[BBSmith 0]

Quote[/b] ]Copy the config.cpp or config.bin from that directory, and put it into its own PBO file, and replace the original addon pbo (c:\ofp\res\addons\o.pbo for example) with this one (Take backup of the original first though).

What do you mean? (I have the o.pbo error to but, I dont understand what you mean with "Copy config and put it into its own PBO file"

[malick 0]

Quote[/b] ]Copy the config.cpp or config.bin from that directory, and put it into its own PBO file, and replace the original addon pbo (c:\ofp\res\addons\o.pbo for example) with this one (Take backup of the original first though).

What do you mean? (I have the o.pbo error to but, I dont understand what you mean with "Copy config and put it into its own PBO file"

I think he means that you have to re-PBO the config.bin or .cpp into its own PBO, without anything else in it. The rest of the data is in another folder. This way, the PBO is just a few Ko large, not Mo...

[BBSmith 0]

Ok, I did what you said.. As well as Avon's..

But I dont understand BIO's or AGP or any of that..

And I DONT know anyone who does!

I tried CutPBO, (no luck)

I did what you said. (no luck)

I tried Virtual memory settings (no luck)

I have only a few addons in my game.

I will be watching the forum every few mins to check to see if sum1's listing and knows a solution.

I have messed with my Virtual memory, but i tried making it low, didnt work), and then i made it as high as it can go (2000,2000)

When i got the computer it was at 1533, 2000.

No luck.!

If you have any ideas please post them.

I'll be waiting

[zingodude 0]

You guys rulez.

I did the following:

1. Use CutPBO at Command Prompt To Cut off 48bytes off the original O.PBO.

2. You should have New-O.PBO file.

3. Rename the New-O.PBO file to O.PBO

4. Use DePBO to extract files from O.PBO

5. Copy Config.bin to a temporary folder call O (Folder can be anywhere)

6. Use MAKEPBO to compress the temporary folder you made.

7. You get a new O.PBO file (should be a a few bytes), you will then proceed to overwrite the original O.PBO.

Everything works out fine. My windows XP no longer reboot by itself due to memory mapped dump error.

[KaRRiLLioN 0]

I just bought a Geforce FX 5900 Ultra 256 MB DDR RAM to replace my GF4-Ti4600 128 MB DDR. I have a goodly number of addons, but not a huge number and after switching the cards out and using the same drivers (it autodetects on restart) I suddenly got the Cannot Memory-map O.pbo error. I tried everything in Avon's FAQ, even the cutpbo method. I changed the AGP apeture size to every setting in the BIOS as well.

My system specs are:

P-4 2.8 GZ

1.0 GB 333 MZ DDR RAM

GF FX 5900 Ultra 256MB DDR, Nvidia 44.03 (latest drivers)

2.0 GB Virtual RAM (pagefile)

Windows XP Professional SP1

Resistance version 1.91

I removed all unofficial addons and Resistance worked again. I then added addons back to the OFP Addons folder (this is where I keep all unofficial addons). After getting to about 46 MB of addons not including the official ones already there, then I started getting a green screen on startup. If I removed addons to get it back below 47MB or so of unofficial addons then it would work normally. Above this number and I would get the green screen. By adding a few more it would crash giving me the "Cannot Memory-map" error.

I then placed my GF4-Ti4600 back in, loaded back up ALL of the addons, and it worked again.

I finally gave in and used Kegetys's method and it worked. I suppose once I start hitting against the 46 MB ceiling again then I'll have to do the same thing to some of the other addons.

This is REALLY ticking me off. It seems that most ppl who have upgraded to new video cards, be they ATI Radeons or Geforce FX's are having these issues, where there is a small limit on the MB's of addons that OFP will load up before the memory-map error. I hope this can be patched or something, although I'm unsure as to whether it's more of a Vid-Card manufacturer issue, or an OFP issue.

Anyway, thanks for the idea Keg, but I hope there's a more elegant Addon handling system for OFP-2.

[gigimxul 0]

I have a slight problem...I did as the instructions said, I unpbo'd the o.pbo to its own directory and created a new one with the same name containing only the config.bin.  However when I play the game, it says I'm missing all these files, files that are in the original o.pbo that I unpbo'd.  Am I suppose to do something with all these other files? Thanks

[KaRRiLLioN 0]

When you de-pbo the files, you are left with a directory named O. Move this directory to your root Operation Flashpoint directory, i.e.

c:\games\operation flashpoint\O

I have noticed some bugs with this approach. When I go to an ammo crate, there are a lot of blanks in the ammo list, and also some Resistance player models will not show up in my target list when I'm the commander and trying to get ppl to target them. It's rather odd.

[kegetys 2]

I have noticed some bugs with this approach.  When I go to an ammo crate, there are a lot of blanks in the ammo list, and also some Resistance player models will not show up in my target list when I'm the commander and trying to get ppl to target them.

Ahh, this must happen as the strings are stored in stringtable.csv instead of the config... So include the stringtable.csv file into the small pbo too, it should then work...

[blackdog~ 0]

Looks like BIS is going to fix this in the next patch..

[KaRRiLLioN 0]

Thanks Keg, will try.

[malick 0]

By the way, I got rid of my memory mapping problem, but it seems I can't depbo O.pbo and some really big pbo (like kegety's snow islands...).

I use pbotool, and it creates a directory called O, but it leaves it empty I can't apply kegety's method with these large files...

Has anyone an idea or an explanation ?

Thanks anyway

[Dauragon 0]

By the way, I got rid of my memory mapping problem, but it seems I can't depbo O.pbo and some really big pbo (like kegety's snow islands...).

I use pbotool, and it creates a directory called O, but it leaves it empty   I can't apply kegety's method with these large files...

Has anyone an idea or an explanation ?

Thanks anyway

Use PBO Decompressor