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

[Thunderbrd]

Getting some strange movement "bugs". Just captured a barb city and can not move any of the attacking units into the city Except the Unit that actually did the final battle. But can move the captured mil unit back in. The City has a GG that is "greyed" out. And I suspect this is the cause. Somehow the game "thinks" this GG is Invisible. And I do Not have that Option or any other CM Option On. City is Shabas NE of Ngapuhi. Should be centered upon opening save.

Savegame and Screenshot below. Game started with SVN 9070 and updated to 9078.

JosEPh

Yeah, interesting. I'll have to run some evaluations. However, it comes down to 'what happened' that allowed the GG to not be destroyed on entry. That seems to strike me as the first thing that went wrong.

He's not invisible since you do have visibility on him. I'm looking at a spot that may explain some of it. Will take some thinking. Usually this kind of rule change causes a bug elsewhere if not thought through well enough.

But I'm looking at some movement rule issues now so fixing this should be right in line with the current project.

 

[Thunderbrd]

Just updated to SVN 9084 and after Re-Calc and Non fatal warning about Celtic_Dun being removed clicked EoT and instant CTD, repeatable.

Previous save game in post above is before the SVN update. Both are using CIVPlayer8's new zzNewCivic set placed in My_Mods.

Save and MiniDump below.

JosEPh

Will take a look soon. Sadly, the minis not going to help much right now but I'll run the turn and see if I can catch the problem.

 

[JosEPh_II]

Will take a look soon. Sadly, the minis not going to help much right now but I'll run the turn and see if I can catch the problem.

Thank you. Probably don't say that to you enough do I. Grumpy that I am. Givin' you grief all the time!

JosEPh

 

[strategyonly]

Grumpy that I am. Givin' you grief all the time!

JosEPh

ahahahaha

 

[Thunderbrd]

Thank you. Probably don't say that to you enough do I. Grumpy that I am. Givin' you grief all the time!

JosEPh

lol... we're cool. No worries mate!

 

[Thunderbrd]

Getting some strange movement "bugs". Just captured a barb city and can not move any of the attacking units into the city Except the Unit that actually did the final battle. But can move the captured mil unit back in. The City has a GG that is "greyed" out. And I suspect this is the cause. Somehow the game "thinks" this GG is Invisible. And I do Not have that Option or any other CM Option On. City is Shabas NE of Ngapuhi. Should be centered upon opening save.

Savegame and Screenshot below. Game started with SVN 9070 and updated to 9078.

JosEPh

I think I called it right before I loaded it. I saw a logic flaw that explains why the general was still alive when the city was taken. Repaired that. In-game, I find the main problem is that the general is attackable but your units cannot move in because they have already attacked that round. Normally not a problem if the unit had been killed as it should've been.

Might be kinda cool though to give GPs their unitclass type in the <Capture> tag so that they would be capturable... Is there any reason we haven't done that?

Just updated to SVN 9084 and after Re-Calc and Non fatal warning about Celtic_Dun being removed clicked EoT and instant CTD, repeatable.

Previous save game in post above is before the SVN update. Both are using CIVPlayer8's new zzNewCivic set placed in My_Mods.

Save and MiniDump below.

JosEPh

Good catch. You must be playing with that 'requires complete kills' option... your game found a place where the number of cities of a player was a divisor and the player didn't have any cities so it attempted to divide by 0.

Fix pending to the SVN shortly.

 

[Dancing Hoskuld]

Might be kinda cool though to give GPs their unitclass type in the <Capture> tag so that they would be capturable... Is there any reason we haven't done that?

Yes because it is a really, really bad idea.


edit Capturing them as a unit that can only become a leader unit and can't be settled in a city is OK.

 

[Thunderbrd]

Yes because it is a really, really bad idea.


edit Capturing them as a unit that can only become a leader unit and can't be settled in a city is OK.

Just curious ... why do you think it's a bad idea? Seems like a wonderful wartime prize to me.

 

[Toffer90]

Yes because it is a really, really bad idea.


edit Capturing them as a unit that can only become a leader unit and can't be settled in a city is OK.

We could define a special group of unit called foreign great X that functions as lesser great persons. e.g. a foreign great artist would give only 50% of the culture that a normal one would... etc, etc.

 

[JosEPh_II]

T-brd wrote:

You must be playing with that 'requires complete kills' option...

Not that I can remember. As I don't like chasing down ships all over the world with that option.

This game is on an archipelago map. And I have just completed the circumnavigate the world thingy where you ships get an extra move. Although the game does not announce that anymore.

But glad you could fix it.

JosEPh

 

[JosEPh_II]

Yes because it is a really, really bad idea.


edit Capturing them as a unit that can only become a leader unit and can't be settled in a city is OK.

I thought once upon a time this last part Was possible. In fact I know it was back in the v24-27 version timeframes.

JosEPh

 

[Dancing Hoskuld]

This game is on an archipelago map. And I have just completed the circumnavigate the world thingy where you ships get an extra move. Although the game does not announce that anymore.

It is still announcing it to me but it often does not come up until all the other stuff has been announced and wont if you end turn before it has processed all the messages. It still shows in the turn log though.

 

[sunrisereader]

repeating ctd on next turn.

 

[strategyonly]

My troops were transported OUTside the enemies boundary AFTER i razed the city?? autosave in zip, i believe i turn before raze?

 

[Thunderbrd]

T-brd wrote:

Not that I can remember. As I don't like chasing down ships all over the world with that option.

This game is on an archipelago map. And I have just completed the circumnavigate the world thingy where you ships get an extra move. Although the game does not announce that anymore.

But glad you could fix it.

JosEPh

It might've been the order in which the player was eliminated may have allowed the code to continue to process that portion before said player was fully removed.

Fixed anyhow.

repeating ctd on next turn.

Will take a look right away.

My troops were transported OUTside the enemies boundary AFTER i razed the city?? autosave in zip, i believe i turn before raze? see pic 1

Interesting. Certainly worthy of investigation. I presume you ARE at war with said nation and you hadn't captured the city with an HN unit?

 

[Thunderbrd]

repeating ctd on next turn.

This again is an air unit having trouble with an animation. I think. There are some odd things going on with the unit data being reported by both the mini and the debug run. That said, I think the oddity comes from variable reporting being flawed by the crash itself, which is taking place in the exe after the mission is reported by the dll, which I BELIEVE (I'm not 1000% sure of this) is the point at which the animation is called for.

Also telling: the unit that just called for an animation appears to be... an ornithopter. Known crash bug I cannot personally fix. (But Toffer said he's taken note.)

 

[Toffer90]

repeating ctd on next turn.

Try turning off unit animations in main game option screen. It might get you past the crash point.

 

[Thunderbrd]

My troops were transported OUTside the enemies boundary AFTER i razed the city?? autosave in zip, i believe i turn before raze? see pic 1

Wow... that's very interesting. There's a big question in my mind as to whether this should be solved in the code or not. On one hand, it probably should be. On another hand, it could create a nasty complexity and perhaps some clashes of rules elsewhere.

See... this is actually quite legally taking place.

I noticed, as I came up and went to attack the city, that there is a rogue in the city. The rogue is a 3rd party. Not sure which player's rogue it is but I'm sure we can assume it to be barbarian.

The rogue can't defend the city nor would he try.

When your units, as a stack, attack and make a breakthrough into the city, they legally move in as it temporarily becomes your city. The rogue is immune to attack still because the city is still a city and he's got the ability to blend into the city.

However, as soon as the city is razed, a plot validity check takes place on all units on the plot. This then finds a rogue that, being visible to your forces, cannot co-habitate the plot with your forces. Units are moved in a sequence from that scenario until the scenario is legal for all units that remain. This means until the rogue itself has been moved due to his own inability to now share the space, or until your units have lost visibility on the rogue.

When this sort of thing happens, the units are sent to the nearest not only 'legal' space for them to be but the space must be either yours or unowned.

Now... looking at this, it's the plot itself that runs the legality check and does so impartially for the player's units involved. The order of the units checked therefore cannot really be rigged.

There are numerous ways to address the problem but I'm really not sure what the 'best' way would be. I could add a tag to improvements so that units with bBlendWithCity can have that effect work when they are on a destroyed city tile. (This would mean that such destroyed city tiles would always be an illogical (outside of this issue) haven for criminals... illogical because there is no crowd to blend into.)
Plus, this adds a new tag and more data use.

I could disable the legality check and allow the units to overlap in this sort of case (I'm strongly considering this since unit movements alone didn't create the situation but rather the choice to raze introducing the new illegality of space sharing... this could improve some other eventual problems that this illegality check may create.)
This might be the way to go but it's hard to guess what other side effects this might have elsewhere.

I could get much more complicated in building new code - which could create complexity based delay and there's so many possible ways to address it along these lines that it's very difficult to say what should be done exactly.

Then there's the option to do nothing and issue the warning that if you see a criminal in the city and you plan to raze the city, march only one unit in to make the final attack against the city (this helps to keep from disrupting the stack as only either the criminal(s) or the invading unit will then be made to jump to the nearest valid plot.)


It's ... tricky. And maybe I should wait for some comments before making up my mind on this.

 

[Toffer90]

I could disable the legality check and allow the units to overlap in this sort of case (I'm strongly considering this since unit movements alone didn't create the situation but rather the choice to raze introducing the new illegality of space sharing... this could improve some other eventual problems that this illegality check may create.)
This might be the way to go but it's hard to guess what other side effects this might have elsewhere.

I thought this check was already disabled because: Wouldn't the "see same tile visibility" modifier also cause similar scenarios?

 

[Thunderbrd]

I thought this check was already disabled because: Wouldn't the "see same tile visibility" modifier also cause similar scenarios?

It very well could. Good point. I don't think this 'generally' happens because the validation check isn't normally run after just a basic movement. The true invalidation of the plot they are on is the fact that the enemy culture floods in afterwards and the check is made DUE to the fact that the city has been razed. (or rather that the ownership changed)

So... yeah, I think simply disabling this check is probably the safest thing to do to harmonize with other recent game rule changes.

EDIT: Well... trying this it doesn't crash and works as intended. It's still a dangerous situation for the units that all moved in as a stack since now the rogue can ambush them but it makes more sense this way.