Ticket #42993

Wonders needlessly hard-coded to override the building upkeep specified in the ruleset.

Open Date: 2021-10-07 19:09 Last Update: 2024-08-25 07:10

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

Details

This bug was probably never found because the vast majority of wonders have 0 upkeep.

However, rulesets allow the ruleset designer to set the upkeep for any building or wonder. There is no need for the server to hard-code 0 upkeep for wonders to override the ruleset values.

file: city.js function: int city_improvement_upkeep(const struct city *pcity, const struct impr_type *b)

blamed lines:

if (is_wonder(b)) {
return 0;
}

Ticket History (3/13 Histories)

2021-10-07 19:09 Updated by: lexxie9952
  • New Ticket "Wonders needlessly hard-coded to override the building upkeep specified in the ruleset." created
2021-10-07 22:22 Updated by: cazfi
Comment

When ever I've seen that part of the code, I've assumed that it's there for never ending to a situation where a Wonder would get sold for lack of funds. I've meant to check if server could nowadays handle selling of a wonder so that we could lift this restriction that wonders have no upkeep. It probably could - wonders just provide effects, and as those same effects could come from other sources more likely to disappear, the server must be prepared for their disappearance. The check here is ancient - predates introduction of the effects system in freeciv-2.0, probably even ruleset provided buildings data.

2021-10-07 22:38 Updated by: cazfi
Comment

As a quick test I removed the check, set Colossus upkeep to 50 so it would drain my balance to negative in a couple of turns, started game, founded my first city, set Colossus there in the editor, did "Turn Done" twice -> client shows negative balance for me, and server crashed.

2021-10-08 00:58 Updated by: ihnatus
Comment

Well, to allow wonders to have upkeep we should either make them sellable or handle negative treasury. I think we should have a special flag or even genus of "semi-wonders" that are unique for a player in a given moment but may be sold (like commercial Civ* Palace) or require upkeep. Alternatively, we could just have buildings count requirement somehow.

2021-10-08 01:29 Updated by: cazfi
Comment

So, the check is there for a reason and *not* needless. There is an issue with the current implementation that this override is silent, not warning ruleset author about the fact that things don't work quite like s/he expects. Will open a new ticket about that. Keeping this ticket for any future development to allow nonzero wonder upkeep.

2021-10-08 01:34 Updated by: cazfi
Comment

Reply To cazfi

There is an issue with the current implementation that this override is silent, not warning ruleset author about the fact that things don't work quite like s/he expects. Will open a new ticket about that.

-> #42994

2021-12-06 22:00 Updated by: None
Comment

I removed it and now can happily make upkeep for wonders. In this case, negative upkeep as a bonus for a certain wonder.

2022-01-06 02:45 Updated by: cazfi
Comment

First step towards this is #43556

2022-01-06 06:03 Updated by: lexxie9952
Comment

So this seems to be angled toward not allowing upkeep unless a building is sellable.

I am not sure if this is following a plan for compatibility with FCW and MP2 rulesets.

In particular, we have a wonder with negative upkeep (Hoover Dam) which relieves upkeep for other buildings in its own city.

I believe I see the case that bothers you. Someone has negative upkeep and here is no other building to sell that's left except a wonder.

Disallowing wonder upkeep for this almost never occurring case, it's not ideal. But I suppose you are thinking a special flag for wonders with upkeep that if they have positive upkeep they must be sellable. As ruleset designer I should have liked a discussion on where we might go with it.

2022-01-15 20:21 Updated by: cazfi
Comment

Reply To lexxie9952

In particular, we have a wonder with negative upkeep (Hoover Dam) which relieves upkeep for other buildings in its own city.

Could that particular use-case be achieved with Output_Bonus_Absolute (#43593), or is there some semantic reason it wouldn't work? I would think that it would work only better (not disabled by A.Smith, AI would evaluate the effect correctly)
That "building sellable" development has uses other than this ticket, so I think it should go forward even if we don't accept it as something that resolves this particular ticket. While the first step might be just a boolean, further development could be three-state definition; not sellable / only force-sellable by server / sellable also by user. In any case, we can't accept any solution that causes server to crash.
2022-01-16 17:29 Updated by: lexxie9952
Comment

It would then not be upkeep removal, but would turn to a profit in cities that don't have another other building upkeep.

We modified the return statement in this function /**********************************************************************//**

Returns the total amount of gold needed to pay for all buildings in the city.

**************************************************************************/ int city_total_impr_gold_upkeep(const struct city *pcity) {

int gold_needed = 0;
if (!pcity) {
return 0;
}
city_built_iterate(pcity, pimprove) {
gold_needed += city_improvement_upkeep(pcity, pimprove);
} city_built_iterate_end;
// Negative upkeep buildings provide infrastructural support on the // upkeep of other buildings but can't result in negative gold_needed: return gold_needed > 0 ? gold_needed : 0;

}

The effect is it reduces upkeep by up to that amount but never turns into a profit.

I don't mind doing some other way that creates the same result. But it is clearly not meant to be a profit, but a "removal of up to X from the sum of upkeeps of other buildings".

2023-09-06 23:52 Updated by: cazfi
  • Milestone Update from (None) to S3_2 d3f (closed)
  • Component Update from (None) to General
2024-08-25 07:10 Updated by: cazfi
Comment

Won't make it to 3.2, which is going to d3f as soon as possible.

Attachment File List

No attachments

Edit

Please login to add comment to this ticket » Login