Single Player bugs and crashes v36 plus (SVN) - After the 24th of October 2015

Status
Not open for further replies.
Hi!

This is my first post here, but I read the forum for years. First I want to say the C2C is a very enjoyable mod even in its half completed shape. So thanks for the hard work!

Now some bug report:

I just upgraded to the latest SVN version (9018), and I get an XML error at the start of the game:

Tag: UNITCLASS_GUERILLA in info class was incorrect
Current XML file is: xml\Units\CulturalUnits_CIV4UnitInfos.xml


I also get occasionally the CTD at the end of the turns, but since it seems it is the known one in H&S and it is curable by a recalc, I don't think I should upload a savegame. But if you think you need one, or I find a new kind of bug, I will send one.


Two minor problems:

When I fight with a cobra, it sounds like I fight with a bear or something big, definitely not sound like a snake. Although IRL I never fought with a cobra so it might really sound like a bear. :D

The horseman unit fights with the wrong end of it's spear.
 
8920 my save game file after the "end of turn" comes out in windows. You can see all the settings when the save file is loaded


there is movement on this issue? last svn does not work :(
 

Attachments

  • Wowa BC-3976.7z
    6.6 MB · Views: 62
Latest SVN error

Looks like its spelled Guerrilla

Sorry. I must've been a little out of it last night to commit without testing. Ugh. Fixing now.
 
Sorry. I must've been a little out of it last night to commit without testing. Ugh. Fixing now.

ahahaha, we all get that way, now and then, no biggy, Have a Great Day!!!/.. SO;)
 
there is movement on this issue? last svn does not work :(
@T-brd and Wowa,

I took your save and finished the turn (units that still had actions they could do I did something with). I saved. Then I did the Re-Calc (I'm still using 9014). Once Re-Calc finished I saved again overwriting the save. I then Clicked the Red EoT button and after 30+ seconds CTD to desktop.

It did generate a MiniDump which Wowa failed to include in his post.

Both Save and minidump below.

This is a 21 player game with some Game set up options that may have conflicts. Such as Aggressive AI and Start as Minors Plus Raging Barbs. Wowa is using SM. He also has several Galleys that have more than 3 units on them.

@Wowa,
Please in the future give more details about your game and how you set it up. Also if it CTDs provide the MiniDump.dmp file it will generate in the Main BtS directory. Compress it with .zip, .rar, or 7z and upload it along with your save game.

Also no need to post in multiple threads about this issue. Post here where it will be seen. Thank you.

JosEPh
 
Thanks for looking at that Joe... I had assumed it was purely an issue due to the bad commit last night but it does look like it's deeper than that. I'll have to take a look later. Working this Saturday. Ugh.

btw:
Wowa is using SM. He also has several Galleys that have more than 3 units on them.
This is totally normal under SM. SM doesn't consider units to be a static volume to load onto ships. Now... I'm not going to say I don't think there are some bugs in that load system somewhere since I get asserts on it all over the place saying there's some inaccuracies. And yes, those need to be tracked down and resolved. But I AM saying that it's perfectly normal to be able to load a lot of units onto a galley provided the size and/or volume of the units being loaded is smaller than the norm. It's also just as possible to be unable to load one unit on a galley if it's size and/or volume is quite high.
 
Kp

There is a limit of 8192 for things like SelectionGroups.
Reusing old Id's is a bad idea, there could be old references to them stored somewhere and reusing them could lead to odd bugs.

There are a few ways to fix that but most of them could increase turn times and/or memory usage. But it has been a long time since that issue came up so it doesn't have a high priority.

Splitting barbs and animals should have been done long ago and i personally don't care if it breaks compatibility. You and me made changes which could cause odd behavior in old saves but luckily nobody really noticed it. That basically means compatibility should be broken more often to avoid odd bugs in old saves.

my English is bad. talking about animals and Barbarians in December 2015. I want to play, but I can not have the same problem as in December

Joseph II: Thunderbird is made a new topic about barbarians and animals, so I wrote there, too, just a month passed, and I can not continue my game
 
One weird thing i have noticed this before also??

The "Arsonist" and or Thief/Assassin, should be he showing up in this late of a game, i am in Ren Era . .
I looked at the Thief looks like the upgrade is Rogue, but it still is present when the Assassin is avail, and now the Assassin if avail this late in game??
 
my English is bad. talking about animals and Barbarians in December 2015. I want to play, but I can not have the same problem as in December

Joseph II: Thunderbird is made a new topic about barbarians and animals, so I wrote there, too, just a month passed, and I can not continue my game
If the problem is in fact a unit overload for barbs then the game will never be playable again and all we can do is keep games from having this problem in the future but will break all savegame compatibility with the current state of the mod when we do.

However, I've considered that you MAY be misdiagnosed with that game and a recalc with the current SVN MAY fix it. But you said you tried that right? I wanted to look at your game again anyhow because there was the distinct possibility that the problem might have been, like SO's game, misunderstood.

One weird thing i have noticed this before also??

The "Arsonist" and or Thief/Assassin, should be he showing up in this late of a game, i am in Ren Era . .
I looked at the Thief looks like the upgrade is Rogue, but it still is present when the Assassin is avail, and now the Assassin if avail this late in game??
From the way DH explained it, it shouldn't be necessary to give them a hard tech limit but rely instead on the availability of a better unit to be built. I don't mind at all that you can build thieves after you've reached the unit limit for Assassins and Rogues. It actually fits some of the theming I was hoping for since Thieves are really just pettier versions of Rogues and both Rogues and Thieves were historically concurrent with Assassins as well. Just because they are weaker units doesn't make them useless now either. They can still sneak into cities and get a lot of crime caused there or get some espionage or do all the other things they normally can. They just don't do it as well as the cutting edge units. But since they are cheaper, it can still be more beneficial to build them quick and perform missions with them that would potentially cause their demise (moreso after better units are available then during their time of being the best available).

Plus it helps to make the investigation mechanism feel more reasonable. Older criminal units are more likely to get caught - but since they are cheaper it's not as much of a loss.
 
If the unit is a limited nationality unit then you do need to give them a hard limit. "Arsonist" and its upgrades are. This is because if you don't then when you build all of the later ones the earlier ones become available.
 
Hi there,
I'm running into a consistent CTD on this game. Not sure if that's related to finishing United Nations but I finish the turn and the game crashes just when the next turn should start.
I've attached the savegame, minidump and logs - could someone please have a look?
 

Attachments

  • Chipper.zip
    4.2 MB · Views: 75
If the unit is a limited nationality unit then you do need to give them a hard limit. "Arsonist" and its upgrades are. This is because if you don't then when you build all of the later ones the earlier ones become available.

What if you want that effect though? You have the same thing arranged for merchants. I thought it would be a nice way to keep older criminals relevant.
 
Hi there,
I'm running into a consistent CTD on this game. Not sure if that's related to finishing United Nations but I finish the turn and the game crashes just when the next turn should start.
I've attached the savegame, minidump and logs - could someone please have a look?

I'll take a look. It wouldn't be terribly surprising to have a crash in UN votes given that I did some experimental stuff there that has otherwise gone untested since its difficult to test. I was trying to make it impossible to get too many votes made available for an integer to handle. So thanks for finding and reporting! Should have this fixed up rather shortly.
 
Hi there,
I'm running into a consistent CTD on this game. Not sure if that's related to finishing United Nations but I finish the turn and the game crashes just when the next turn should start.
I've attached the savegame, minidump and logs - could someone please have a look?

I was able to run through the next 3 turns without a crash. However, the minidump suggests that you may still have a corruption from the previously resolved gamestate problem that was recently repaired on the SVN version (but you MUST do a recalculation after updating to heal the bad gamestate(s).)

Alternatively, it looks like it could be a problem in an 'Active Defense' RevDCM option. (I'm not all that familiar with this option but it has to do with Air active defenses. The ACTUAL crash doesn't look to be happening in the code but in a Kernel so it may have to do with a bad animation on an air unit - seen this sort of thing previously.) It may be that I was able to run through because I didn't have the bug option set this way. If this is it, then it probably IS a graphic issue which may also explain why someone else was complaining that they couldn't use their air units without experiencing crashes - might be the same thing. So you may try to turn that option off and see if it gets through the turn.

The first time I found a similar issue I disabled the animation entirely but I really don't want to have to keep disabling more and more animations if I can avoid it.
 
there is movement on this issue? last svn does not work :(

Ok, upon re-reviewing this save, the issue is actually pretty clear. The game attempts to add a new selection group for a unit to join, which is a very routine action. It flat out fails.

Now... this is actually a little odd considering that there's an assert that should be thrown if it's going to perform this way and that assert doesn't happen. Nevertheless, the new selection group fails to initiate when it should've. There could be another answer to why this is that I would invite another coder like Alberts2 to take a look at.

But suffice it to say, it isn't quite the unit count limit so much as it is the selection group limit (the shells within which units are grouped together for both players (when units are grouped) and for AI to command) that has been breached (in theory.)

It's a long ways into the turn that this takes place.

Now... that said, some of this is just theory and in taking a second look I MUST wonder if it's not a bug somewhere in the upgrade process the unit is going through in relation to why it's coming back with a NULL value for the group shell it's trying to reform to place it into. May well be something that can yet be fixed but it's certainly mired in complexity and will take more time to investigate now that my eyes are a little more open to some things about this process.
 
I was able to run through the next 3 turns without a crash. However, the minidump suggests that you may still have a corruption from the previously resolved gamestate problem that was recently repaired on the SVN version (but you MUST do a recalculation after updating to heal the bad gamestate(s).)

Alternatively, it looks like it could be a problem in an 'Active Defense' RevDCM option. (I'm not all that familiar with this option but it has to do with Air active defenses. The ACTUAL crash doesn't look to be happening in the code but in a Kernel so it may have to do with a bad animation on an air unit - seen this sort of thing previously.) It may be that I was able to run through because I didn't have the bug option set this way. If this is it, then it probably IS a graphic issue which may also explain why someone else was complaining that they couldn't use their air units without experiencing crashes - might be the same thing. So you may try to turn that option off and see if it gets through the turn.

The first time I found a similar issue I disabled the animation entirely but I really don't want to have to keep disabling more and more animations if I can avoid it.

Thanks, I appreciate it.
"Recalculating" is that message when I load a game with a new SVN update, right? I always accept, and I also manually did one (Ctrl+shift+T, correct?) before sending the dump.
I'll definitely try to remove the active defense option and see what happens.
 
Ok, upon re-reviewing this save, the issue is actually pretty clear. The game attempts to add a new selection group for a unit to join, which is a very routine action. It flat out fails.

Now... this is actually a little odd considering that there's an assert that should be thrown if it's going to perform this way and that assert doesn't happen. Nevertheless, the new selection group fails to initiate when it should've. There could be another answer to why this is that I would invite another coder like Alberts2 to take a look at.

But suffice it to say, it isn't quite the unit count limit so much as it is the selection group limit (the shells within which units are grouped together for both players (when units are grouped) and for AI to command) that has been breached (in theory.)

It's a long ways into the turn that this takes place.

Now... that said, some of this is just theory and in taking a second look I MUST wonder if it's not a bug somewhere in the upgrade process the unit is going through in relation to why it's coming back with a NULL value for the group shell it's trying to reform to place it into. May well be something that can yet be fixed but it's certainly mired in complexity and will take more time to investigate now that my eyes are a little more open to some things about this process.

9021 is the same problem. I want to understand whether there is a possibility to continue the game or the error with the barbarians and animals can not be corrected without losing compatibility with earlier versions?
 
9021 is the same problem. I want to understand whether there is a possibility to continue the game or the error with the barbarians and animals can not be corrected without losing compatibility with earlier versions?

As it stands right now your game is on hold.

Since I've seen the game here's a suggestion for your next one till this one gets fixed or not.

Start the new one with about 5 or 6 less AI. Don't use Start as Minors with Raging Barbs or Aggressive AI as this puts the whole game in an instance War status and the AI (especially 20 of them (Barb plus 19 regular AI) will produce too many units too fast. These are just suggestions you do what you want to do as it is after all your game.

JosEPh :)
 
As it stands right now your game is on hold.

Since I've seen the game here's a suggestion for your next one till this one gets fixed or not.

Start the new one with about 5 or 6 less AI. Don't use Start as Minors with Raging Barbs or Aggressive AI as this puts the whole game in an instance War status and the AI (especially 20 of them (Barb plus 19 regular AI) will produce too many units too fast. These are just suggestions you do what you want to do as it is after all your game.

JosEPh :)

True. And a smaller mapsize may help too. However, I'm in the process of confirming for absolute certainty that it is an issue of overload. In this case, at least, it does attempt to reuse old group IDs that are no longer in use. So the limit is a matter of how many groups are in the game at one time. But that MAY not be all to the story here. We'll see.

EDIT: Interesting. It looks like the barbarians are experiencing a massive upgrade event. Every unit they have is upgrading at once and its overloading the number of groups they can have. I theorize that I may be able to resolve this by adding a parameter to the initialization of the unit that passes the selection group of the original unit along through the initialization process so that when it comes time for the newly initializing unit to pick up a new selection group it just adopts the old selection group instead. If this doesn't get fouled up by the AI that would be fantastic. I might be able to create a data wormhole though if it does so that before the new unit goes and defines a new selection group for itself, it would check to see if one is on the counter for it to adopt instead. This could be a bit trickier though.

Although not everything involving the Free List Trash Array that selection group ids are cycled from is completely clear to me, I think ultimately the problem isn't so much about an ultimate limit being reached as it is about the data flow itself. Too much is being initiated before the old clears away to leave room for the new. It's like you have 10 apples in a basked and for every apple you eat at the end of the day another apple replaces the one eaten. But if you eat all 10 in one day you run out. I'm not sure when the list recovers the old group ids that were trashed but I suspect it's not being recovered between upgrade orders so the problem is simply too many barbarian unit upgrades taking place at one time.

I might be able to fix this yet.
 
Status
Not open for further replies.
Top Bottom