C2C - UEM - Ultimate-Earth-Map 100% MOD and SVN update compatible by Pit2015

100 civ dll is justified now as memory usage is improved or later if it improves further, 40 civs can stay recommended but more are possible to use on own risk, its only not prioritized currently. :)
Ah, see there's the problem with it. Much of the memory usage is allocated when you open it up that far even if you aren't using all those player slots in your game. So its limiting even for those who choose more wisely.

And yes, we've relaxed, with great efforts, our memory limits, and work continues to do so, but we didn't do it to just recreate the problem in this direction - there are other more pressing projects to attend to that will need that memory.
 
Yeah someone has to come up with cool code to save 90% to the HDD. :thumbsup: 2023 soon and no solution for 32bit games? :coffee: Or maybe crush that VRAM somehow or use it more.

Someone try to flag the DLLs LAA, and let me know if it conserves more memory or shout out and i test it, put it into latest svn, nothing to loos. :) But report here i want to know. On my other mod i managed to conserve about 600kb.
 
Someone try to flag the DLLs LAA, and let me know if it conserves more memory or shout out and i test it, put it into latest svn, nothing to loos. :) But report here i want to know. On my other mod i managed to conserve about 600kb.
Our dll is compiled with the large address aware flag set.
The BtS process can use more than 2 GB of RAM which proves that it is large address aware as 32 bit programs can only use 2 GB of RAM without being large address aware.
The exe decides how to partition/allocate the 4GB of RAM it has available, and it has chosen to reserve 1.2 GB for other things (graphics, audio, misc), and has thus only allocated 2.8 GB to the actual game code.
It's an exe thing, there is nothing we can do, so please stop beating this dead horse. :deadhorse:
All we can do is to find ways for the BtS process to use less RAM, and that is something we are constantly working on one way or another when we see ways to do so.
 
Last edited:
Dll's don't have LAA flag, it's an exe thing. Also, the BtS process can use more than 2 GB of RAM which proves that it is large address aware as 32 bit programs can only use 2 GB of RAM without being large address aware.
The exe decides how to partition/allocate the 4GB of RAM it has available, and it has chosen to reserve 1.2 GB for other things (graphics, audio, misc), and has thus only allocated 2.8 GB to the actual game code.
It's an exe thing, there is nothing we can do, so please stop beating this dead horse.
All we can do is to find ways for the BtS process to use less RAM, and that is something we are constantly working on one way or another when we see ways to do so.

Read this under FAQs: DLLs should be able to LAA flagged, try to patch them LAA.

FAQs​

"Do you need to LAA patch DLLs? The answer is a qualified 'yes'. See the Wikipedia articles Dynamic-link library and Virtual Memory for the full background, but the relevant point is this:

"With the introduction of 32-bit libraries in Windows 95 every [DLL] process runs in its own address space." [This would be physical address space. As far as the application is concerned, the DLL is loaded into it's virtual address space.]

DLLs share the same file format as an EXE. As with EXEs, DLLs can contain code, data, and resources, in any combination, within their own address space. Conceptually in abstract they are the same type of file: separate but cooperating programs or applications ('apps'). The LAA flag is a 'Large Address AWARE' flag (my emphasis). It enables a DLL (which is loaded as needed by the calling program, and thus relatively unpredictable by the player) to load into physical memory locations greater than the 4 GB virtual space addressable by the 32-bit game. Without the flag, they will only be loaded into the same 4 GB space as the game. The more code you can get to utilize the higher memory above 4 GB, the more room for the code (and data) which can't (not LAA enabled). It's about memory management in loading code, which reduces the chances of exceeding available memory.

LAA flagging does not prevent a program from gobbling up all available memory until it crashes, nor is it a magic bullet that makes the code 'better'. There is no guarantee that a DLL will perform correctly when loaded to upper memory if it was not LAA flagged by the developer. But it should manifest problems quickly in that case if the registry test setting suggested above is used, and has proven to successfully improve the amount of available memory for some games (i.e. The Elder Scrolls: Oblivion).


Two Considerations

1. As pointed out above: in a game that is written for a 32-bit environment, 'virtual memory' addressing only goes up to 4 GB. If the game does not handle 'out of memory' conditions well, you get CTDs when it attempts to write data beyond the bounds of it's allocated memory. This is the OS protecting itself from 'rogue apps'. While each 32-bit app gets it's own 'allocated' memory space, they all must share the lower 4 GB of memory because they can't address memory above 4 GB. The more loaded in the lower 4 GB, the less available memory is allocated to each process. All have to fit into the same 4 GB 'bag'.

2. In order to get the maximum use out of that lower 4 GB of memory for a 32-bit game, you need to reduce the 'reserved footprint' of the OS and anything else occupying that space as much as possible. That means loading everything you can above 4 GB with a 64-bit OS, and shutting down any non-essential programs and services with a 32-bit OS. Programs like ioBit's (now Razor's) GameBooster help you determine and decide which apps and services are 'non-essential' as well as provide a simple mechanism to stop and start them. How well you manage this determines how close to the 4 GB game virtual memory limit you can get, even on a 64-bit system. If DLLs are not flagged as LAA, then they won't get loaded above 4GB. They still might not, even with the flag. The only way you can tell is to track each process and find the starting address, but what can you do if it isn't loading high? (Nothing: it's out of your control.) But if the LAA flag is not set, it's guaranteed the EXE or DLL will be loaded into the lower 4 GB of memory and reduce the available memory.

So: flagging a DLL as LAA enables it to be loaded above the 4 GB boundary, and thus make more space available to your game. But it is not absolutely essential, of only minor effect with a 32-bit OS, and any particular DLL might not have any practical effect. But having a chance to reduce your lower memory footprint is commonly regarded as preferable to having no chance. Whether these efforts are worth it to you is a personal decision."


They tell crap or is it possible? So as i understand the DLLs currently go into the 2.8 GB memory the exe is using now, if you flag the DLLs LAA then it will not go into that 4 GB range and free more memory.

But dont ask me how to patch DLLs LAA, you have to research or to find out. But should be the same like for exe files if they similar.

May not work, but is worth a try. If it saves 50-100 kb is better than nothing.

Btw my current memory usage is 1.250 MB at UEM start what is pretty cool, but nothing is impossible in this universe.
 
Last edited:
Well; I was inaccurate in my previous post, as our dll is LAA, so I edited it. My point was that the exe is handling RAM allocation, and it is not giving us more than 2.8 GB for whatever reason.

It might have something to do with how BtS is running python natively, maybe 1.2 GB is reserved for python cache.

Also, I'm pretty sure this is correct: https://social.msdn.microsoft.com/F...e-of-large-address-aware-dll?forum=vclanguage
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Purpose of large address aware dll
Question: My application (EXE) is large address aware and it uses a DLL. This DLL dynamically allocates memory.
...
Interesting point is that non large address aware DLL was also able to dynamically allocate more than 2GB. So, what does large address aware flag signify for a DLL?

Answer:
Nothing. Only the flag on the .exe matters.
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
So our dll is just a slave to the "dll within the exe" which is the file with the code that allocates RAM address space for the process, our dll doesn't matter in this regard.
 
Last edited:
Really try this, flag the DLL LAA should be not to hard with a LAA patch tool, maybe somehow the used DLL gets loaded into the 4 GB exe range also if its a slave and then not.

Some say dont works other say works, so only a test can tell. Maybe it works only on some old stuff and it is the case here.

Yes, thats the question, where does that 1.2 GB go, at the moment its just thoughts. If its python, maybe you can use it somehow or put more into python.

Otherwise if this test dont give a positive result think about a way to find out where are these missing 1.2 GB exactly go.
 
Last edited:
Yes, thats the question, where does that 1.2 GB go, at the moment its just thoughts. If its python, maybe you can use it somehow or put more into python.
It's a point, I could try caching large amounts in python and see if I can go beyond 3 GB usage that way.
Have an array of arrays, and cache a 1 million big array into the first array every new turn I play should probably do it as a test.
 
It's a point, I could try caching large amounts in python and see if I can go beyond 3 GB usage that way.
Have an array of arrays, and cache a 1 million big array into the first array every new turn I play should probably do it as a test.

Beside this i did some RAM testing...

1. I placed 20.000 - 30.000 units on the map, works! Memory usage only 100 MB more. 1.250 MB to 1.350 MB now (After complete game restart). If i move to all regions of the map memory usage is still under 2 GB, as all of the map is loaded with thousands of units outstanding.

2. Closed WB and got this crash: "Failed to allocate video memory..." screenshot RAMTEST1 Line:321 there is a problem but it is fixed if you reload the complete game. Look into there if something can be done there. Increase the outside video memory or something. Tells something about texture, maybe only a bugged texture...

3. After reload i did a game turn, worked! Conclusion 30.000 units only 100 MB more, so 100 civ dll should be no problem.

4. If i restart the game my memory usage is 1.250/1.350 MB also with 30.000 units on map, if i go to every region on world map its 1.900 MB (But the 30.000 units still only take 100 MB more, its the map stuff), so try to fix the unloading of the graphics paging, should clear the memory again if you go to another region, like you restart the game completely, that will save a lot of memory.

Conclusion a long game will be possible now and the CTDs are mostly by game bugs as the memory usage stays far under 2.8 GB.

Interesting if you tab out of the game in fullcreen sometimes the preloaded regions on the minimap disappear, maybe it works to tab out of game and then turn without crashing. Sometimes you need to tab out 3 times before the minimap is not blue anymore everywhere. But ram usage still higher.

Check out and do some testing:

1. Load RAMTEST1 scenario, open WB and close WB, turn = crash maybe.

2. Load RAMTESTSAVE after complete game restart and turn it, should work most times. Watch the combat to ping/view every region. Turn combat animations on. (To be able to start a turn put a production in every placed city)

Looks like someone has to fix the graphics paging to unload the loaded graphics again correctly if you look another region on the map. Game restart does this, in game changing the view to another region its not doing it.
 

Attachments

  • RAMTEST1.jpg
    RAMTEST1.jpg
    321 KB · Views: 16
  • RAMTEST2.jpg
    RAMTEST2.jpg
    3.7 MB · Views: 15
  • RAMTEST1.CivBeyondSwordWBSave
    6.3 MB · Views: 5
  • RAMTESTSAVE.CivBeyondSwordSave
    11.2 MB · Views: 5
Last edited:
@Pit2015
I think units affect TURN TIME heavier, which is a much more annoying issue.
MAFs might be less unavoidable now, but 5-minutes-long turns... no, thanks.
On the other hand, it has not DIRECT roots in the number of civs, since I get much slower turns from swarming Barbs alone, which aren't even actual civs to begin with, just units and cities.
 
@bartigol2
Don't necessarily listen to what Pit suggests, lol.
For some weird reason he dislikes several unique features of C2C, so he will tell you to not use them, but that's literally missing a whole lot of FUN.
Definitely use all Combat Mods at the least - these enhance the gameplay like you would never dream of in Vanilla.
Merging, Stealth, Assassination - these are extremely unique features of C2C that make it so hugely distinct from the normative Vanilla Civ4 (or probably ANY Civ, I'm not sure).
And SVN is basically a server-based ongoing updating for the mod, in case you want to be onboard with the very latest updates.
Though I've seen the modders preparing for v.43 soon-ish (no idea when exactly), so it might be less relevant NOW.
While there were certain discernible changes between the previous release and the current SVN, you as a new player wouldn't feel much of it anyways.
Just play what you have - it'll still show you 99% of what C2C is about, and that's what matters.
Enjoy!
 
@Pit2015 also i see you mention "SVN" - what is it and do i need it to play without issues?

SVN allows you to update the mod while you game, so you always have the newest mod version and you can continue/update your savegames.

As said before, you can change or add options but some options cause memory leaks or bugs, if you want a stable and working long game its recommended to go with the scenario options i set.

After next UEM update i will add "Hard Conquest" if @Toffer90 can come up with it, otherwise i will go back to standard combat and will take "Always raze cities" out as standard scenario option.

Any suggestions to add a options to the next UEM version? Should be good tested...

EDIT:

@bartigol2 Size Matters has issues, so its not good to use it currently.
 
Last edited:
@bartigol2 Size Matters has issues, so its not good to use it currently.
I assume you're talking about the worldbuilder interactions with it?
 
Yep, unclear if it affects gameplay also, how can the AI handle it? As i remember @JosEPh_II said AI cant handle it good.

News:

It does both better and worse in various ways though it's been a bit improved on the AI stuff and more AI fixes are coming that are helping to flat out resolve all sorts of things but none of it is really specific to SM. Some feel the game is more challenging with it and others feel its less so, and a lot of that is based on how the player plays actually. So its a mixed bag either way really.

Interestingly, it helps with memory limit issues to have it on.
 
It does both better and worse in various ways though it's been a bit improved on the AI stuff and more AI fixes are coming that are helping to flat out resolve all sorts of things but none of it is really specific to SM. Some feel the game is more challenging with it and others feel its less so, and a lot of that is based on how the player plays actually. So its a mixed bag either way really.

Interestingly, it helps with memory limit issues to have it on.

Ok, looking into to put it maybe into next update.
 
@Toffer90 and others, is it not possible to allocate more video memory to C2C somehow? I think that can fix some crash problems.
 
Keep at it Pit! :thumbsup:
 
Top Bottom