Single Player bugs and crashes v38 plus (SVN) - After the 20th of February 2018

[raxo2222]

Yes, most mapscripts define the map sizes differently.

Well it should be standarized, so actual amount of tiles never go that different.
Standard sized map for example have actual area of Small on one map script and Large on other map script.

Shape may be different, but area shouldn't differ that much between different map scripts, so they are effectively other sized map.

Duel: 40*24 = 960
Tiny: 52*32 = 1664
Small: 64*40 = 2560
Standard: 84*52 = 4368
Large: 104*64 = 6656
Huge: 128*80 = 10 240
Giant: 160*100 = 16 000
Gigantic: 200*120 = 24 000

 

[Yudishtira]

Looked into this. I still can't find anywhere that explains it.

But there's nothing that would explain boats in particular having any unusual benefit that land hunters might not. Not that I could see. There still COULD be. I just can't find it after reviewing all theories I could think of. Sometimes a perfect save scenario can illuminate a problem I keep overlooking.

I'd definitely need a save with instructions that shows/replicates a Ruffian fighting a Barbarian. I'd love to see this so I can debug it.

Here's a ship v toucan save. There is a Deceres 2SE of the capital and a toucan 1 more to the SE. When I ran it I got 8.44XP. Size Matters definitely on. Fight or Flight also afaik.

They don't withdraw from land hunters all that often either - not as often as in the previous versions I've played. But they never withdraw from any naval unit - by which I mean outrigger/galley/war galley/trireme/quinquereme/deceres

I have no barbs atm, so I can't help you with the ruffian v barb issue any time soon. Although I will look to see if my 'historical' hard saves are any help.

 

[Toffer90]

Well it should be standarized, so actual amount of tiles never go that different.
Standard sized map for example have actual area of Small on one map script and Large on other map script.

Shape may be different, but area shouldn't differ that much between different map scripts, so they are effectively other sized map.

Duel: 40*24 = 960
Tiny: 52*32 = 1664
Small: 64*40 = 2560
Standard: 84*52 = 4368
Large: 104*64 = 6656
Huge: 128*80 = 10 240
Giant: 160*100 = 16 000
Gigantic: 200*120 = 24 000

Go right ahead and standardize/normalize them, but don't you dare change the world mapscript, It's mine, all miiiine. ^^

 

[JosEPh_II]

What about Galactic and later era? In this and later eras increment gets bigger again.
That is month and day should be stopped displaying after 2200 year too.

Agree with this as a condition for using #1.

Does this cause more code? I would not think that it does but not sure.

 

[JosEPh_II]

Go right ahead and standardize/normalize them, but don't you dare change the world mapscript, It's mine, all miiiine. ^^

Agree here too. I've really grown to like the world map script. Job well done that I hope continues to get refinements. One caveat, please never make Old world start default. And Thank you Toffer for the C2C_World map.

 

[Yudishtira]

I'd definitely need a save with instructions that shows/replicates a Ruffian fighting a Barbarian. I'd love to see this so I can debug it.

And I found one... Barb city Bantu is on the second island to the north of my continent. There are two bandit riders on the ships adjacent to it. They can enter the city ok, but if they try to enter the tile west of the city, there is combat. And the odds are not given beforehand.

 

[Toffer90]

Agree with this as a condition for using #1.

Does this cause more code? I would not think that it does but not sure.

Adding the upper limit of 2200 AD is only one line of code and has a positive impact on performance as there will then be less turns where the dll has to be called from python to run its 60 lines of code 4 times every second. ^^
So that frequent python to dll interaction will then only happen between the year 1800 and 2199 AD

The transition\communication\interaction between python language and c++ language causes a significant delay that may be equivalent to 200 python lines of simple calculations and statements.

Edit: The upper limit is now added to the SVN.

 

[raxo2222]

Go right ahead and standardize/normalize them, but don't you dare change the world mapscript, It's mine, all miiiine. ^^

I looked and your and other map size definitions.

def getGridSize(argsList):
    grid_sizes = {
## Mini-Map Aspect Ratio Changed to 1.5
##                        Perhaps change aspect ratio to:
##                                                            1.75,    or 2? Original 1.647540984
        WorldSizeTypes.WORLDSIZE_DUEL:        (15, 10),    # (07, 04) (16, 08)        (13, 08)
        WorldSizeTypes.WORLDSIZE_TINY:        (21, 14),    # (14, 08) (20, 10)        (18, 11)
        WorldSizeTypes.WORLDSIZE_SMALL:        (27, 18),    # (21, 12) (24, 12)        (23, 14)
        WorldSizeTypes.WORLDSIZE_STANDARD:    (30, 20),    # (28, 16) (28, 14)        (28, 17)
        WorldSizeTypes.WORLDSIZE_LARGE:        (33, 22),    # (35, 20) (32, 16)        (33, 20)
        WorldSizeTypes.WORLDSIZE_HUGE:        (36, 24),    # (42, 24) (38, 19)        (38, 23)
        6:                                    (39, 26),    # (49, 28) (42, 21)        (43, 26)
        7:                                    (42, 28)    # (56, 32) (48, 24)        (46, 28)
    }
    if (argsList[0] == -1): # (-1,) is passed to function on loads
            return []
    [eWorldSize] = argsList
    return grid_sizes[eWorldSize]

Why there is no giant or gigantic map size modifiers?
And how this 6: or 7: are even working here?

Interestingly Pangaea intentionally makes map one step smaller (Pangaea Standard is actually Small)

 

[Toffer90]

I looked and your and other map size definitions.

def getGridSize(argsList):
    grid_sizes = {
## Mini-Map Aspect Ratio Changed to 1.5
##                        Perhaps change aspect ratio to:
##                                                            1.75,    or 2? Original 1.647540984
        WorldSizeTypes.WORLDSIZE_DUEL:        (15, 10),    # (07, 04) (16, 08)        (13, 08)
        WorldSizeTypes.WORLDSIZE_TINY:        (21, 14),    # (14, 08) (20, 10)        (18, 11)
        WorldSizeTypes.WORLDSIZE_SMALL:        (27, 18),    # (21, 12) (24, 12)        (23, 14)
        WorldSizeTypes.WORLDSIZE_STANDARD:    (30, 20),    # (28, 16) (28, 14)        (28, 17)
        WorldSizeTypes.WORLDSIZE_LARGE:        (33, 22),    # (35, 20) (32, 16)        (33, 20)
        WorldSizeTypes.WORLDSIZE_HUGE:        (36, 24),    # (42, 24) (38, 19)        (38, 23)
        6:                                    (39, 26),    # (49, 28) (42, 21)        (43, 26)
        7:                                    (42, 28)    # (56, 32) (48, 24)        (46, 28)
    }
    if (argsList[0] == -1): # (-1,) is passed to function on loads
            return []
    [eWorldSize] = argsList
    return grid_sizes[eWorldSize]

Why there is no giant or gigantic map size modifiers?
And how this 6: or 7: are even working here?

6 is Giant
7 is Gigantic

It could just as well be changed to:

0:      (15, 10),    # (07, 04) (16, 08)        (13, 08)
1:      (21, 14),    # (14, 08) (20, 10)        (18, 11)
2:      (27, 18),    # (21, 12) (24, 12)        (23, 14)
3:      (30, 20),    # (28, 16) (28, 14)        (28, 17)
4:      (33, 22),    # (35, 20) (32, 16)        (33, 20)
5:      (36, 24),    # (42, 24) (38, 19)        (38, 23)
6:      (39, 26),    # (49, 28) (42, 21)        (43, 26)
7:      (42, 28)     # (56, 32) (48, 24)        (46, 28)

Giant and gigantic are not present in the dll code that define the enumerator:

    python::enum_<WorldSizeTypes>("WorldSizeTypes")
        .value("NO_WORLDSIZE", NO_WORLDSIZE)
        .value("WORLDSIZE_DUEL", WORLDSIZE_DUEL)
        .value("WORLDSIZE_TINY", WORLDSIZE_TINY)
        .value("WORLDSIZE_SMALL", WORLDSIZE_SMALL)
        .value("WORLDSIZE_STANDARD", WORLDSIZE_STANDARD)
        .value("WORLDSIZE_LARGE", WORLDSIZE_LARGE)
        .value("WORLDSIZE_HUGE", WORLDSIZE_HUGE)
        .value("NUM_WORLDSIZE_TYPES", NUM_WORLDSIZE_TYPES)
        ;

NO_WORLDSIZE = -1
NUM_WORLDSIZE_TYPES = 6

 

[raxo2222]

6 is Giant
7 is Gigantic

It could just as well be changed to:

0:      (15, 10),    # (07, 04) (16, 08)        (13, 08)
1:      (21, 14),    # (14, 08) (20, 10)        (18, 11)
2:      (27, 18),    # (21, 12) (24, 12)        (23, 14)
3:      (30, 20),    # (28, 16) (28, 14)        (28, 17)
4:      (33, 22),    # (35, 20) (32, 16)        (33, 20)
5:      (36, 24),    # (42, 24) (38, 19)        (38, 23)
6:      (39, 26),    # (49, 28) (42, 21)        (43, 26)
7:      (42, 28)     # (56, 32) (48, 24)        (46, 28)

Giant and gigantic are not present in the dll code that define the enumerator:

    python::enum_<WorldSizeTypes>("WorldSizeTypes")
        .value("NO_WORLDSIZE", NO_WORLDSIZE)
        .value("WORLDSIZE_DUEL", WORLDSIZE_DUEL)
        .value("WORLDSIZE_TINY", WORLDSIZE_TINY)
        .value("WORLDSIZE_SMALL", WORLDSIZE_SMALL)
        .value("WORLDSIZE_STANDARD", WORLDSIZE_STANDARD)
        .value("WORLDSIZE_LARGE", WORLDSIZE_LARGE)
        .value("WORLDSIZE_HUGE", WORLDSIZE_HUGE)
        .value("NUM_WORLDSIZE_TYPES", NUM_WORLDSIZE_TYPES)
        ;

NO_WORLDSIZE = -1
NUM_WORLDSIZE_TYPES = 6

Interesting.

So this is legacy reason - someone who added Giant/Gigantic sizes didn't knew how to DLL, and this DLL enumerator never got updated as there was no need for this anyway.

 

[Toffer90]

Interesting.

So this is legacy reason - someone who added Giant/Gigantic sizes didn't knew how to DLL.

The enumerators are convenient in that one can add in lower values or new values in between old ones without other code shifting what they are referencing.
e.g. If a piece of code is supposed to only be run when WorldSizeTypes.WORLDSIZE_SMALL is the map size used,

Then it won't matter how many new worldsizes that are smaller than WorldSizeTypes.WORLDSIZE_SMALL is added to the game as the value of WorldSizeTypes.WORLDSIZE_SMALL will simply become one larger for every size added below it.

But if the code is set to be run every time the third mapsize in the xml definition is used then it will run for smaller and smaller map sizes for each smaller mapsizes that are added below the third one.
Then you will have to manually go to every code that reference the third mapsize in the xml and increment it by one for each smaller map size that has been added.
So let's say there's a 1000 places in the code you need to do this then you will quickly realize that it would have been better to use an enumerator that gives a name to each xml entry that stays the same regardless of how the xml get changed.

The map size enumerator is quite unimportant though, it is not used many times in code and it is very rare that new map sizes are added or get removed.
​

python::enum_<YieldTypes>("YieldTypes")

.value("NO_YIELD", NO_YIELD)
.value("YIELD_FOOD", YIELD_FOOD)
.value("YIELD_PRODUCTION", YIELD_PRODUCTION)
.value("YIELD_COMMERCE", YIELD_COMMERCE)
.value("NUM_YIELD_TYPES", NUM_YIELD_TYPES)
;​

These enumerators are used all the time in code and they represent the position they have in the xml they belong to.
So if there is a piece of code that says:

if yield == YieldTypes.YIELD_PRODUCTION: # 1

Do something important that is very related to production​

The numerical value of YieldTypes.YIELD_PRODUCTION is 1, so:

if yield == 1: # YIELD_PRODUCTION according to the xml order

Do something important that is very related to production
​

Would work just as well until.... a modder one day decides to add a new type of yield and for some reason decides that it should be at the top of the xml as it makes more sense to order them that way.
python::enum_<YieldTypes>("YieldTypes")

.value("NO_YIELD", NO_YIELD)
.value("YIELD_X", YIELD_X)
.value("YIELD_FOOD", YIELD_FOOD)
.value("YIELD_PRODUCTION", YIELD_PRODUCTION)
.value("YIELD_COMMERCE", YIELD_COMMERCE)
.value("NUM_YIELD_TYPES", NUM_YIELD_TYPES)
;​

Then all code that reference YieldTypes.YIELD_PRODUCTION would automatically change to represent the value 2 instead of 1.
If the enumerator had not been used in code then you would get something like this:

if yield == 1: # YIELD_FOOD according to the xml order (should be changed to the number 2 to represent production)

Do something important that is very related to production​

But if the enumerator is used in code:

if yield == YieldTypes.YIELD_PRODUCTION: # 2 (The referencing of the correct object solves itself)

Do something important that is very related to production
​

That explanation might be hard to follow, but with a bit of patience you should be able to understand enumerator usage in programming quite well from it.

 

[Thunderbrd]

Here's a ship v toucan save. There is a Deceres 2SE of the capital and a toucan 1 more to the SE. When I ran it I got 8.44XP. Size Matters definitely on. Fight or Flight also afaik.

They don't withdraw from land hunters all that often either - not as often as in the previous versions I've played. But they never withdraw from any naval unit - by which I mean outrigger/galley/war galley/trireme/quinquereme/deceres

I have no barbs atm, so I can't help you with the ruffian v barb issue any time soon. Although I will look to see if my 'historical' hard saves are any help.

I'll take a look, thanks. Now that hunters have more stealth strike capabilities, the means to take down birds improves a lot as often one good hit in battle is enough so if they can take them out during the stealth strike rounds, the birds can't try to withdraw, which improves the likelihood of success a lot for hunters in more recent versions.

And I found one... Barb city Bantu is on the second island to the north of my continent. There are two bandit riders on the ships adjacent to it. They can enter the city ok, but if they try to enter the tile west of the city, there is combat. And the odds are not given beforehand.

This kind of bug erodes the soul because ya just KNOW you're likely going to introduce a different one to try to fix it but I'm happy to take a look and see if I can resolve it.

I just got my new computer in so give me a bit to get it all up and running properly first.

 

[Thukew]

Playing on SVN 10293. Just entered Modern Era in a game that was started a few dozen revision #s ago.
--National X Smelters have all been renamed "Not near a city X Smelter." This includes both built and unbuilt ones. Other "National" buildings (Zoo and Railroad Museum, for example) are unchanged.
--The Congress of Vienna (which I own) issue-selection dialog box shows that I have negative several billion votes to apply to whatever issues I'm being prompted to select for voting. It seems to apply the correct number to the actual vote tally, though.
--Researching Industrialism removed my access to Sails, which disabled all of my Shipwrights. I don't have any available buildings to build that that produce sails. I can trade for them as a workaround.

 

[Konrad Klar]

SVN 10299

The "champion" event sometimes tries to give a Leadership promotion to gatherer, that is unable to receive the promotion.

 

[Yudishtira]

Funerary Services (in Classical) replaces Modern Embalmer, which is at Chemistry how many eras later I don't know. It looks intentional so how does that work?

 

[Yudishtira]

Playing on SVN 10293. Just entered Modern Era in a game that was started a few dozen revision #s ago.
--National X Smelters have all been renamed "Not near a city X Smelter." This includes both built and unbuilt ones. Other "National" buildings (Zoo and Railroad Museum, for example) are unchanged.
--The Congress of Vienna (which I own) issue-selection dialog box shows that I have negative several billion votes to apply to whatever issues I'm being prompted to select for voting. It seems to apply the correct number to the actual vote tally, though.
--Researching Industrialism removed my access to Sails, which disabled all of my Shipwrights. I don't have any available buildings to build that that produce sails. I can trade for them as a workaround.

At Assembly Line (apparently) you get the Sail Factory, but it requires a Factory, so that might be why it's not in your build list.

As for the others, well the smelter change was very deliberate, although if you think it seems pretty silly, I'd agree. The Congress I can't help you with, except to confirm that I have seen such a bug in the past.

 

[raxo2222]

Funerary Services (in Classical) replaces Modern Embalmer, which is at Chemistry how many eras later I don't know. It looks intentional so how does that work?

I wasn't revising replacement chain integrity, I guess its replacement chain bug here.
I'll remove this buggy replacement.

It appears it was only such case, I guess I changed it in regular buildings but not in module

--Researching Industrialism removed my access to Sails, which disabled all of my Shipwrights. I don't have any available buildings to build that that produce sails. I can trade for them as a workaround.

Ease with beelining

You should build factory, this mod still has traps for beeliners.
Only Shipwright building uses Sails, I guess I can move Sail Worker's obsoletion to Coast Guard.

I guess original designer thought players don't beeline or build all buildings or something like that.
Or that they kept not beelining and building everything

 

[Thunderbrd]

Playing on SVN 10293. Just entered Modern Era in a game that was started a few dozen revision #s ago.
--National X Smelters have all been renamed "Not near a city X Smelter." This includes both built and unbuilt ones. Other "National" buildings (Zoo and Railroad Museum, for example) are unchanged.
--The Congress of Vienna (which I own) issue-selection dialog box shows that I have negative several billion votes to apply to whatever issues I'm being prompted to select for voting. It seems to apply the correct number to the actual vote tally, though.
--Researching Industrialism removed my access to Sails, which disabled all of my Shipwrights. I don't have any available buildings to build that that produce sails. I can trade for them as a workaround.

1) Is this looking like a bug somehow?
2)Interesting. Not sure where to find that but I'll try to keep it in mind if I run across it.
3)This does need some addressing.

 

[raxo2222]

1) Is this looking like a bug somehow?
3)This does need some addressing.

As for 1. @Dancing Hoskuld had plans for those National resource producers.

As for 3. I already fixed it on my side: Sail makers now obsoletes at same tech as Shipwright - Coast Guard.
Now I'm waiting for comments on ordinance changes, so I can commit things at once.

 

[Thunderbrd]

As for 1. @Dancing Hoskuld had plans for those National resource producers.

I know. I just think the naming on that is terrible and I find it amusing that it's being reported as a bug. I REALLY do not understand the point of these buildings being required to be where the resources aren't in radius.

As for 3. I already fixed it on my side: Sail makers now obsoletes at same tech as Shipwright - Coast Guard.

Cool. It sounded like something should be done to smooth the transition a bit. Glad to hear you addressed it.