Bug Reports and Technical Issues

[Leoreth]

Okay, that definitely seems wrong. Can you share that save?

 

[Fresol]

Okay, that definitely seems wrong. Can you share that save?

Here you go.

 

[Fresol]

The Alt+R (build road to) function no longer works if you can build both railway and highway. The labourers will just stay on one tile building railway and highway alternatively.

 

[Thonnas]

So, been playing the 1.15 RC, and decided to start up a game as England. Using the 600 AD start, the city screens are broken. No buildings or specialist displays on the sides and no buildings displayed in the lower part. All other games I have played have been fine, and the 1700 start seems to work fine for England. I haven't tried the ancient start. If this is not easily reproducible, I will get screen shots and logs. Let me know.

 

[Leoreth]

Thanks, are you also using any modules, in particular Varietas Delectat?

 

[Thonnas]

Yes, this was using all modules, I tried the version without, and it worked fine. I ran another installation of the mod with modules and got the same issue. I do get a number of the file naming errors with varietas delctat.

 

[Leoreth]

Alright, then that's your issue. I'm currently working on the VD module, and fixing these errors is part of the agenda. I recommend playing without VD until the fix is up.

 

[Bernd-das-Brot]

May be a bug regarding slaves. I (Netherlands with colonialism civic) can not use bought slaves to build plantages. See save.

Or is there another hidden prerequisit in addition to colonialism and in colony (how is that definded? Non-home continent?)

 

[Leoreth]

Without looking at the save, it needs to be the New World specifically (the filename suggests Manila). Will look into it later.

 

[Akbarthegreat]

Got this exception a few turns before winning the UHV with Egypt. This is the pre release 1.15 version, I used the "Install DoC 1.15 Release Candidate.exe" to install it.

Spoiler :

 

[Leoreth]

This should be fixed if you download the installer again.

 

[Steb]

There is definitely something wrong. In this particular situation, Montgomery was my first great general and No Name was my second ever, and I know for a fact that there were more available names in the list. In the same game, I also got both John Lennon and George Handel in the Industrial era (should be Global and pre-Industrial, respectively); they were my only Great Artists and there are available names in the Industrial era list. I suspected the Great People manager might be confused as to what is the current era, but then even if it thought I was in the Global era, there were other names besides Lennon to choose from before picking Handel.

So there's something weird in an unclear, inconsistent way. I've been noticing that as well from GP born in other civilizations, in all my recent games, without being able to put a finger on the problem.

(I'll try to get the save, but I'm leaving for vacation very soon so I may not be able to for a couple of weeks)

I have investigated this and I think I have found three problems in GreatPeople.py.

The first is in setup(). When creating the list lGreatPeople, the program removes the era numbers (iMedieval, iRenaissance, etc.) that are in the dictionary, but puts the positions of these numbers in the list lOffset as if the era numbers were still in. For instance, if the dictionary has [GP1, GP2, iMedieval, GP3, iRenaissance, GP4, iIndustrial, GP5, GP6], then lGreatPeople will contain [GP1, GP2, GP3, GP4, GP5, GP6], but the Renaissance offset in lOffset will be 4, which corresponds to the Industrial era GP5 in lGreatPeople. This will result in miscategorization of great people of the later eras.

One solution is to...offset the offsets according to the number of era numbers removed from the list. Something like this (capital letters used for emphasis in the 3 lines I added/changed):

def setup():
    for iCiv in dGreatPeople.keys():
        for iType in dGreatPeople[iCiv].keys():
            lEntries = dGreatPeople[iCiv][iType]
            iERAS_SO_FAR = 0 
            for i in range(len(lEntries)):
                entry = lEntries[i]
                if entry in range(iNumEras): lOffsets[iCiv][lTypes.index(iType)][entry] = i-iERAS_SO_FAR
                else: lGreatPeople[iCiv][lTypes.index(iType)].append(entry)
              
            lCurrentOffsets = lOffsets[iCiv][lTypes.index(iType)]
            for i in range(1, len(lCurrentOffsets)):
                if lCurrentOffsets[i] < lCurrentOffsets[i-1]: lCurrentOffsets[i] = lCurrentOffsets[i-1]
              
            lCurrentOffsets[iDigital] = len(lEntries)-iERAS_SO_FAR
              
    print lGreatPeople

(There might be a more elegant solution, but my Python skills are what they are.)

The second problem is in the last line of getEraNames(). It currently is:

return lBefore[:-iSpread] + lAfter

which causes the earliest names to be returned. For instance, no civ has any names in the Digital era, so when a GP is born it will be picked from e.g. the Medieval names if you're France instead of the Global era ones. Perhaps this is intended, but my guess is that getting the names from the era(s) immediately before the current one is more desirable. For this, write:

return lBefore[-iSpread:] + lAfter

Also in getEraNames(), the last problem may be intended behavior, but I think it works poorly. Initially, I assumed that the intended behavior is that if you're in Era X, you will necessarily get a GP from Era X if there is at least one in the list. However, from what you said and from the code, I realize that it is not "at least one", but some other value. That value seems to be iEra+2:

iSpread = max(iNextOffset - iOffset, iEra+2)

So if I'm getting this right, the spread (which is the number of names the program can choose from), is either the number of names in the current era, or, if that's not enough, the number of the era + 2. But the latter may result in high numbers in the later eras. iGlobal = 5, so unless there are 7 names in the era (which is the case for virtually no civ) the game can choose from earlier eras, possibly resulting in actual Global era names being diluted in the pool. Since iDigital = 6, and there are never any names in the Digital era, and many civilizations have less than 8 names in any given type, Digital era GP can be picked from almost any era. Is there a rationale for iEra+2? Wouldn't a flat number (e.g. 2 or 3) work better?

I have tested my changes only in a simplified and standalone version of GreatPeople.py, not in-game. I can test them at some point next week probably. One thing I don't know about is the effect of removing GP names from the pool because they are born.

(If you want, I can make these changes into a pull request. I can also combine that with my next batch of suggested GP names—I have quite a lot actually. But I'm guessing it's easiest for you to just make the changes yourself.)

 

[Leoreth]

Thank you for the feedback, I have to look into the code in its entirety before I can give a response though.

 

[Leoreth]

Alright, I looked at the code and you are correct. I have pushed fixes for the first two mentioned issues, and have limited the the minimal value for the spread variable to 5. By the way, already used names are tracked separately in the DLL (see CvGame::isGreatPersonBorn()). Only after the list of possible names is filtered using that function, the final list of available names is returned with the desired length.

 

[pichulo_]

used installer 1.15 with modules, CTD

 

[Jipsu]

Git version 23.9.2017:

From the Civilopedia hints I read that

• you need exploration to vassalise far-away civs. This doesn't apply to Portuguese in the New World. Does it apply to anyone anymore?
• Pagan Temples should/used to change into organized religion temples, but that doesn't happen anymore.

If Mayans settle Panama or Venezuela religion spreads to the Americas before Old World finds it. Not sure what happens if Incas try it.

Aztec spawn bugged out in a way that suggests spawn blocking still works. I controlled Puh/Tenochtitlan as the Mayans and refused to let it flip. Their armies spawned in the north and their two settlers either SW of Puh or, if there was no garrison, in Puh. In the former case the Settlers wouldn't move unless Aztecs managed to flip one of my Settlers to build a city. The armies would refuse to come within the first ring of Puh, even if it was empty. If the Settlers spawned in Puh they would move to found Tuitan and the resulting culture would allow Aztecs to capture Puh.

Spoiler Pics :

As an anecdote, it was also interesting to see Catholicism being born in 1400's, probably because both Greece and Rome converted to Judaism. Led to Orthodoxy being pretty dominant.

Edit: Cogs should require Seafaring, Shipbuilding and/or Navigation.

 

[soul-breathing]

Maybe a bug when I make war with Mexico as China, 1700 scenerio, Emperor, Epic

I settle a city in California and declare war to Mexico, when my troops go into Maxico territory, some of them join to Mexico, just as New civ flipping. But it's 1886ad now.

Still flipping in 1890ad.

Spoiler :

Spoiler :

 

[Fresol]

Maybe a bug when I make war with Mexico as China, 1700 scenerio, Emperor, Epic

I settle a city in California and declare war to Mexico, when my troops go into Maxico territory, some of them join to Mexico, just as New civ flipping. But it's 1886ad now.

Still flipping in 1890ad.

Spoiler :

Spoiler :

Troop desertion lasts some turns(10 under normal game speed). When did you settle the city?

 

[soul-breathing]

Troop desertion lasts some turns(10 under normal game speed). When did you settle the city?

But Mexico spawns in 1810ad, now it's 1886, it's about 30-40 turns later.

 

[Leoreth]

Very odd, Mexico should never have this kind of unit flip.