Random AI Turn Crashes

[Litharion]

Edit - Make sure to update to the latest DeI version (1.1e). If you still get a crash that doesn't repeat when you load and are using the latest version, then post in this thread. Thanks!

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

Spoiler Alert, click show to read: 

If you experience constant crashes during the AI turn cycle, please use the Debug_Log.pack. The pack file will create 2 log. files in your main Rome 2 Folder.
(not the data folder, the one above the data folder). This is for non-repeatable random AI turn crashes, not repeatable crashes. If you have a crash that repeats when you load, post the save in the bug reports thread.

What we need!

If you want us to investigate the crash, upload the
1. DEBUG_Supply_System_Log
2. DEBUG_major_log
3. a save game right before the crash (%appdata%,-> The Creative Assembly -> Rome2\save_games)
4. When did the crash happen ?
- AI turn cycle
- selecting an army or city
- directly after or before a battle
5. System specs (total RAM, etc)

Only if all required informations are given, I can take a look at why the game crashes.


How to use:
1. Download the Debug.log
2. activate Debug_Log.pack, load before the DeI main files
- not compatible with Ancient Empires
3. deactivate all other mods despite DeI and the Debug_Log.pack
4. Start a new campaign or continue a campaign
5. Play until it crashes on the Campaign map

The thread will be strictly moderated and is not meant for discussions, so please only post here if you have a random crash and can provide the required files.

-regards, Litharion

[Unactuality]

Getting a repeatable crash on the Insubres (I think) turn.

All 3 files are in here:
http://www.filedropper.com/deicrashfiles

Edit: Thanks, crash is repeatable. Fixed in 1.1e.

[ZainDBreaker]

What program should I use for the debug.log. I'm unable to activate it.

[Litharion]

What program should I use for the debug.log. I'm unable to activate it.

You just have to download and activate the pack. The log file will be in your Rome 2 folder after playing a campaign with it.

[Lord Dakier]

I'd recommend getting people to verify their game and ensure the data folder is cleared. I had these symptoms and it fixed my issues.

[LethaL]

@Lord Dakier Cleared of what exactly??

[ildar]

https://drive.google.com/open?id=0B5...kVVUDdVOUJPaXM
I can't find DEBUG_Supply_System_Log, file despite loading pack file before DEI, crash is during AI turn Suebi

[Dresden]

https://drive.google.com/open?id=0B5...kVVUDdVOUJPaXM
I can't find DEBUG_Supply_System_Log, file despite loading pack file before DEI, crash is during AI turn Suebi

Thanks for posting this, we will take a look and see if it helps identify any issues. The supply debug file should be in the same location as the others. However, its possible that you are using the 1.1e fix pack and it loaded before the debug pack.

[ildar]

hi, yeah indeed, should I place debug before 1.1e fix then? I am about to start new campaign pure for testing purposes, so wanted to make sure that my setup is proper.

[Syanox]

It's very likely virtual memory exhaustion.

For the impatient : in a terminal, as administrator, run : bcdedit /set increaseuserva 3072
and reboot.

The longer explanation :

Rome 2 is a 32-bits program, whether running on a 32-bits systemor not. This means that machine words (integers) can store values ranging from 0 to 2^32 (4G). And these integers are sometimes used to store the address of an object in memory. Because of common operating system design practices, there is a split between user programs and the kernel, the most privileged piece of software in the operating system. On Win32, this split is 2/2, meaning there are 2G for the program and 2G for the kernel. I've monitored how much memory Rome 2 uses with DeI, and it turns out it reaches a pretty 1.8G after a battle. This value is less than 2G but there is uncompressible fragmentation (say, holes of unused but unmovable memory in the address space) that allows exhaustion without actually filling the whole address space. There could be peaks above that value that my monitoring tool didn't sample, in particular when a player triggers an end of turn.

The procedure above is described in more details in an older post on this very forum for the very same problem (see http://www.twcenter.net/forums/showt...uot-workaround). It's also mentioned on Microsoft MSDN (see https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx). Most importantly, the short one I gave here only works for "modern" Windows versions (Vista+), so go read those if you want to know more.

For the devs out there: mind portable programming. An int is not a long and is not a long long. And uint32_t/uint64_t/uintptr_t weren't added to languages so that they could happily be ignored. It's 2016 dammit, there's 64-bits everywhere.

[Causeless]

For the devs out there: mind portable programming. An int is not a long and is not a long long. And uint32_t/uint64_t/uintptr_t weren't added to languages so that they could happily be ignored. It's 2016 dammit, there's 64-bits everywhere.

Using uint32_t and other strictly defined types like that is generally a bad idea, unless you know you need it. It means that the compiler cannot optimize it as easily reducing performance (a 64 bit int is typically faster to use than a 32 bit int, for example, on 64 bit CPUs), and it's in reality less portable due to other (mostly RISC) processor architectures which have memory alignment requirements.

If you KNOW, for whatever reason, that you need your variables to be an explicit size - if working with huge amounts of data, or needing massive numbers for example - then sure, go ahead. But for most random variables that do not require large data types, you should use whatever type gives the compiler the most freedom.

If the crash is due to to Rome 2 using too much memory, then it's not really the game's fault (since it's only a good thing that they could optimize the game to work with just 2 gb of memory). You could use a simple .exe hack to allow the process to become large-address aware (4gb instead of 2, I believe), as a quick fix. If assuming the issue is memory usage then the best solution is for DeI to optimize the function's memory usage rather than using weird tricks like that.

[Dresden]

Yeah rename the debug file so its is higher alphabetically and then just make sure its listed first in mod manager.

Another thing you can test is turning AI attrition in the supply system off. If you have PFM (pack file manager) you can do this pretty easily. To do that you can go to /scripts/lib/lib_supply_system.lua and change "activate_attrition_for_ai = true" to "activate_attrition_for_ai = false"

[Dresden]

If you are experiencing random AI turn crashes that are not repeatable on load, please try out this test pack - http://www.twcenter.net/forums/showthread.php?705528

[Dresden]

Hopefully this issue has finally been fixed, so I am going to unsticky this thread. If you get a crash that doesn't repeat and are using the latest version of DeI (1.1e) then please post in this thread.

[Phalangitis]

Dresden, It was one thing or a combination of factors? I ask because this might happen to any other overhaul out there and the cause or the solution might help other teams also.
Thanks.

[Dresden]

This specific one was a script function in the supply system that was attempting to locate nearby enemy armies. At least, that is my understanding of it. I helped track it down but Litharion would better understand the exact nature of it. We aren't sure why that specific function wasn't working at very odd/random times. Our only explanation is that it may return a nil result in very weird circumstances.

So, for now, we removed that part of the script.

[Litharion]

we set it to always return true to be exact

[Violent Whimsy]

Thanks guys for all the work on this. Haven't AI turn crashed since the update

[Syanox]

Using fixed width types isn't generally a bad idea. Just use them when you need them, i.e. serialization. My post was actually more concerned with uintptr_t, because that's what lots of developers don't know about. They cast their pointers to int/long/long long without care. And that's what mostly makes programs unable to quickly be ported to 64-bits. The post was meant to any TW developer out there, however unlikely they actually read it. I'm not starting a debate.

[Causeless]

Using fixed width types isn't generally a bad idea. Just use them when you need them, i.e. serialization. My post was actually more concerned with uintptr_t, because that's what lots of developers don't know about. They cast their pointers to int/long/long long without care. And that's what mostly makes programs unable to quickly be ported to 64-bits. The post was meant to any TW developer out there, however unlikely they actually read it. I'm not starting a debate.

So then we ultimately agree. Only use the types if they are needed, but not for most random (and especially stack-allocated) data being used.