alain_bkr alain_bkr alain_bkr Interesting. Is this civ2civ3 and S3_0?
This does explain how the AIs can (very occasionally) start and finish a 600 cost Wonder in a single turn.
Reply To alain_bkr
and this is very bad use of production capacity.
Not to mention the cost in gold or shields, per turn, of keeping that flock alive.
alain_bkr yes it is 3.0_beta1 , and default rules (civ2civ3)
alain_bkr)
alain_bkr i believe this behavior (AI tries to improve tradeoutes) may be linked to #42192 (AI wants gold)
alain_bkr I got this again, when i let my nation to the AI : I had a very comfortable situation, earning money under federation , and a huge tech lead, and huge production.
The AI changed to fundamentalism, and lacked money. Then it sold many buildings and build tons of fret (500 if i remember correctly).
I suppose something in the code choose to build caravan/fret in order to get money, which is mostly wrong.
In my tests with 3.0 and civ2civ3 this was also the main problem I found about the AI.
I have been testing a solution that seems to work, by using limited Unit_Slots = 2 per city, for the Caravan and other units problematic for the AI. In my games AI is also crazy about carry boats and workers. I have seen AIs with 10 cities and 300 workers.
I have also noticed that AI no longer use their cities to produce "Coinage", ever. This used to be a reasonable fallback for nations short of gold.
Actually, if I limit the amount of settlers available per city by using Unit_Slots, it appears this warning when a city cannot produce a settler, even when coinage should be still available:
Polish Kraków(61,52) (s4) {d0 u0 g0} Cannot even build a fallback (caravan/coinage/settlers). Fix the ruleset!
Reply To bard
this warning when a city cannot produce a settler, even when coinage should be still available: Polish Kraków(61,52) (s4) {d0 u0 g0} Cannot even build a fallback (caravan/coinage/settlers). Fix the ruleset!
This might hint that the problem is in that in fact for some reason AI does not want to build anything. In such a situation caravans are the very first fallback build target.
Reply To cazfi
Reply To bard
this warning when a city cannot produce a settler, even when coinage should be still available: Polish Kraków(61,52) (s4) {d0 u0 g0} Cannot even build a fallback (caravan/coinage/settlers). Fix the ruleset!
This might hint that the problem is in that in fact for some reason AI does not want to build anything. In such a situation caravans are the very first fallback build target.
If one uncomments "#define ADV_CHOICE_TRACK" on server/advisors/advchoice.h before compiling freeciv, logs should show whether AI builds caravans for money or just as fallback.
This might hint that the problem is in that in fact for some reason AI does not want to build anything. In such a situation caravans are the very first fallback build target.
Ok, I see.
If one uncomments "#define ADV_CHOICE_TRACK" on server/advisors/advchoice.h before compiling freeciv, logs should show whether AI builds caravans for money or just as fallback.
Thanks, sounds useful. But in both cases, it is problematic for civ2civ3 ruleset.
If it works as you describe, with Caravans being a fallback before Coinage, then Caravans with upkeep other than 0 are always a risk of bankruptcy for the AI. I guess it is mandatory either to remove the upkeep from Caravans, or to use limited city_slots.
Another thing that seems to help in my tests is to reduce the values of the trait "trader" in nations.ruleset
Reply To bard
This might hint that the problem is in that in fact for some reason AI does not want to build anything. In such a situation caravans are the very first fallback build target.
Ok, I see.
If one uncomments "#define ADV_CHOICE_TRACK" on server/advisors/advchoice.h before compiling freeciv, logs should show whether AI builds caravans for money or just as fallback.
Thanks, sounds useful. But in both cases, it is problematic for civ2civ3 ruleset. If it works as you describe, with Caravans being a fallback before Coinage, then Caravans with upkeep other than 0 are always a risk of bankruptcy for the AI. I guess it is mandatory either to remove the upkeep from Caravans, or to use limited city_slots. Another thing that seems to help in my tests is to reduce the values of the trait "trader" in nations.ruleset
Getting to fallbacks still sound like a code bug. Or is there are legitimate reason it either has zero want for coinage, or can't build it?
Reply To cazfi
Getting to fallbacks still sound like a code bug. Or is there are legitimate reason it either has zero want for coinage, or can't build it?
Especially in 3.0 and later where want is not an integer, so even less-than-one want value for coinage (which I guess can happen with some divisions) should select it if there's nothing else to build.
So I guess that either some critical part still handles want as integer, or some place erroneously overrides above-zero want with a zero want.
Reply To cazfi
Getting to fallbacks still sound like a code bug. Or is there are legitimate reason it either has zero want for coinage, or can't build it?
I'm not sure to fully understand what should be the correct (non-bug) behavior. I guess it is better if you can test it by yourself:
I uploaded a ruleset: default civ2civ3 from 3.0.6, where I simply added city_slots = 1 for every unit, and then limited Unit_Slots = 4 Any auto-save with those changes (even if Unit_Slots is increased to 20) will end showing the warning "Cannot even build a fallback (caravan/coinage/settlers). Fix the ruleset!" I uploaded a savegame where the warnings already happen.
Reply To cazfi
I got ruleup to work for civ2civ3_earth (#47657)
While ruleup didn't fail this time, the ruleset does not load. Have no time to confirm, but I think it's because nations.ruleset ruledit.embedded_nations list is not correct (not in sync with what is actually embedded - animals missing)
Reply To cazfi
Reply To bard
I guess it is better if you can test it by yourself
I try (to find the time). Will also be interesting to compare results between S3_0 and S3_1, now that I got ruleup to work for civ2civ3_earth (#47657)
Ok, but note that the ruleset and savegame uploaded here are not from "_earth" custom version. It is the default ruleset shipped with freeciv 3.0.6, where I edited a couple of files to recrete the issue.
I can do the same with S3_1 if useful.
Reply To bard
Reply To cazfi
I try (to find the time). Will also be interesting to compare results between S3_0 and S3_1, now that I got ruleup to work for civ2civ3_earth (#47657)
Ok, but note that the ruleset and savegame uploaded here are not from "_earth" custom version. It is the default ruleset shipped with freeciv 3.0.6, where I edited a couple of files to recrete the issue. I can do the same with S3_1 if useful.
For comparing how the *engine* changes affect this, it's better to just ruleup the very ruleset used in 3.0 to 3.1.
I've been told (so it's at least one person's opinion) that in 3.1, civ2civ3 works much better than (their) somewhat disappointing 3.0 experience.
Reply To bard
I uploaded a ruleset: default civ2civ3 from 3.0.6, where I simply added city_slots = 1 for every unit, and then limited Unit_Slots = 4 Any auto-save with those changes (even if Unit_Slots is increased to 20) will end showing the warning "Cannot even build a fallback (caravan/coinage/settlers). Fix the ruleset!" I uploaded a savegame where the warnings already happen.
When I perform the same test with civ2civ3 from S3_1 (add city_slots = 1 to every unit, and set Unit_Slots = 4), the result is the same:
"Cannot even build a fallback (caravan/coinage/settlers). Fix the ruleset!"
Reply To cazfi
If one uncomments "#define ADV_CHOICE_TRACK" on server/advisors/advchoice.h before compiling freeciv, logs should show whether AI builds caravans for money or just as fallback.
I'll try to debug S3_1 with this, to try to understand if what you said about coinage is happening:
Getting to fallbacks still sound like a code bug. Or is there are legitimate reason it either has zero want for coinage, or can't build it?
Especially in 3.0 and later where want is not an integer, so even less-than-one want value for coinage (which I guess can happen with some divisions) should select it if there's nothing else to build. So I guess that either some critical part still handles want as integer, or some place erroneously overrides above-zero want with a zero want.
Log from S3_1 with #define ADV_CHOICE_TRACK
The ruleset is not allowing the AI to build Caravan nor Settlers (due to limited city slots), but Coinage should be available.
I don't understand the backtrace, but that "null" makes me think that the AI adv_choice list is void.
1: Danish København(9,35) (s5) {d5 u58 g5} Cannot even build a fallback (caravan/coinage/settlers). Fix the ruleset!
3: [T090 - 2023/03/29 02:52:35] (null)Backtrace:
3: Backtrace:
3: [T090 - 2023/03/29 02:52:35] (null) 0: ./server/freeciv-server(backtrace_print+0x3b) [0x5608066b101b]
3: 0: ./server/freeciv-server(backtrace_print+0x3b) [0x5608066b101b]
3: [T090 - 2023/03/29 02:52:35] (null) 1: ./server/freeciv-server(vdo_log+0xad) [0x5608066b547d]
3: 1: ./server/freeciv-server(vdo_log+0xad) [0x5608066b547d]
3: [T090 - 2023/03/29 02:52:35] (null) 2: ./server/freeciv-server(do_log+0xb6) [0x5608066b5566]
3: 2: ./server/freeciv-server(do_log+0xb6) [0x5608066b5566]
3: [T090 - 2023/03/29 02:52:35] (null) 3: ./server/freeciv-server(real_city_log+0x29d) [0x5608064f32fd]
3: 3: ./server/freeciv-server(real_city_log+0x29d) [0x5608064f32fd]
3: [T090 - 2023/03/29 02:52:35] (null) 4: ./server/freeciv-server(dai_manage_cities+0x28e0) [0x56080657b990]
3: 4: ./server/freeciv-server(dai_manage_cities+0x28e0) [0x56080657b990]
3: [T090 - 2023/03/29 02:52:35] (null) 5: ./server/freeciv-server(dai_do_last_activities+0x100) [0x5608065644b0]
3: 5: ./server/freeciv-server(dai_do_last_activities+0x100) [0x5608065644b0]
3: [T090 - 2023/03/29 02:52:35] (null) 6: ./server/freeciv-server(srv_main+0xfed) [0x560806421dad]
3: 6: ./server/freeciv-server(srv_main+0xfed) [0x560806421dad]
3: [T090 - 2023/03/29 02:52:35] (null) 7: ./server/freeciv-server(main+0x365) [0x560806415695]
3: 7: ./server/freeciv-server(main+0x365) [0x560806415695]
3: [T090 - 2023/03/29 02:52:35] (null) 8: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f7606bb8083]
3: 8: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f7606bb8083]
3: [T090 - 2023/03/29 02:52:35] (null) 9: ./server/freeciv-server(_start+0x2e) [0x56080641638e]
3: 9: ./server/freeciv-server(_start+0x2e) [0x56080641638e]
Game saved as /home/davidf/.freeciv/saves/freeciv-T0091-Y-0250-auto.sav.xz
> 1: [T091 - 2023/03/29 02:52:36] in dai_city_choose_build() [daicity.c::303]: Danish København(9,35) (s5) {d6 u67 g6} Cannot even build a fallback (caravan/coinage/settlers). Fix the ruleset!
Now I see that the previous trace did not include the logs from advchoice.c
I enable debug when compiling: ./autogen.sh --enable-debug
I try to launch the game so it prints the debug logs: freeciv-gtk3.22 -d d:daicity:advchoice -l log.txt
But I have never been able to see such file related logs, except when I edit the .c file by changing the log priority to "log_error". I'd appreciate if you can tell me how can I see the debug logs, it'd help me a lot in future tests and bug reports too.
Reply To bard
Now I see that the previous trace did not include the logs from advchoice.c I enable debug when compiling: ./autogen.sh --enable-debug I try to launch the game so it prints the debug logs: freeciv-gtk3.22 -d d:daicity:advchoice -l log.txt But I have never been able to see such file related logs, except when I edit the .c file by changing the log priority to "log_error". I'd appreciate if you can tell me how can I see the debug logs, it'd help me a lot in future tests and bug reports too.
I don't use --debug level logs much, relying more on other debugging methods. I'll check if they work as expected.
In the above case it might be just that you're trying to log server side, but launch client.
Not really sure if what we've found since is the reason of the original caravans problem, but will treat this ticket like it i (i.e. repurpose this to fixing the now found code bug).
The reason coinage was given zero (or even negative) want on that savegame was that AI thought that building coinage (or; finishing it - it's probably bug too that coinage gets treated like it's going to get finished) would make it impossible for it to do "Help Wonder" action (and maybe others, this was the one that came first). That in turn was because the check if some action is possible now, and the check if something will be possible later, has some differences causing them to give different result when the results should have been identical (-> no change because of the coinage). The same low-level bug has likely been cause to many kinds of problems.
Reply To cazfi
The same low-level bug has likely been cause to many kinds of problems.
For this reason also S2_6 version attached. Though of course this conversely means also that there's a risk of all kinds of unexpected consequences.
Reply To cazfi
Not really sure if what we've found since is the reason of the original caravans problem, but will treat this ticket like it i (i.e. repurpose this to fixing the now found code bug).
I'm not sure either, but I also think they are related. I'll test your patch with S3_0 to try to confirm it.
The reason coinage was given zero (or even negative) want on that savegame was that AI thought that building coinage (or; finishing it - it's probably bug too that coinage gets treated like it's going to get finished) would make it impossible for it to do "Help Wonder" action (and maybe others, this was the one that came first). That in turn was because the check if some action is possible now, and the check if something will be possible later, has some differences causing them to give different result when the results should have been identical (-> no change because of the coinage). The same low-level bug has likely been cause to many kinds of problems.
Good catch. It sounds like a fix with big potential to improve the AI.
Though of course this conversely means also that there's a risk of all kinds of unexpected consequences.
Right, I'll test it a bit and I'll see if I can tell the difference while playing auto-games with civ2civ3 rules.
The AI in 2.6 was reasonably good playing with civ2civ3 rules. But 3.0 is the first time in freeciv that I think the AI is worse than previous version while playing with these rules. The crazy production of caravans is one of the main issues I notice in my tests. If this patch helps with that, it will surely improve 3.0, but I'm not sure about 2.6, I'll try to do some tests too.
Reply To bard
Reply To cazfi
Not really sure if what we've found since is the reason of the original caravans problem, but will treat this ticket like it i (i.e. repurpose this to fixing the now found code bug).
I'm not sure either, but I also think they are related. I'll test your patch with S3_0 to try to confirm it.
Please open a new ticket about further problems, even if they have similar symptoms. Let's keep this one about the identified issue (and its patch)
The AI in 2.6 was reasonably good playing with civ2civ3 rules. But 3.0 is the first time in freeciv that I think the AI is worse than previous version while playing with these rules. The crazy production of caravans is one of the main issues I notice in my tests. If this patch helps with that, it will surely improve 3.0, but I'm not sure about 2.6, I'll try to do some tests too.
The big difference between 2.6 and 3.0 is that former still had integer math with the wants, so anything below 1.0 rounded to zero, e.g., not to be built / done. In 3.0 wants below 1.0 really exist, for good (AI does not go idle when it actually should do something) and bad (unearthed bugs and balance issues).
I have been playing some AI auto-games with this patch on v3.0.6, and you were right this would have required 2 different tickets, because the problem about coinage is fixed, but there are still games where AI keeps building Caravans like crazy. I have opened a new ticket here #47776
Reply To cazfi
The big difference between 2.6 and 3.0 is that former still had integer math with the wants, so anything below 1.0 rounded to zero, e.g., not to be built / done. In 3.0 wants below 1.0 really exist, for good (AI does not go idle when it actually should do something) and bad (unearthed bugs and balance issues).
The patch does not improve the AI as much as I expected, it is hard to notice the difference, apart of some cities producing coinage from time to time. If I understood, in those cases, without the patch, the AI would be building caravans, so I guess the problem pointed by the op (alain_bkr) has improved some way.
If there are new "unearthed bugs and balance issues" I did not notice them in my tests (5-6 auto-games with civ2civ3 rules).
I have seen some AIs building Supermarkets and farms, something very rare to see without the patch, I'm not sure if the patch helped here. In the other hand, I still see idle cities (building coinage), that have not build a Factory that would give 6 or more shields (with upkeep of 3 gold), so there is still room to improve the AI in this aspect.
But I must say that the way AI build city improvements is far better than it used to be in previous versions (AI never built any factory or power plant in 2.5). It is the production of units what causes more problems to the AI with civ2civ3 rules. I plan to open a ticket about that too.
Reply To cazfi
Reply To bard
I try to launch the game so it prints the debug logs: freeciv-gtk3.22 -d d:daicity:advchoice -l log.txt
In the above case it might be just that you're trying to log server side, but launch client.
I've checked that part, and indeed client request only the specific log level from the server, it does not pass extra definitions needed at debug level. It's also not trivial to implement (well, there's a relatively easy way to implement a hack, but I'm still trying to invent a better way). So, for the time being, to get debug level logs from the server one needs to launch server separately.
Reply To cazfi
I've checked that part, and indeed client request only the specific log level from the server, it does not pass extra definitions needed at debug level. It's also not trivial to implement (well, there's a relatively easy way to implement a hack, but I'm still trying to invent a better way). So, for the time being, to get debug level logs from the server one needs to launch server separately.
Thank you. I didn't answered earlier because I wanted to test it properly, and I have been unable to get it working until now.
You are right that my mistake this time was that I was requesting the server log from the client, but in the past I had tested it launching the server separately with no success either. My problem seems that I was filtering the file name as if it was a string search that would match any result containing the string (as described in freeciv README):
./fcser -d d:ai -l log.txt
I was expecting this to print all logs from any file with the string "ai", but in my tests no logs appear this way. However it does work if I write the full name of the file (including the .c):
./fcser -d d:daicity.c -l log.txt
The second problem in my failed tests was that I was not getting any debug log from the file advchoice, even when I uncommented from advchoice.h the line: #define ADV_CHOICE_TRACK
After recompiling, I still can't see any log from this file (even if I don't filter the logs, by using ./fcser -d d -l log.txt). This part is not so important, I guess I did something wrong, but I do know c programming, and it is sad when I can't get working this kind of simple things.
Reply To bard
After recompiling, I still can't see any log from this file (even if I don't filter the logs, by using ./fcser -d d -l log.txt). This part is not so important, I guess I did something wrong, but I do know c programming, and it is sad when I can't get working this kind of simple things.
My fault. I thought (and instructed you accordingly) that we have the logging in place, and enabled by that macro. In reality that macro enables just the framework, so one can easily add the logging ( call to adv_choice_log_info() ) where ever they want.
Reply To cazfi
Reply To bard
After recompiling, I still can't see any log from this file (even if I don't filter the logs, by using ./fcser -d d -l log.txt). This part is not so important, I guess I did something wrong, but I do know c programming, and it is sad when I can't get working this kind of simple things.
My fault. I thought (and instructed you accordingly) that we have the logging in place, and enabled by that macro. In reality that macro enables just the framework, so one can easily add the logging ( call to adv_choice_log_info() ) where ever they want.
So let's have it documented -> #47785
I noticed that AI can produce lots of caravan, which are not use :
The AI keeps trying to improve already very good trade route (+5 or more), and this is very bad use of production capacity.
I estimate that caravan production could stop (for traderoutes) when all cities have 1 traderoute , and maybe consider building a second one 50 turn later , but NEVER improve traderoute that gives +4 or more.