City-buy allows buying off all shields of an unavailable production target
Likely #43278 is a subset of this.
Reply To cazfi
Likely #43278 is a subset of this.
The idea of my comment there applies with this too: That city is able to buy NOW is no guarantee that the production is still available during its turn change processing. Example with standard rulesets: Multiple players may buy a wonder during the turn, but only the one shuffled first in the turn change processing gets it.
But likely to have a rule that "buying something *known* to be unavailable is prohibited even if one can buy something that later turns out to be unavailable", would be an improvement over current rule that "buying is allowed on both cases"?
alienvalkyrie Reply To cazfi
But likely to have a rule that "buying something *known* to be unavailable is prohibited even if one can buy something that later turns out to be unavailable", would be an improvement over current rule that "buying is allowed on both cases"?
It would certainly help prevent potential mistakes for beginners, but it might cause a situation where having more information (in a way the game understands) would take away possible courses of action (i.e. buying something unavailable). If we don't want that, we could show a warning instead of downright prohibiting it.
In the development branch we could give rulesets power to decide, but not in d3f branches.
Note that with "Buy" as an action, the ruleset control would be in form of enablers of that action. So there's also a question if we want to introduce some temporary ruleset mechanism until we have "city actions" and "buy" implemented as one (neither happening in 3.2, I think, with relatively little time left as the main development version)
There's also possibility of something seeming to be unavailable, but becoming available before turn change processing, though maybe not with standard rulesets (or maybe with temporary tech loss?)
Reply To cazfi
In the development branch we could give rulesets power to decide, but not in d3f branches.
For d3f branches, it's probably best just to keep status quo.
For 3.2, boolean game.ruleset setting?
lexxie9952 What I really didn't go on about much, is that it becomes one of those kinds of cheaty exploits that really can degrade multiplayer game integrity and creates very unnecessary high stress for Gamemasters and server operators in community PR situations. I run a server on a fork so can keep the coded solution above annyway.
But I'm starting to try to be more serious about the goal that real-time live servers shouldn't have to be a fork . Upstream should strive to be a universal client-agnostic server capable of meeting the demands players have for live community servers. The result will be a huge bonus windfall in concentrated/unified development instead of fractured as it is now.
lexxie9952 Reply To cazfi
Reply To cazfi
In the development branch we could give rulesets power to decide, but not in d3f branches.
For d3f branches, it's probably best just to keep status quo. For 3.2, boolean game.ruleset setting?
Well, I start to think comments were made about 3.2 getting close to feature freeze before it would be capable of recoding a ported/translation of modern multiplayer ruleset like MP2. If that is the case, then any feature like boolean game/ruleset setting might just be wasted work or "clutter" never used. The higher meta-decision needs to be made about what server version will be able to support all ruleset features community already expects, then a decision like "let's wait for buy-action" and be able to check scope for unavailable target, or some other decisionn.
If 3.2 does want to strive for client agnostic server capable of (ported/translated) version of MP2, then a boolean game.ruleset setting works great! There is some chance other server operator stakeholders might want it anyway, as once an exploit gets out, it can go plague other servers after the first server patches against it. Sometimes it helps make it more real to know the context, so FYI the context was in queueing gov_req units and doing tricks with statue of liberty to make illegal, then the did_buy flag goes away after TC so u can change target again.
lexxie9952 While I'm at it, it might be better to leave nothing unsaid and full disclosure. There is player named Dr.Z who seems to have Ph.D. in Exploitology. No matter how many times I patch it trying to be liberal for real situations to allow nice convenience for players, he ALWAYS finds a way to exploit it into an unfair advantage neither of us could think of, then wants to brag about it and tell others, not knowing it causes loss of morale in player community. You can look at fcw.org commits in the last week or so of this post, and every single conceivable way you could have illegal targets or do buys on illegal targets or do tricks to change things from legal to illegal targets or use build slots or anything else, he found a way to exploit it.
Bottom line is, neither client nor server should think it's being nice or convenient or liberal to allow "harmless conveniences" or postponements or warnings around illegal targets and worklists, it has to be fully black/white yes/no 0/100 authoritarian "ORDNUNG und NO EXCEPTIONS!!" logic on outlawing everything, and be aware that it's not just in packet handling phase in mid-turn user interactions but many exploits also count on vulnerabilities on how TC phases process executions too.
Reply To lexxie9952
any feature like boolean game/ruleset setting might just be wasted work or "clutter" never used.
Just because FCW might not use some feature, doesn't make it "never" used. In this case, I'd be inclined to make the setting *default* to the behavior made possible by it. Not so sure about ruleup - it's usually expected to update rules unchanged.
Reply To lexxie9952
No matter how many times I patch it trying to be liberal for real situations to allow nice convenience for players, he ALWAYS finds a way to exploit it into an unfair advantage neither of us could think of, then wants to brag about it and tell others, not knowing it causes loss of morale in player community. You can look at fcw.org commits in the last week or so of this post, and every single conceivable way you could have illegal targets or do buys on illegal targets or do tricks to change things from legal to illegal targets or use build slots or anything else, he found a way to exploit it.
Well, avoiding exploitability was one of the reasons of the comments made here, even if it was not explicitly spelled so. We currently have a simple rule where *everyone* is allowed to buy the target they currently have. This change is about making it so that it's only possible by exploitation, for which there then is plenty of ways.
Reply To lexxie9952
Well, I start to think comments were made about 3.2 getting close
Around S3_1-d3f (last spring) I commented a lot in multiple channels about the 3.2 schedule.
This freeciv-dev email is still the latest status: https://www.freelists.org/post/freeciv-dev/Freeciv31-Freeciv32-schedule,1
Situation is to be re-evaluated once 3.1.0-alpha5 is out (likely December/January) and we see how far from beta1 S3_1 still is at that point.
Reply To (Anonymous)
one can buy them at lower shield-gold cost, then switch the target on the next turn from some unit costing 10 or 20 to one cost 30 or 40.
Buying gives just shields, not finished products, so buying unit costing 20 will only give you shields up to 20, and one cannot finish unit costing 40 with it. If that's not the case with fcw, then likely that's a difference in your code.
Preventing buying current production when it's not valid target at the moment is not critical for 3.2, and we're already late from d3f.
Unavailable production targets DO happen (probably shouldn't), but that's a separate issue.
This bug happens when there is an unavailable target in current city production. It is still possible to buy the target. This facilitated exploits like (rather) tricky worklist manipulations to arrive at illegal targets so that one can buy them at lower shield-gold cost, then switch the target on the next turn from some unit costing 10 or 20 to one cost 30 or 40.
Adding a check for unavailability in really_handle_city_buy() fixed it for us at FCW: