Bug Reports and Technical Issues

Nope. I think the bug has been there ever since the lose-contact feature was implemented. Time to fix the code! Currently it only takes units and cities into account when deciding whether to lose contact or not, culture-covered tile are excluded.
That code is already really inefficient with the deeply nested loops and everything. I'll try to come up with a better solution.
 
Nope. I think the bug has been there ever since the lose-contact feature was implemented. Time to fix the code! Currently it only takes units and cities into account when deciding whether to lose contact or not, culture-covered tile are excluded.

I often fortify a unit in another civs city and still sometimes lose contact and then have to move that unit to get it back.
 
I often fortify a unit in another civs city and still sometimes lose contact and then have to move that unit to get it back.

From my experience you never lose contact if you have their city in vision. I could be wrong though, but I think it's true most of time.
 
Ok this made my day :eek:

Spoiler :
attachment.php


Overflow in Boston.
Okay, that gave some additional info, more soon with the next commit message.
 
That code is already really inefficient with the deeply nested loops and everything. I'll try to come up with a better solution.
Okay, how about this: X and Y can only lose contact if X cannot see any tile Y controls and Y cannot see any tile X controls. It's possible to lose contact with units that see each other in foreign or unclaimed territory.

That should be easy to implement and could actually save turn times.
 
Re Post 307: This would be a very welcomed solution. For right now.
 
Okay, how about this: X and Y can only lose contact if X cannot see any tile Y controls and Y cannot see any tile X controls. It's possible to lose contact with units that see each other in foreign or unclaimed territory.

That should be easy to implement and could actually save turn times.

but you get contact back if either one of you moves? then that would be ok, imho
 
Are CTDs and overflow bug anyway related?

CTDs happen now in almost every 3000 BC and 600 AD Canada runs. Please try to load Canada yourself! From what I observe from autosave files right before CTDs they all share one thing: happening after Brazilian spawn, close to Canada spawn, and map is missing key cities like Montreal and Toronto. Can it be that game is checking to rename Toronto and there is none?
 
Are CTDs and overflow bug anyway related?
I don't think so, but it could be.

CTDs happen now in almost every 3000 BC and 600 AD Canada runs. Please try to load Canada yourself!
I did. Crashes happened sometimes but in less than a quarter of the runs.

From what I observe from autosave files right before CTDs they all share one thing: happening after Brazilian spawn, close to Canada spawn, and map is missing key cities like Montreal and Toronto.
That's the risk when playing earlier starts, and the reason why the 1700 AD scenario exists.

Can it be that game is checking to rename Toronto and there is none?
No, and something like that could at worst cause a Python exception.
 
Does Canada now flip St. John's?:eek: I thought we all were asking to flip everything in Canada on turn 3 except St. John's!
 
Sorry, stupid implementation.
 
I will, thanks.
 
Are CTDs and overflow bug anyway related?

CTDs happen now in almost every 3000 BC and 600 AD Canada runs. Please try to load Canada yourself! From what I observe from autosave files right before CTDs they all share one thing: happening after Brazilian spawn, close to Canada spawn, and map is missing key cities like Montreal and Toronto. Can it be that game is checking to rename Toronto and there is none?

My Congo game also crashed at around 1670AD, which put my slave trade testing to a halt.:mischief:
 
I'm confused about Madras. There's Madarasapatinam in the CNM with no origin and I have no idea how that name can ever came in the game. It's Chennai in India's settler map, Kanchipuram in Barbs.py

So does with "Simiyan hoton".
 
Back
Top Bottom