Bug reports and technical issues

Use inline heuristic function. No significant difference.

Stop.
Premature optimization is the root of all evil.

profile
Spoiler :

Code:
>>> cProfile.run('h(1,1,70,70)')
heapq with heuristic
False
Time  2.40100002289
Visited  3435

         179835 function calls (179510 primitive calls) in 2.404 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    2.404    2.404 <string>:1(<module>)
       13    0.000    0.000    0.003    0.000 <string>:493(write)
       13    0.000    0.000    0.000    0.000 brine.py:107(_dump_str)
    78/13    0.000    0.000    0.001    0.000 brine.py:138(_dump_tuple)
   156/13    0.000    0.000    0.001    0.000 brine.py:161(_dump)
       13    0.000    0.000    0.002    0.000 brine.py:273(dump)
    65/13    0.000    0.000    0.000    0.000 brine.py:286(dumpable)
    91/52    0.000    0.000    0.000    0.000 brine.py:291(<genexpr>)
       65    0.000    0.000    0.000    0.000 brine.py:90(_dump_int)
       13    0.000    0.000    0.000    0.000 channel.py:42(send)
       13    0.000    0.000    0.002    0.000 protocol.py:149(_send)
       13    0.000    0.000    0.003    0.000 protocol.py:156(_send_request)
       13    0.000    0.000    0.000    0.000 protocol.py:170(_box)
       13    0.000    0.000    0.003    0.000 protocol.py:350(_async_request)
        1    0.000    0.000    0.001    0.001 r.py:18(show)
    22342    0.080    0.000    0.134    0.000 r.py:21(dist)
    30915    0.059    0.000    0.087    0.000 r.py:39(isValid)
        1    2.144    2.144    2.401    2.401 r.py:66(h)
        1    0.000    0.000    2.404    2.404 r.py:7(g)
       13    0.000    0.000    0.000    0.000 stream.py:112(write)
     3435    0.010    0.000    0.010    0.000 {_heapq.heappop}
     3434    0.005    0.000    0.005    0.000 {_heapq.heappush}
    44684    0.032    0.000    0.032    0.000 {abs}
    39/13    0.000    0.000    0.000    0.000 {all}
     3580    0.003    0.000    0.003    0.000 {len}
    22342    0.022    0.000    0.022    0.000 {max}
       13    0.000    0.000    0.000    0.000 {method 'acquire' of 'thread.lock' objects}
     3591    0.003    0.000    0.003    0.000 {method 'append' of 'list' objects}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
    31071    0.028    0.000    0.028    0.000 {method 'get' of 'dict' objects}
       13    0.000    0.000    0.000    0.000 {method 'join' of 'str' objects}
       31    0.000    0.000    0.000    0.000 {method 'pack' of 'Struct' objects}
       13    0.000    0.000    0.000    0.000 {method 'release' of 'thread.lock' objects}
       13    0.000    0.000    0.000    0.000 {method 'send' of '_socket.socket' objects}
    13740    0.016    0.000    0.016    0.000 {range}
        2    0.000    0.000    0.000    0.000 {time.time}


Spoiler :

Code:
>>> cProfile.run('f3(1,1,70,70)')
zahlen
False
Time  0.881999969482
Visited  3435

         66134 function calls (65809 primitive calls) in 0.883 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.883    0.883 <string>:1(<module>)
       13    0.000    0.000    0.003    0.000 <string>:493(write)
       13    0.000    0.000    0.000    0.000 brine.py:107(_dump_str)
    78/13    0.000    0.000    0.002    0.000 brine.py:138(_dump_tuple)
   156/13    0.001    0.000    0.002    0.000 brine.py:161(_dump)
       13    0.000    0.000    0.002    0.000 brine.py:273(dump)
    65/13    0.000    0.000    0.000    0.000 brine.py:286(dumpable)
    91/52    0.000    0.000    0.000    0.000 brine.py:291(<genexpr>)
       65    0.000    0.000    0.000    0.000 brine.py:90(_dump_int)
       13    0.000    0.000    0.000    0.000 channel.py:42(send)
       13    0.000    0.000    0.002    0.000 protocol.py:149(_send)
       13    0.000    0.000    0.003    0.000 protocol.py:156(_send_request)
       13    0.000    0.000    0.001    0.000 protocol.py:170(_box)
       13    0.000    0.000    0.003    0.000 protocol.py:350(_async_request)
        1    0.800    0.800    0.881    0.881 r.py:164(f3)
        1    0.000    0.000    0.001    0.001 r.py:18(show)
    27480    0.049    0.000    0.072    0.000 r.py:39(isValid)
        1    0.000    0.000    0.883    0.883 r.py:7(g)
       13    0.000    0.000    0.000    0.000 stream.py:112(write)
    39/13    0.000    0.000    0.000    0.000 {all}
      157    0.000    0.000    0.000    0.000 {len}
       13    0.000    0.000    0.000    0.000 {method 'acquire' of 'thread.lock' objects}
    10147    0.008    0.000    0.008    0.000 {method 'append' of 'list' objects}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
    27636    0.023    0.000    0.023    0.000 {method 'get' of 'dict' objects}
       13    0.000    0.000    0.000    0.000 {method 'join' of 'str' objects}
       44    0.000    0.000    0.000    0.000 {method 'pack' of 'Struct' objects}
       13    0.000    0.000    0.000    0.000 {method 'release' of 'thread.lock' objects}
       13    0.000    0.000    0.000    0.000 {method 'send' of '_socket.socket' objects}
        2    0.000    0.000    0.000    0.000 {time.time}
 
Thank you, Leo, and thank you, Lone Wolf. I'll check it. BTW, I have 4 GB of RAM, but I usually keep active more than a program, like Windows Media Player and Firefox, when I play this mod...
 
Finally I see.
A* is greedy best-first search. My implementation is a very simple breadth-first search, even not using disjoint set data structure.
When the target is disconnected, the problem is almost equivalent to traversing all nodes of an undirected graph.
In this case, it's expected my implementation is faster than A* armed with priority queue.

It is necessary to take into consideration that:
Usually you need to test multiple disconnected graphs before you find the connected one. But if you find one, you will no longer check the connectivity.
Therefore, IMHO, A* is not a best choice.
 
Just experienced a bugged Tamil start.

-There's Phytex at start : something related to C+++ but failed to get screenshot. Probably related to VD again.
-My Trireme can pass the Cape at South Africa with no problem. Is Tamil immune to Cape?
-I had CTD with 2 pop up.
One is about memory graphic card blablabla, which I presume my Laptop is not good enough anymore to play DoC :(
Another one is from C+++ response asking to terminate, similar to the previous pre-patch VD one.
 
Thank you, Leo, and thank you, Lone Wolf. I'll check it. BTW, I have 4 GB of RAM, but I usually keep active more than a program, like Windows Media Player and Firefox, when I play this mod...
I don't know, 4 GB sounds sufficient. I have no idea how much memory WMP uses, though. If it stores whole playlists in the memory it might cause trouble.

Finally I see.
A* is greedy best-first search. My implementation is a very simple breadth-first search, even not using disjoint set data structure.
When the target is disconnected, the problem is almost equivalent to traversing all nodes of an undirected graph.
In this case, it's expected my implementation is faster than A* armed with priority queue.

It is necessary to take into consideration that:
Usually you need to test multiple disconnected graphs before you find the connected one. But if you find one, you will no longer check the connectivity.
Therefore, IMHO, A* is not a best choice.
So, the only problem I see here if the graphs are disconnected, we're wasting time by maintaining the sorted heap, when we have to visit every node anyway, right? So it's mainly a question of whether we expect the connection to exist or not when it is checked. I wonder if it might be a better idea to work from the target nodes instead, since usually you will have plenty of railroads around Moscow, but only some at the Siberian coast if you've actually settled there, and then chances are high there's already a railroad connection.

Just experienced a bugged Tamil start.

-There's Phytex at start : something related to C+++ but failed to get screenshot. Probably related to VD again.
-My Trireme can pass the Cape at South Africa with no problem. Is Tamil immune to Cape?
-I had CTD with 2 pop up.
One is about memory graphic card blablabla, which I presume my Laptop is not good enough anymore to play DoC :(
Another one is from C+++ response asking to terminate, similar to the previous pre-patch VD one.
It's possible that all further C++ problems are related to the Python exception at the beginning. Do you have a save from that game (or the starting autosave)?

Did you have Compass when crossing the cape?
 
-I had CTD with 2 pop up.
One is about memory graphic card blablabla, which I presume my Laptop is not good enough anymore to play DoC :(
Another one is from C+++ response asking to terminate, similar to the previous pre-patch VD one.
I got the same CTDs. Will disabling VD help me with that?
 
So, the only problem I see here if the graphs are disconnected, we're wasting time by maintaining the sorted heap, when we have to visit every node anyway, right? So it's mainly a question of whether we expect the connection to exist or not when it is checked. I wonder if it might be a better idea to work from the target nodes instead, since usually you will have plenty of railroads around Moscow, but only some at the Siberian coast if you've actually settled there, and then chances are high there's already a railroad connection.

Good idea.
Moscow as target, Siberian coast as start.
Pros: need shorter time to figure it out especially when the graph is disconnected.
Cons: cannot check all starts simultaneously if they are not in the same connected component.

Thus I thought it's better.
 
You're right about the situation where the starts are disconnected, but again it's pretty unlikely to have a city there with lots of railroads that don't lead to Moscow, so it won't be that bad.
 
In victory.py, the deadline for Trans-Siberian railraod is 1930. It is not same as XML text.
Code:
	<TEXT>
		<Tag>TXT_KEY_UHV_RUS2</Tag>
		<English>Build the Trans-Siberian Railway by 1920 AD and be first to complete the Manhattan Project and Apollo Program</English>
		<French>Construire le programme Apollo avant 1950 ap. J.-C.</French>
		<German>Bauen Sie die transsibirische Eisenbahn bis 1920 n. Chr. und seien Sie die erste Zivilisation, die das Manhattan-Projekt und Apollo-Programm vervollst&#37592;digt</German>
		<Italian>Costruisci il Programma Apollo entro il 1950 d.C.</Italian>
		<Spanish>Concluir el Programa Apollo antes del 1950 d. C.</Spanish>
	</TEXT>
 
Yes I do. I'll sent it soon.

Yes I have Compass, but isn't Cape only cross-able by Astronomy?
I've rolled an Egypt start + WB and having Compass don't let me pass through?
 
You're right about the situation where the starts are disconnected, but again it's pretty unlikely to have a city there with lots of railroads that don't lead to Moscow, so it won't be that bad.

I agree with you. Even with lots of railroads, it won't be an issue.
I guess it might take less time to check the connectivity of a graph with more connected components.
I support using Siberian coast as starts.
 
I get this error when trying to open WB during my game (SVN+VD). Maybe this will help.
But I don't get the 1280 AD crash, so this bug doesn't seem to be in everyone's DoC.
I'm going to try a game without VD ( :sad: ) later today to look whether it is VD that strains my laptop (and others as well, of course).
 

Attachments

  • runtime.jpg
    runtime.jpg
    32.9 KB · Views: 50
Yes I do. I'll sent it soon.

Yes I have Compass, but isn't Cape only cross-able by Astronomy?
I've rolled an Egypt start + WB and having Compass don't let me pass through?
I'll check that.

I get this error when trying to open WB during my game (SVN+VD). Maybe this will help.
But I don't get the 1280 AD crash, so this bug doesn't seem to be in everyone's DoC.
I'm going to try a game without VD ( :sad: ) later today to look whether it is VD that strains my laptop (and others as well, of course).
The 1280 AD crash isn't deterministic, I've managed to play a full Japan game without problems recently for example.

And while the error message you posted is too unspecific to be helpful, at least we can be certain now that it isn't a memory problem. Do you have the save where WB causes that?
 
1280 is Turkish spawn date.
Go to Consts.py, search for

# civ birth dates

line, find the date 1280 below, change it to 2020 or something, and reload your save. See whether does the error occur.
 
Hey, got a problem.

I just installed civ 4, warlords & bts, with the 3.19 update, in my new mac computer. I copied my RFC DoC folder from my windows to my mac computer, but when I launch the mod (and it only happens with this mod), I get a ton of errors.

Some of them say things like: :
- Failed loading XML file xml\text\civ4gametext_seljuks.xml. [AspyrBuild/depot/Civ4/Source BTS/Win/FirePlace/FireWorks/Win32/FXml.cpp:140] Error parsing XML File -
File: xml\text\civ4gametext_seljuks.xml
Reason: (null)
Line: 0, 0
Source: (null)

And other errors say things such as:
- LoadXML call failed for xml\text\civ4gametext_leaderheads.xml. Current XML file is: xml\text\dynamicnames_ethiopia.xml

Any ideas of what I could do?
 
I just started an America game, but i CTD while loading (must have been around turn 60-70). Emperor, normal, most recent SVN and VD.
Maybe the bug's about VD...I'm going to try againg, this time without VD.
 
If it happened on turn 68, it's "normal", meaning that this CTD happens all the time. My Spanish game which was going very smoothly just got smashed to pieces by this bug on turn 68.

I noticed that it happened mostly (only ?) to European civs like France or Spain, as my game with Mali wasn't affected. But why would the Euro civs be affected by the Turkish spawn on that turn ? Or does it have something to do with the Turkish spawn at all ?
 
If it happened on turn 68, it's "normal", meaning that this CTD happens all the time. My Spanish game which was going very smoothly just got smashed to pieces by this bug on turn 68.

I noticed that it happened mostly (only ?) to European civs like France or Spain, as my game with Mali wasn't affected. But why would the Euro civs be affected by the Turkish spawn on that turn ? Or does it have something to do with the Turkish spawn at all ?
Well...first time I got this 1280 AD crash. Never happened before...
I'm updating the SVN, because I haven't figured out how to uninstall VD :sad:
 
Back
Top Bottom