• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.

Zaleukos

Evöl högerhök
32 Badges
Aug 11, 2001
594
1.714
Visit site
  • Europa Universalis III Complete
  • Shadowrun Returns
  • BATTLETECH
  • Magicka 2
  • Pillars of Eternity
  • Mount & Blade: Warband
  • Europa Universalis IV: Pre-order
  • Europa Universalis IV: El Dorado
  • Cities: Skylines
  • 500k Club
  • 200k Club
  • Victoria 2: Heart of Darkness
  • Victoria 2: A House Divided
  • Victoria 2
  • Rome Gold
  • Europa Universalis IV: Res Publica
  • Crusader Kings II
  • Magicka
  • Europa Universalis III Complete
  • Heir to the Throne
  • Europa Universalis IV: Wealth of Nations
  • Europa Universalis IV: Art of War
  • Europa Universalis IV
  • Divine Wind
  • Europa Universalis III Complete
  • Crusader Kings II: Sword of Islam
  • Crusader Kings II: Sons of Abraham
  • Crusader Kings II: The Republic
  • Crusader Kings II: Rajas of India
  • Crusader Kings II: The Old Gods
  • Crusader Kings II: Legacy of Rome
  • Crusader Kings II: Charlemagne
The game is generally unstable, but I've not had reproducible crashes before my realm fell into civil war (going back to autosaves have always been enough to get past crashes). My first suspect "civil war crash" came shortly after the war started, forcing me to go back to a pre-CW autosave.

Now I have a few savegames from after the war's start. The game tends to crash on particular dates for every savegame. For example the attached save games usually crash on November 27 and January 24. Saving before the crash date somehow allows the game to continue past it, only to crash on a new "doomsday" date (within a few months in-game time). The november27 crash occurs if I start from older civil war save games as well though. Are any in-game states affected by saving the game?

System info:
3.0GHz P4 with 2Gb RAM, ATI Raden 5670 GPU with 1GB video RAM, and integrated Soundcard. ATI drivers updated upon purchase of the card about a month ago, but the soundcard drivers are quite old. Dxdiag attached.

Troubleshooting measures:
The savegames dont contain any noculturegroup units. I am running the game in windowed mode with multisampling and shadows turned off. Have tried deleting the files in the map/cache folder, but the only difference that made was that it takes far longer to start the game. Setting the master volume in settings.txt to -1 doesnt switch off the sound for some reason, but setting all the sound parameters to -1 did. Speedfan shows temperatures around 50C for the GPU and 33-40C for all other parts.
 

Attachments

  • dateofdoom5080124.rar
    691,1 KB · Views: 13
  • dateofdoom5071127.rar
    687,4 KB · Views: 12
  • DxDiag.txt
    45,1 KB · Views: 19
  • olddateofdoom5071127.rar
    685,4 KB · Views: 13
Last edited:
I had a similar problem when a civil war broke out in one of my games. I had no crashes prior to the civil war, but suddenly started getting a CTD every few moments.

Here's the link to my problem and how I solved it. Hope this helps!
 
I had a similar problem when a civil war broke out in one of my games. I had no crashes prior to the civil war, but suddenly started getting a CTD every few moments.

Here's the link to my problem and how I solved it. Hope this helps!

Thanks! Sadly those fixes wont do it. Clearing the map/cache files doesnt do anything, there is no "unborn" entries for the crash dates, and the temperatures are normal. All that's set to happen on these dates is unit training (of one unit for each date).
 
Hmmm, you mention unit training. Maybe this could be the cause:

I wanted to share one other trick I've had pretty consistent success with lately.

First, let's be clear about something - the game crashes A LOT and it is because it's inherently unstable. The trick I'm going to relate below wouldn't work this weren't the case... because it wouldn't exist.

So: If you are plagued by constant crashes to desktop on the same day over and over, try this trick:

1. Make note of the date your game crashes and try to save the game either on that very day or the day immediately before. If you're on slow mode, you usually have a few moments when the date changes before it will crash (my guess is this is because the game doesn't do all the actions for a given day until it is about to move on to the next day.) The point of trying to save as close as possible to the crash is so that the computer doesn't have the time to end up doing the same thing that I suspect causes the crash in the first place (you'll understand this comment in a minute.)

2. So, let's say you have a continuous crash on January 20, 592. Go to your save game folder and open your save with something like Notepad. The first bit of your save will look a little like this:
date="592.1.20" (this is the in-game date of the save)
player="ROM" (this is the country you are playing)

3. Now, use the editor's Find function to search for the very same date. In Notepad, just enter 592.1.20 in the search window and start looking for that date elsewhere in your save.

4. You may find that date in a section that looks like this toward the end of the save file:
military_construction=
{
start_date="592.1.20"
(then some other stuff)
If you scroll up a little bit you'll notice the section starts with a number/equals combination, like 201=, or in my specific save, 242=. This is the province code, and the section defines everything that's happened since the start of the game - who owns the province, how many times it's changed hands, and so on. The "military_construction" parameter dictates for any military unit currently under development, what its start and finish dates were, what type it is, etc.

5. Notice that word CURRENT up there? Well, you might just find TWO "military_construction" entries with the exact same start date in the exact same province. Scroll a little bit down from the first entry for your crash date. Do you see another military_construction entry with the same date? You DO??? Well, how can it be that two military units start getting built on the very same day in a single province? That's right... they can't. And I bet you can guess what happens when the game tries to build them both when it performs all the actions for that day (see #1 above). That's right... BOOOOM!

6. So, *if* this is what is causing your crash, you'll need to delete one of the military_construction entries so it's no longer duplicated. The entire entry looks more or less like this:
military_construction=
{
start_date="592.1.20"
date="592.3.16"
country="CAR"
type="horse_archers"
unit=
{
id=589752
type=4713
}
regiment=
{
id=589751
type=4713
}
}
DON'T DELETE TOO FEW OR TOO MANY BRACKETS or your save game structure will be corrupt, and trust me, you'll never figure out where it's broken.

7. Once you've deleted one of the two entries, make sure you clean up any white space or hanging lines, then save and re-run the game. It will probably pass the date now with no problems. Every time I have had a crashing save where I found these duplicate entries, deleting them eliminated the crash.

8. If it worked... rejoice while you can, because this crash can happen over and over again. There is nothing to stop the computer from generating duplicate military entries again. I assume that any time a computer-played country attempts to form a military unit, there is a risk of the issue happening. In other words, you may become very good at editing your save games. :p


Clearly there is a bug in the game that creates duplicate military entries for computer-played countries, but since we can't reasonably expect most bugs to be fixed, I thought I would post this "solution." Just please be careful with your save games. They can grow very big and very brittle.

Hope this helps some of you.

Credit for this goes to someone else (a user called blintz, I think, sorry!). Hope this helps. If not, you may have to wait for AndrewT to help you out, as I'm not very technical when it comes to Rome.
 
The savegames do have duplicate production queue entries, but removing them doesnt prevent the crash. The entries dont contain the crash date either.
 
Can you copy the whole ROME directory structure to a new place, then install the 2.31 beta over that and see if that helps?
 
I managed to play past the civil war yesterday by saving every 15 game days or so (obviously not a playable long term fix), and the game stayed unstable after the civil war was over, so it might have been wrong of me to blame the CW for the stability problem.

Can you copy the whole ROME directory structure to a new place, then install the 2.31 beta over that and see if that helps?

Done! It will take a while to see if it helps though, as I'll have to start over and the instability never was particularly bad in a fresh game.

EDIT: I tested firing up the old dateofdoom5080124 savegame just for laughs, and it crashed as expected. Not that the observation is worth much in the face of savegame compatibility issues.
 
Last edited:
Now I've done some testing with 2.31b. As before the game runs fine in the beginning, but after a few bigger wars (not civil wars) against Carthage and Macedonia it becomes unstable on the border of unplayable.

The attached savegame crashes on a fixed date (496.4.3), but most of my unstable savegames dont end up crashing on a particular date. Like before I could work around this crash by saving the game before the date of doom.

EDIT: added current system.log (rar-ed) and settings.txt to the attachments.
 

Attachments

  • dateofdoom496.4.3patched231b.rar
    560,2 KB · Views: 12
  • system.rar
    1,3 KB · Views: 14
  • settings.txt
    611 bytes · Views: 132
Last edited:
Try editing your setting.txt as follows:
refreshRate=60
fullScreen=yes # windowed mode is not supported
master_volume=-1 # will stop all sound
If that helps you can undo them one by one to see which change did it.
 
Tested a few times to see if the behaviour is reproducible, but the game still crashes. The only difference was that I two times out of five got slightly different crash dates (496.4.2 and 496.4.5).

On a side note the only effect of "master_volume=-1" on my system is to lock the sound setting sliders inside the game. It doesnt stop the sound (setting it to 0 mutes the sound though).
 
Last edited:
It's just that I noticed your sound drivers are really old, 2004. That aside I'm puzzled, while the game does have it's problems we don't have this issue you see with every game you play crashing as soon as there are large wars. You could also try updating your video driver http://game.amd.com/us-en/drivers_catalyst.aspx?p=xp/radeonx-xp - after doing that delete the files only in the Rome /map/cache/ folder.
 
The reason for the ancient sound drivers is that I have a crappy on-board sound card (the mobo and PC is from 2006 save the graphics card that I had to replace a few months ago), and the manufacturers' drivers caused issues with other games, so I reverted to some generic driver long ago.

I'll try updating the ATI drivers and switching off the sound completely with the device manager.

EDIT: I dont think the wars necessarily are the cause of the crashing, since the game doesnt crash during every war I fight. My initial suspicion of civil wars being the trigger came from the first two rounds of instability coming after the outbreak of civil wars. War isnt the only thing the unstable saves have in common either. They are also all about 30 in-game years "old", so the trigger could easily be something else in the accumulated history. For the first few decades the game runs fairly stable.
 
Last edited:
Updated the drivers and switched off the sound completely. Tested three times for reproducibility. The savegame still crashes, albeit not always on 496.4.3. The longest it managed to run without crashing was to 496.5.1.

I will test playing a peaceful game in some other scenario.
 
I've now been able to play far into several campaigns without crashing, which is a major relief.:)

The old (previously attached) savegame still crashes like a clockwork, which makes me pretty sure that whatever causes the crash is in the savegame rather than in my Windows or hardware.