[We the People] Bug reporting

[Nightinggale]

Turns out the bishop is in the colony, but due to having lost the profession, it can't change profession from the domestic advisor and it's hidden in the colony screen, meaning it can't change profession there either. No idea how this happened, but the same can happen (rarely) if a fisherman is removed from a plot because of a pirate. I made a fix, which once every turn will look through all citizens and then kick out those without professions. This way when a unit vanishes, it will end up on the colony plot on the map the next time you click end turn. That's the best I can do without knowing what triggered this condition. The good news is that this fix will work on existing savegames.

The bad news is that autoplaying triggers this once in a while, meaning there is an underlying problem, which has yet to be found. More investigating is needed, but at least units will not get stuck in an idle and unreachable condition.

I'm aiming towards a new pre-release, but I need to fix a few things first. Hopefully it can be tomorrow.

But all the variables from "Learning by Doing" are correctly handled in the new Savegame Format, right?

Sure. The savegame format doesn't look like it is to blame for this. Not sure about learning by doing either. I highly suspect this to be an old bug, which people either haven't noticed because the units are hidden from the colony screen or that it's really hard to trigger. For all we know it's the first time ever that it triggered on an important unit like a bishop. People would care less for a missing free colonist.

 

[Taurus]

Here is another save with that bishop, the oldest one I have. Bishop is last in line in domestic advisor, so some turns after he came to colony. Hope it helps.

Another observation on that topic: in the most recent save (year 1613) in military advisor/unit view, you can see bishop in Jamestown (1st one) and bishop as priest in Jamestown (2nd one). So the first one is really stuck in between the worlds...

 

[raystuttgart]

I made a fix, which once every turn will look through all citizens and then kick out those without professions.

As discussed yesterday, that is a great "last safety net".
Players will at least notice right away and worst case "Unit being stuck in City Screen" is prevented.

The bad news is that autoplaying triggers this once in a while, meaning there is an underlying problem, which has yet to be found.

Ah ok, so our hope that it was an extremely rare bug was not fulfilled.
Yeah, these damn bugs sometimes really try their best to hide ...

Turns out the bishop is in the colony, but due to having lost the profession, it can't change profession from the domestic advisor and it's hidden in the colony screen, ...
More investigating is needed, but at least units will not get stuck in an idle and unreachable condition.

Yeah, this is strange.
Currently can not think of anything that could cause this ...

I'm aiming towards a new pre-release, but I need to fix a few things first. Hopefully it can be tomorrow.

I wish you a lot of patience and success.
Such bugs are annoying ...

I highly suspect this to be an old bug, which people either haven't noticed because the units are hidden from the colony screen or that it's really hard to trigger.

I really do not think so because if it triggered several times with Autoplays it would not have been missed by players.
Maybe once ok, but not a couple of times ...

 

[raystuttgart]

@Nightinggale

I think I might know what causes the OOS desync issues in MP Games.
It might be if the "New Random Seed on reload" Game Option is activated.

There was an issue with it (not working) in TAC and RaR which I had fixed.
This is many years ago however, so I am not absolutley sure anymore how I had done it.

If it is deactivated there might be no OOS desync issues anymore.
Would be interesting to check.

 

[Mr. ZorG]

interesting idea. I don't remember if there was such an option at the beginning of our games. I'll try to find out.

 

[Mr. ZorG]

clarification.

there is no such function "New Random Seed every turn". there is a function "New Random Seed on reload"

 

[raystuttgart]

there is no such function "New Random Seed every turn". there is a function "New Random Seed on reload"

That is the one I meant.
Would be interesting to figure out if OOS desyncs in MP games still occur if it is deactivated.

 

[Nightinggale]

That is the one I meant.
Would be interesting to figure out if OOS desyncs in MP games still occur if it is deactivated.

Considering that it's only active if enabled by game option and the game is not multiplayer, I would say this isn't the culprit. Besides that would fail instantly while in reality it takes several turns to trigger a desync.

 

[Vaeringjar]

So I occasionally play Civ hotseats, and I recall a previous version working fine (2.7?, don't remember), 2.8.2.1 is a gamebreaking issue though, any diplomatic interaction with another player results in a crash... I tried a bunch of things, single player works fine, vanilla col works fine (SP & hotseat), and it doesn't seem to matter what the diplo offer is, as soon as the offer is sent/clicked it crashes. (please let me know when this is solved)

Love the mod!

 

[Vaeringjar]

It's not technically a bug, but since there's no main suggestions thread I'll just put it here, that the FaireWeatherFX map script doesn't use the map sizes defined in CIV4WorldInfo.xml, having sizes hardcoded instead

IMO the map size for gigantic is too big, and huge too small. Gigantic is currently 4x the size of Huge. I've found 2x to be perfect for me, at ~ 90x140

 

[Nightinggale]

So I occasionally play Civ hotseats, and I recall a previous version working fine (2.7?, don't remember), 2.8.2.1 is a gamebreaking issue though, any diplomatic interaction with another player results in a crash... I tried a bunch of things, single player works fine, vanilla col works fine (SP & hotseat), and it doesn't seem to matter what the diplo offer is, as soon as the offer is sent/clicked it crashes. (please let me know when this is solved)

To be completely honest I think everybody had forgotten about hotseat. I wasn't even aware of anybody, who have tried it. It's certainly not something we test.

A savegame would be nice.

It's not technically a bug, but since there's no main suggestions thread I'll just put it here, that the FaireWeatherFX map script doesn't use the map sizes defined in CIV4WorldInfo.xml, having sizes hardcoded instead

IMO the map size for gigantic is too big, and huge too small. Gigantic is currently 4x the size of Huge. I've found 2x to be perfect for me, at ~ 90x140

Known issue. I wrote about it 2 years ago and mentioned it even earlier on the forum. So far nobody has fixed it because there has always been more important bugs to look into. I do agree that it's a bit annoying, but it's not game breaking.

 

[Vaeringjar]

Alright, here's a save I quickly assembled for the hotseat diplo crash. On my end reproducibility rate is 100%. Not zipped as it'd only save 5kb

 

[Nightinggale]

So I occasionally play Civ hotseats, and I recall a previous version working fine (2.7?, don't remember), 2.8.2.1 is a gamebreaking issue though, any diplomatic interaction with another player results in a crash... I tried a bunch of things, single player works fine, vanilla col works fine (SP & hotseat), and it doesn't seem to matter what the diplo offer is, as soon as the offer is sent/clicked it crashes. (please let me know when this is solved)

This is weird because it is crashing in the exe for no apparent reason meaning no hint on what is wrong. I tried giving gold to another player and to my knowledge, that's still vanilla code, but it still crashed. No idea what could cause that to happen.

 

[Vaeringjar]

It worked fine in the previous version I played, so there has got to be something causing it :/

 

[Nightinggale]

So I occasionally play Civ hotseats, and I recall a previous version working fine (2.7?, don't remember), 2.8.2.1 is a gamebreaking issue though, any diplomatic interaction with another player results in a crash... I tried a bunch of things, single player works fine, vanilla col works fine (SP & hotseat), and it doesn't seem to matter what the diplo offer is, as soon as the offer is sent/clicked it crashes. (please let me know when this is solved)

Fixed.

This took some digging. All I had to go on was that it worked at some point and not anymore. I did some trial and error to figure out precisely which git revision broke it, looked at the changed code and... well when you eliminate all the impossible, whatever remains must be the case regardless of how unlikely it is. Apparently it was because CvSavegameWriter did not have const for references to the arguments. This in turn meant CvDiploParameters:write was no longer const. The exe apparently requires that function to be const. First time I have ever seen a crash related to a missing const. Not just for WTP, but in programming in general.

TL DR: the bug is fixed. The cause is very unlikely, I had nothing to go on and spent hours looking for and finding the needle in the haystack.

 

[XSamatan]

Great news!!

 

[Vaeringjar]

Oh man I can imagine the potential time that took you. Wasn't expecting it to be worked on anytime soon, so massive thanks and respect mate, seriously.
Could the dll be uploaded as is, or do you have a rough estimate of the timing for the next update?

 

[Vaeringjar]

On a different topic, and not technically a bug either, but the AI seems to chop down every single tree in range and spam improvements regardless of it ever working them or not. So the AI achieves a very high food production, but its hammers/industry is tiny, which I assume also slows down overall development/efficiency in terms of buildings.

 

[Nightinggale]

Could the dll be uploaded as is, or do you have a rough estimate of the timing for the next update?

I uploaded a new version yesterday. It's in the thread, which is intended to be used for all 2.8.2.x feedback.

 

[f1rpo]

[...] This in turn meant CvDiploParameters:write was no longer const. The exe apparently requires that function to be const. [...]

[...] As useful as Dependency Walker is, it could not be used to catch this specific bug because DW doesn't look at const. [...]

(2nd quote is from the dev diary thread)

When I try this with the BtS EXE, then DW catches the error (screenshot attached). Just felt that I should point this out on the odd chance that there is some way to get it to work with the Col EXE as well. (I can't easily test that because I don't have a development environment set up for Col.)