チケット #42993

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

登録: 2021-10-07 19:09 最終更新: 2022-01-16 17:29

報告者:
担当者:
(未割り当て)
チケットの種類:
状況:
オープン
コンポーネント:
(未割り当て)
マイルストーン:
(未割り当て)
優先度:
5 - 中
重要度:
5 - 中
解決法:
なし
ファイル:
なし

詳細

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;
}

チケットの履歴 (11 件中 3 件表示)

2021-10-07 19:09 更新者: lexxie9952
  • 新しいチケット "Wonders needlessly hard-coded to override the building upkeep specified in the ruleset." が作成されました
2021-10-07 22:22 更新者: cazfi
コメント

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 更新者: cazfi
コメント

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 更新者: ihnatus
コメント

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 更新者: cazfi
コメント

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 更新者: cazfi
コメント

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 更新者: None
コメント

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 更新者: cazfi
コメント

First step towards this is #43556

2022-01-06 06:03 更新者: lexxie9952
コメント

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 更新者: cazfi
コメント

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 更新者: lexxie9952
コメント

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

添付ファイルリスト

添付ファイルはありません

編集

ログインしていません。ログインしていない状態では、コメントに記載者の記録が残りません。 » ログインする