Improve and split is_req_unchanging()
alienvalkyrie Something I'd been thinking about would be to have an enum that's a scale of unchanging-ness (though it probably wouldn't actually be a total order), with different AI and advisor code choosing its own cutoff points based on what they can respond to. On the unchanging end, there would be things like "cannot change without switching ruleset", "can only change pregame", "can only change by adjusting server settings", "can only change when players are added or removed (or die)" etc.; more toward the changing end would be stuff like "can only change when changing terrain", "can only change when adding or removing extras", as well as "can only change when losing or gaining tech other than through research", "can only change when gaining tech, including through research", and various other things.
I haven't looked much into what an exhaustive list of those would include, or how granular different things would have to be. But apart from allowing more accurate AI and advisor decisions, this could also be used in the future to optimize or cache requirements and effects.
Since we have a table of requirement testers now, can we put some other data on it? Just I am too thick to benchmark things. The table may be updated on ruleset load or game start (e.g. nothing may change terrain => terrain reqs are unchanging). Currently, unchanging requirements follow one or more of rules:
The function is_req_unchanging() now looks only at requirement itself but we often can get more specific results looking also at the context (and often even without performance loss). If I understand the semantics right, this function evaluates in assumption that every object that is on the context persists. Maybe we should indeed classify different things that can be changed by out of the game actions (e.g. AI level) but it should first find its use; some things (e.g. original owner) can be changed only by scripts, probably it should ever be configurable by scripts if they are considered unchanging.
Reply To ihnatus
Just I am too thick to benchmark things.
I don't believe the "thick" part, but I realize that setting up various testing environments takes a bit too much effort for just a single use. If you want some profiling done, I can run them if you provide the patch to test. Problem is that it can take significant time (even weeks) that I can reserve time for such runs.
A patch for master is made. Seems to work fine with one from #45982. I don't know, maybe fill calbacks in unchanging_condition fields? More flexibility but maybe less reliability, in one place we use the fact that REQUC_PRESENT has calculated if the req evaluates.
If one wants to try if this solution accelerates something. I have put out a snippet from my early development where I just update the switch.
Heck, supplied a wrong patch and lost the right one... Well, there were mistakes any way. Sending in few minutes the new one with unchanging callbacks in the table.
Some minor fixes. Remade REQUC_LOCAL to supply REQUCH_NO in the table instead of REQUCH_YES to be able to edit only enum field if the ruleset does not support road building.
Published a 3.0 patch, much more lightweight. (Actually, some ideas from it seem not bad...) Do we need a special 3.1 patch?
Improved the 3.0 patch for rssanity.c. Yes, we need a 3.1 patch.
After a lot of fixing, patches for all targeted versions are supplied.
Split from #45982 since it's a much wider problem. The "bug" part is, actually, terrain etc. "can't build" callbacks not called even if you provide a tile for testing; also, some requirements are not updated during development so some buildings are not shown on the full building list for creating a construction plan.
We should use more actual sense of the requirements in client, while AI (including human player advisors) should get a different function that also should be actualized where possible but hides things AI would be confused by. (Surely, such things are better to be reduced in the future.)