A patch for 3.2 branch, not tested for others. At least 3.0 needs another one.
Reply To ihnatus
A patch for 3.2 branch, not tested for others. At least 3.0 needs another one.
Are you sure you still want this to S3_0? (Is it worth the extra effort?)
Are you sure you still want this to S3_0? (Is it worth the extra effort?)
I hope the effort needed here is not very big. AI selection of defenders in port cities seems to be still not optimal.
Especially since we're going to backport this to older branches, please do not use for-scope: "for (int i = ..)"
I got some linking errors while producing libfreeciv.so, on meson based build. (Maybe related to the fact that it's a shared library, but haven't tested if autotools build of shared libfreeciv would fail too).
If you cannot reproduce or just want me to look at the issue in more detail, I can do that.
Reply To cazfi
I got some linking errors while producing libfreeciv.so, on meson based build. (Maybe related to the fact that it's a shared library, but haven't tested if autotools build of shared libfreeciv would fail too). If you cannot reproduce or just want me to look at the issue in more detail, I can do that.
Don't know what are you speaking about here, I am a bit out of synchronization with main branch and I don't build meson.
Reply To (Anonymous)
Reply To cazfi
I got some linking errors while producing libfreeciv.so, on meson based build. (Maybe related to the fact that it's a shared library, but haven't tested if autotools build of shared libfreeciv would fail too). If you cannot reproduce or just want me to look at the issue in more detail, I can do that.
Don't know what are you speaking about here
The problem seems to be simply that multiplier_effect_value() is 'inline' and not 'static inline' - as 'inline' is only a hint for the compiler, for some reason it had generated an actual call to the function, expected to be in "another" module. Just adding the 'static' there should resolve the issue.
Reply To cazfi
Especially since we're going to backport this to older branches, please do not use for-scope: "for (int i = ..)"
Hm, I thought for years it's a good practice... Well, let's respect C99-special persons here.
Just now I look at this patch and think it should not be applied where I have intended it to. Like, for AI purposes mathematical expectation-ish digit would tell more than the max and min, and it can be computed much easier and faster. So I probably abandon it until an application is found (like, a better estimation is requested for city map size or something).
Reply To ihnatus
Reply To cazfi
Especially since we're going to backport this to older branches, please do not use for-scope: "for (int i = ..)"
Hm, I thought for years it's a good practice... Well, let's respect C99-special persons here.
Up to S3_1 I make test builds with Ubuntu Trusty, and gcc there does not understand this scope. Pedantically speaking: Our CodingStyle prohibits it (but I think we should change that in main branch)
Just now I look at this patch and think it should not be applied where I have intended it to. Like, for AI purposes mathematical expectation-ish digit would tell more than the max and min, and it can be computed much easier and faster. So I probably abandon it until an application is found (like, a better estimation is requested for city map size or something).
Well, it would be great if rs_max_city_radius_sq() would give lower limit -> sdl2-client city dialog would scale better. Also, that function is used only in ruleset loading time (result is effectively cached)
Ok, I amend the patch, do with it whatever you want.
A split of #41781 to keep all features in separate patches from generic logical machinery. Currently, needed to estimate effects of units considered for building.
A recursive function will go through the uncertain requirements of the effects of given type to find the maximal and minimal combinations possible with provided context and limitations.