Ticket #44730

Fix city_size limitations for units.ruleset

Date d'ouverture: 2022-05-31 03:53 Dernière mise à jour: 2022-06-03 23:34

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

Détails

A split of #44703 for all active branches.

Currently, city_size is lifted from non-positive values to 1 for units having "Settlers" flag. Obviously, it should be for units that can found cities that is for long a different category. Also, for them overflow of this value should be also fitted in (now, does not fail the application but breaks helptext and produces warnings).

EDIT: Tested the case. Underflow value emulates HQ9+ "+" operator and fails the ruleset to load. Overflow value takes the lower byte that may result in 0, then the city is actually deleted after creation. If we remove the "Settlers" flag from city builders, loads any values, for negative ones the lower byte goes to helptext but the city size is 1. Server complains only on bad unit type packet values. So yes, it needs to be fixed.

Ticket History (3/12 Histories)

2022-05-31 03:53 Updated by: ihnatus
  • New Ticket "Fix city_size limitations for units.ruleset" created
2022-05-31 04:15 Updated by: cazfi
Commentaire

Sounds like something that would still have a good chance to make it to 3.0.2 (in time). Can you make the patch relatively soon?

2022-05-31 04:59 Updated by: ihnatus
  • Details Updated
2022-05-31 05:02 Updated by: ihnatus
Commentaire

I'll try tomorrow.

2022-06-01 03:38 Updated by: ihnatus
Commentaire

Patch for d3f branches. The check was moved into postprocessing to access actions cache. I don't know what meant the assignment to 1 before setting ok = false, likely some ruledit autofix, but we can live without it. I'll put it back in master.

2022-06-01 09:36 Updated by: cazfi
Commentaire

S3_0 / S3_1 patch looks good (have not yet compiled or tested in)

The would do some changes to the master patch:
- Maybe rscompat_set_valid_value() function name should contain '_3_2' to indicate that it's something to clear out when the rscompat code is change to do 3.2 -> 3.3 update instead
- The rscompat update should be in the ruleset loading (ruleset.c), and the sanity check side should fail if the ruleset is not ok by then (no matter whether it was ok to begin with, or just fixed by the rscompat code)
- "(!compat->compat_mode || compat->version < RSFORMAT_3_2)" seems wrong (you probably mean to check for >= _3_2 and not < _3_2 (which means 3.1 in practice)), but you need to rework that part for the previous point anyway

2022-06-02 00:34 Updated by: cazfi
  • Propriétaire Update from (Aucun) to cazfi
  • Résolution Update from Aucun to Accepted
Commentaire

Sorry if you're just about to submit updated master patch, but as I'm not counting on it, I propose that at this point we push the S3_0 / S3_1 patch also to master (and we get the review period for that running immediately), and open a new ticket about further master changes.

2022-06-02 03:04 Updated by: ihnatus
Commentaire

Reply To cazfi

Sorry if you're just about to submit updated master patch, but as I'm not counting on it, I propose that at this point we push the S3_0 / S3_1 patch also to master (and we get the review period for that running immediately), and open a new ticket about further master changes.

Well, it would be right, and I don't have the patch ready now any way.

2022-06-03 23:32 Updated by: cazfi
Commentaire

Reply To cazfi

open a new ticket about further master changes.

-> #44747

2022-06-03 23:34 Updated by: cazfi
  • État Update from Ouvert to Atteints
  • Résolution Update from Accepted to Fixed

Modifier

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