Ticket #47598

Calculate uncertain effect values

Open Date: 2023-03-19 05:13 Last Update: 2023-03-24 05:52

Reporter:
Owner:
(None)
Type:
Status:
Open
Component:
MileStone:
(None)
Priority:
5 - Medium
Severity:
5 - Medium
Resolution:
None
File:
2

Details

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.

Ticket History (3/14 Histories)

2023-03-19 05:13 Updated by: ihnatus
  • New Ticket "Calculate uncertain effect values" created
2023-03-19 05:22 Updated by: ihnatus
Comment

A patch for 3.2 branch, not tested for others. At least 3.0 needs another one.

2023-03-19 13:00 Updated by: cazfi
Comment

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?)

2023-03-19 20:08 Updated by: ihnatus
Comment

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.

2023-03-20 08:20 Updated by: cazfi
Comment

Especially since we're going to backport this to older branches, please do not use for-scope: "for (int i = ..)"

2023-03-20 08:33 Updated by: cazfi
Comment

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.

2023-03-21 01:48 Updated by: None
Comment

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.

2023-03-21 04:09 Updated by: cazfi
Comment

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.

2023-03-23 02:32 Updated by: ihnatus
Comment

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).

2023-03-23 03:33 Updated by: cazfi
Comment

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)

2023-03-24 05:28 Updated by: ihnatus
Comment

Ok, I amend the patch, do with it whatever you want.

2023-03-24 05:52 Updated by: cazfi

Edit

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login