• Our friends from AlphaCentauri2.info are in need of technical assistance. If you have experience with the LAMP stack and some hours to spare, please help them out and post here.

Bug Reports and Technical Issues

Oh, thanks for pointing that out. I usually have resource bubbles off, so that would explain the difference.
 
Yes, that was it. Fix to come shortly.
 
I didn't have resource icons on when I got the mouseover bug, I will play some games on the newest commit and see if I can trigger it again. This time with a save!
 
Please show me a save where the AI starts production of a unit that you consider excessive next turn. That is the best way of investigating this.
I almost forgot about this. Currently working on it; challenge is selecting one among so many possible turns to share. In other words, the purported effect is apparent for the length of a given civ's game. I'm gonna focus on England though.

Also, corresponding Unit AI transport seems to be stuck, similar to the prior problem with Settlers/Colonists that you were able to fix. By stuck I mean a transport will sit in port with MISSIONAI_PICKUP for an undetermined duration (NOTE: this seems to affect the Islander civs more than continentals; while Spain, or even more so the Netherlands, for example will be seen actively ferrying units across the oceans, England's Irish Conquerors get stuck in Dublin with empty transports in port). I'm also working on confirming a suspicion that under some conditions an AI civ will stop receiving Colonists when AFAIK they should still be, and in either case England doesn't get their first for quite some time following discovery of Exploration. The spawned English Galleons also frequently change roles to ASSAULT_SEA, stranding the spawned Settler and precluding further spawns (if I understand the system, iColonistsAlreadyGiven is active until Settler is consumed?) . Actually, this is probably what's happening rather than the Colonists now spawning at all as stated above. What's unclear is what threshold for ASSAULT_SEA transports England AI wants to meet before permitting a SETTLER_SEA, but it's quite a few, though as youre certainly aware this preference is subject to conditions, mainly war/peace. In games where England is at war when Colonist spawns occur (and this is most games because Reformation and/or Hundred Years Warring), it isnt uncommon for no overseas settlement to occur while the first Settler sits at home indefinitely. In contrast (and sorry to throw another element into this confusion) AI Spain tends to overfavor SETTLER_SEA Galleons, whatever that be worth. Finally, the following might be useful to know: if I only change a Galleon's role to SETTLER_SEA, it will revert to ASSAULT in between turns. If however, I both change role and load a settler and defender, it will retain role and immediately set sail.
 

Attachments

In the end I could only reproduce the same one I posted as a screenshot last night. If you start as the Byzantines in the 600 scenario and go into worldbuilder, this error pops up if you mouse over the marble tile in Egypt. This is the only consistent one I found. I think I only found it because I've been looking at civs in worldbuilder to see their new name maps.
 

Attachments

  • mouse over error.png
    mouse over error.png
    3.3 MB · Views: 7
  • mouse over error 2.png
    mouse over error 2.png
    4 MB · Views: 7
Addendum:
Save 1:1670s. England has 7 Galleons, all ASSAULT_SEA, all idle, two more in queue. Also Four settlers at home. To confirm, yes they do have city sites marked for settlement.

Save 2: 1701. At 9 Galleons, one finally retains SETTLER_SEA role and embarks settler and defender, both of which were built. No indication that AI ever received Colonist spawns. Also, they're headed for Australia, with area settler values in above 6000. Just for kicks and removed map vision from these tiles and the Galleon returned to post instead of heading to one of the earlier selected sites in the Americas with values between 1000-3500. EDIT: two turns later they started toward one of these sites.
 

Attachments

Moving a City in WB founds a new one on target tile instead along with Python error:
Traceback (most recent call last):

File "CvScreensInterface", line 623, in leftMouseDown

File "CvPlatyBuilderScreen", line 2308, in leftMouseDown

AttributeError: 'module' object has no attribute 'getName'
ERR: Python function leftMouseDown failed, module CvScreensInterface
 
The spawned English Galleons also frequently change roles to ASSAULT_SEA, stranding the spawned Settler and precluding further spawns (if I understand the system, iColonistsAlreadyGiven is active until Settler is consumed?) . Actually, this is probably what's happening rather than the Colonists now spawning at all as stated above. What's unclear is what threshold for ASSAULT_SEA transports England AI wants to meet before permitting a SETTLER_SEA, but it's quite a few, though as youre certainly aware this preference is subject to conditions, mainly war/peace.
As you observe below, I think the dynamic is more that the AI for some reason decides it does not need that many SETTLER_SEA units and converts them to ASSAULT_SEA instead. But I agree that it shouldn't.
In the end I could only reproduce the same one I posted as a screenshot last night. If you start as the Byzantines in the 600 scenario and go into worldbuilder, this error pops up if you mouse over the marble tile in Egypt. This is the only consistent one I found. I think I only found it because I've been looking at civs in worldbuilder to see their new name maps.
Have you updated? This is the error that is supposed to be fixed by "fixed city name encodings". Some city names with non-ASCII characters were accidentally left without unicode encoding, so the game was unable to display them.
 
Have you updated? This is the error that is supposed to be fixed by "fixed city name encodings". Some city names with non-ASCII characters were accidentally left without unicode encoding, so the game was unable to display them.
I was convinced I had, but apparently not. Sorry for the false alarm.
 
Back
Top Bottom