Ticket #46029

Improve and split is_req_unchanging()

Date d'ouverture: 2022-11-03 06:10 Dernière mise à jour: 2022-11-19 20:48

Rapporteur:
Propriétaire:
Type:
État:
Atteints
Composant:
Priorité:
5 - moyen
Sévérité:
5 - moyen
Résolution:
Fixed
Fichier:
6

Détails

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

Ticket History (3/37 Histories)

2022-11-03 06:10 Updated by: ihnatus
  • New Ticket "Improve and split is_req_unchanging()" created
2022-11-03 06:33 Updated by: alienvalkyrie
Commentaire

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.

2022-11-03 14:55 Updated by: ihnatus
Commentaire

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:

  • Always unchanging
  • Unchanging if local range
  • Unchanging if not provided by ally
  • Once present, can't change
    • Surviving requirements can't change from present unless provided by an ally

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.

(Edited, 2022-11-03 15:09 Updated by: ihnatus)
2022-11-03 15:27 Updated by: cazfi
Commentaire

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.

2022-11-05 08:26 Updated by: ihnatus
  • File improve-is_req_unchanging.patch (File ID: 10747) is attached
2022-11-05 08:30 Updated by: ihnatus
Commentaire

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.

2022-11-05 08:32 Updated by: ihnatus
Commentaire

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.

2022-11-05 23:37 Updated by: ihnatus
  • File improve-is_req_unchanging.patch (File ID: 10747) is deleted
2022-11-05 23:55 Updated by: ihnatus
Commentaire

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.

2022-11-06 00:02 Updated by: ihnatus
  • File improve-is_req_unchanging.patch (File ID: 10768) is attached
2022-11-06 00:48 Updated by: ihnatus
  • File improve-is_req_unchanging.patch (File ID: 10768) is deleted
2022-11-06 00:50 Updated by: ihnatus
Commentaire

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.

2022-11-09 05:23 Updated by: ihnatus
  • File 3.0-improve-is_req_unchanging.patch (File ID: 10789) is attached
2022-11-09 05:24 Updated by: ihnatus
Commentaire

Published a 3.0 patch, much more lightweight. (Actually, some ideas from it seem not bad...) Do we need a special 3.1 patch?

2022-11-09 23:32 Updated by: ihnatus
  • File 3.0-improve-is_req_unchanging.patch (File ID: 10789) is deleted
2022-11-09 23:33 Updated by: ihnatus
Commentaire

Improved the 3.0 patch for rssanity.c. Yes, we need a 3.1 patch.

2022-11-10 05:47 Updated by: ihnatus
  • File 3.1-improve-is_req_unchanging.patch (File ID: 10794) is attached
2022-11-10 05:49 Updated by: ihnatus
  • File 3.1-improve-is_req_unchanging.patch (File ID: 10794) is deleted
2022-11-10 05:53 Updated by: ihnatus
  • File 3.1-improve-is_req_unchanging.patch (File ID: 10795) is attached
2022-11-10 07:41 Updated by: ihnatus
  • File 3.1-improve-is_req_unchanging.patch (File ID: 10795) is deleted
2022-11-10 07:42 Updated by: ihnatus
  • File 3.1-improve-is_req_unchanging.patch (File ID: 10796) is attached
2022-11-10 08:13 Updated by: ihnatus
  • File 3.1-improve-is_req_unchanging.patch (File ID: 10796) is deleted
2022-11-10 08:14 Updated by: ihnatus
  • File 3.1-improve-is_req_unchanging.patch (File ID: 10797) is attached
2022-11-10 08:17 Updated by: ihnatus
  • File 3.2-improve-is_req_unchanging.patch (File ID: 10798) is attached
2022-11-10 20:38 Updated by: ihnatus
  • File 3.0-improve-is_req_unchanging.patch (File ID: 10799) is attached
2022-11-10 21:19 Updated by: ihnatus
  • File 3.2-improve-is_req_unchanging.patch (File ID: 10798) is deleted
2022-11-10 21:20 Updated by: ihnatus
  • File 3.1-improve-is_req_unchanging.patch (File ID: 10797) is deleted
2022-11-10 21:20 Updated by: ihnatus
  • File 3.0-improve-is_req_unchanging.patch (File ID: 10799) is deleted
2022-11-10 21:22 Updated by: ihnatus
Commentaire

After a lot of fixing, patches for all targeted versions are supplied.

2022-11-12 21:28 Updated by: cazfi
  • Propriétaire Update from (Aucun) to cazfi
  • Résolution Update from Aucun to Accepted
2022-11-19 20:48 Updated by: cazfi
  • État Update from Ouvert to Atteints
  • Résolution Update from Accepted to Fixed

Attachment File List

Modifier

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