[Freeciv-Dev] [patch #4671] Move limits on what terrain a spy action can be done from to action enablers
Follow-up Comment #8, patch #4671 (project freeciv): See also bug #22279. ___ Reply to this item at: http://gna.org/patch/?4671 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4671] Move limits on what terrain a spy action can be done from to action enablers
Follow-up Comment #7, patch #4671 (project freeciv): I have read the entire thread (which took me a long time because of my poor English). If I understand correctly, you are requesting here that spy action enablers would be moved to ruleset definition instead of being hard-coded in the server (and maybe client and AI, I didn't check if it matches). I suppose this is a part of series to generalize such actions. Isn't a way to test in a requirement a terrain is native to the unit? If not, this is probably the lack of highest priority for getting your objective. I think the term attack means attack, nothing else, and shouldn't mean anything else. If I remember correctly, only diplomatic unit action uses action enablers at the moment. I suggest that Attack, Help Wonder, Establish Trade Route (and maybe some other) should use the action enablers. After, maybe units able to do these actions would be determined directly in their definition in the ruleset. And then, many unit flags would become obsolete (and I think this would be very easier to maintain, notably to keep server/client/AI synchronized). If writing such conditions using the requirement syntax, why not using some magic lua function? ___ Reply to this item at: http://gna.org/patch/?4671 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4671] Move limits on what terrain a spy action can be done from to action enablers
Update of patch #4671 (project freeciv): Status: Ready For Test = In Progress ___ Follow-up Comment #6: Thanks for the deeper expansion of my suggestion Thanks for making me consider it again. I dropped it to soon. (I should have checked if the hack would have been required for any bundled rulesets in stead of assuming that it would and that it therefore would have to be supported. The hack gave me the idea behind Alternative 1 and the original patch) I think you are correct that Alternative 3 is the superior medium term solution. ___ Reply to this item at: http://gna.org/patch/?4671 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4671] Move limits on what terrain a spy action can be done from to action enablers
Follow-up Comment #4, patch #4671 (project freeciv): On actions and action enablers: You can have multiple action enablers for the same action. Action enablers are ruleset defined. Actions aren't (yet) ruleset defined. Complex action definitions is defining actions in the ruleset the same way you define arbitrary disasters and roads. You could then create two actions that establish an embassy. Not something I imagine will be done in the near future. _I suppose the deeper philosophical issue is whether the entirety of requirements to perform an action belong in the ruleset._ You are correct. I would prefer as much of the rules as reasonably possible to be declarative. This give ruleset authors more flexibility. It also makes it easier for software (our help system, AI-approaches that take the domain as input, etc) to reason about them. When that is said: Complexity is absolutely an argument able to convince me. There is a reason why I haven't suggested adopting the Game Description Language as the new ruleset format. ;) _I suspect that any Action could be used in an offensive way, regardless of how peaceful it might seem._ Exactly. Some actions ranked by how much an attack they are: Establish Traderoute Establish Embassy Steal Tech Combat Attack This is why I would prefer to make it ruleset defined. On Alternative 3: Adopt the attack semantic for all actions. To keep the current behavior Caravan would get the Marines flag. Has the advantage that it can inherit the existing code that supports acting from a non native tile. Supports spy can attack from non native. Consistent for all actions. Problem: it is currently possible to define a unit that is marines when it comes to one kind of action and not marines when it comes to another. (Example: A Warrior-Merchant that can establish a trade route to a coastal city but not attack an enemy on the beach while transported as sea) Potential solution: Hope that no such unit is in use and that if it is its users prefers the new semantics. Would anyone object to this? Ugly hack: Add a requirement that the unit is on a native tile to the action enabler of the action that only should work on native terrain. Units using this hack don't get the full benefits of the existing code to act from a non native tile. The hack could even enable rules like Establish Embassy but don't Incite Revolt from a non-native tile. ___ Reply to this item at: http://gna.org/patch/?4671 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4671] Move limits on what terrain a spy action can be done from to action enablers
Follow-up Comment #5, patch #4671 (project freeciv): Thanks for the deeper expansion of my suggestion, yes that was what I meant, although I hadn't thought it through as completely. Having read that, Alternative 1 looks very tempting, except for the complexity. Looking through the various call stacks for attack testing, it seems that many of the historical developers got lost: there is multiple repetition of tests, with different early shortcuts in different views, depending on who thought what was a good idea. The logic in unit_move_handling() differs somewhat, but both the client (in can_units_attack_at()) and the AI (all over the place) seem to rely on can_unit_attack_tile(), which requires: 1) The unit is not UTYF_CIVILIAN 2) The unit has an attack strength greater than 0 3) The unit can reach a target unit (depending on unreachable protects) 4) The unit owner is at war with all owners of all units on the destination tile 5) The unit is on native ground or has UCF_ATT_FROM_NON_NATIVE or UTYF_MARINES 6) The target tile is native to the attacking unit, or the unit has UCF_ATTACK_NON_NATIVE AND doesn't have UTYF_ONLY_NATIVE_ATTACK 7) The target unit can be targeted by the attacking unit *) Some other stuff about cities and unit counts and whatnot that isn't that relevant I tried to break this down into requirements vectors for a hypothetical action enablement, and ended up with far too many different sets (because of the ORs involved, and the variances depending on server settings). (1),(2),(7) ended up duplicated in all lists, I wasn't sure how to structure (3), (4) ended up being a list of present=FALSE conditions for every non-war state (because testing for war would early-terminate on the first matching unit), even adjusting the semantics for easiest application, and nativity broke into 4 cases (native-native, native-non-native, non-native-native, non-native-non-native). This entirely ignores the different server rules for diplomats, capturers, bombarders, (as these end up being different sorts of actions than the classic Combat Attack). So, while it may be interesting to try to solve the general problem (for which something extending from Alternative 1 is likely the best solution), I suspect this is very messy, and would end up with at least 4 clauses for every action enablement (which seems a high burden and prone to mistakes), which returns me to a preference for Alternative 3 for the medium-term. It occurs to me that a possible future alternative to avoid hacks would be to have a general reqs framework for units taking generic actions against tiles, which would default to 8 clauses (nativity x unreachable-setting) (or more), and which could be extended by ruleset authors to impose slightly different rules on an action-specific basis. I've not thought this through completely, but suspect that it would result in overall less duplication in the ruleset, although it may be a bit more difficult to explain in the ruleset author guidance. When looking at this, the concept of targeting reminded me of bug #20711: it may be that one only needs 4 clauses (nativity), rather than 8, because units may be able to communicate without being able to engage in combat (potentially depending on technology, etc.). ___ Reply to this item at: http://gna.org/patch/?4671 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4671] Move limits on what terrain a spy action can be done from to action enablers
Follow-up Comment #2, patch #4671 (project freeciv): Thanks for your feed back, Emmet. Your suggestions looks like two alternatives I had considered. I may have considered them enough that anything even remotely similar looks like one of them. Please let me know if I'm talking about something else than what you suggested. Alternative 1: Test if the unit is on native terrain in requirement Adding requirement types that look at various other unit information has been on my TODO-list for a while. I have delayed working on it to avoid collisions with all the other requirement work. My original plan was to add an is the unit on a native tile-test there and then use it in this patch. That would make it possible to keep the rules nativity-based. Aesthetically it helps keeping the population of the requirement type for various unit information (like CityTile is for tiles) above one. It allows the same flexibility as the current patch: if an action done from non native terrain is allowed or not can vary depending on other requirements. On the other hand testing for nativity bring complexity that could give a result the rule set author didn't expect. I was uncertain about the demand for the cases where it is useful. (Examples: action enable based on nativity + complex nativity and action enable based on nativity + spy units that behave similar with different kind of nativity) Your comment counts as evidence that there is demand. Alternative 2: It is an attack (Marines etc) It could be said that we currently consider the spy actions to be attacks. Why else would we ban doing them from non native terrain? By the same standard other actions I would like to move to action enabler control, like establish trade route, aren't considered attacks. (This could be solved by adding a flag saying that an action is an attack) I'm not convinced that everyone will agree what should be considered attacks. I can imagine a rule set where a land diplomat on a boat can establish an embassy but not incite the city to change sides. (This could be solved by making the action flag ruleset configurable) A down side is that rules like Land unit Spy can establish Embassy from a boat by land unit Diplomat can't becomes impossible. (This could be solved by complex action definitions in the ruleset and defining two different actions. But not in the near future) I think I'll implement the test mentioned in Alternative 1. Does that make the current form of the patch more palatable? An argument for waiting for the test is that this patch then can use it at once. An argument against waiting is that action enabler based tests currently don't check for nativity. ___ Reply to this item at: http://gna.org/patch/?4671 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4671] Move limits on what terrain a spy action can be done from to action enablers
Follow-up Comment #3, patch #4671 (project freeciv): On Alternative 1: My fear here is that the logical conclusion to a patch series along that line ends up causing the ruleset to need to duplicate the entirety of the nativity rules that are in the engine (unless move also ends up using this enablement framework, in which case it all gets pulled out of the engine). Given the deep complexity of this, and the number of issues we've encountered dealing with it, I'm not sure it ought be exported to rulesets. That said, when extending the testable conditions for units, being able to test nativity seems reasonable. I suppose the deeper philosophical issue is whether the entirety of requirements to perform an action belong in the ruleset. In favour is the fact that ruleset authors may be confused by hardcoded engine restrictions (e.g. can only be performed from native tile). In opposition is the potential complexity involved and the need to duplicate significant logic in multiple rulesets or lose the features entirely. On Alternative 2: So, an alternate way of thinking about the current attack semantics might be that one considers them as action semantics, where attack is one of many possible actions (side note: I'd like this, as it enables units that can both attack and bribe, for example, or allows much more interestingly complex solutions for capture than the current arrangement). This makes the names UCF_ATT_NON_NATIVE, UTYF_ONLY_NATIVE_ATTACK, and UTYF_MARINES even less correct, but they provide for per-unit specification of nativity concerns in a way that avoids needing to indicate this in the action enabler requirements. This model fails to handle the case where a Diplomat can Establish Embassy from a non-native tile, but only Incite Revolt from a native tile, but does handle the case where a Spy can Establish Embassy from a non-native tile but a Diplomat cannot (precisely the opposite from what is possible with the use of an IsAttack flag). That said, I believe that whether something can be done from/into a non-native tile is more about the nature of the unit (can it start there? can it reach there?) than about the nature of the action, but I can see the counterarguments. In the event that this needs to be about *both* action and unit, then it probably makes sense to have yet another data structure of some sort to deal with the interaction (an example of such a thing would be the combat bonus system, which deals with unit/unit interactions), rather than duplicating things. On Offensive Trade Routes: I've played games where my opponent repeatedly canceled all the trade routes to my city with Copernicus' Observatory by creating new trade routes to any trading partners I had: this had the combined effect of reducing my research speed (lower Copernicus' Observatory bonus), and increasing my opponents (multiple new traderoute bonuses). While such tactics may be rare, I suspect that any Action could be used in an offensive way, regardless of how peaceful it might seem. On Complex Action definitions: Do I understand correctly that one cannot currently define multiple Action Enablers for the same action, or when suggesting a workaround for dealing with allowing spies to establish embassies from transport, while diplomats required native terrain did you mean something else (e.g. different engine implementations of the actions)? My naive expectation was that action enablers were like effects: one could define as many sets of requirements for an Action as one wished, so as to get the semantics right. Disjunctive requirements would obviate the need for this feature, but that depends on lots of other things, and may not be possible within the 2.6 development window (requires completing nreqs removal, dealing with ruleset_cache, unifying uses of requirement vectors, etc.). ___ Reply to this item at: http://gna.org/patch/?4671 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4671] Move limits on what terrain a spy action can be done from to action enablers
URL: http://gna.org/patch/?4671 Summary: Move limits on what terrain a spy action can be done from to action enablers Project: Freeciv Submitted by: sveinung Submitted on: Sat 26 Apr 2014 10:24:40 PM UTC Category: None Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: sveinung Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: ___ File Attachments: --- Date: Sat 26 Apr 2014 10:24:40 PM UTC Name: 0001-Move-limits-on-what-terrain-a-spy-action-can-be-done.patch Size: 22kB By: sveinung http://gna.org/patch/download.php?file_id=20587 ___ Reply to this item at: http://gna.org/patch/?4671 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4671] Move limits on what terrain a spy action can be done from to action enablers
Follow-up Comment #1, patch #4671 (project freeciv): I'm uncomfortable with the philosophy behind this patch, because it encodes what actions can be done by action+terrain, rather than basing it on unit nativity, which either forces all action-enabled units to have similar nativity or requires the ruleset author to spend all sorts of time duplicating actionenabler enties to support the alternatives. This represents a regression from current behaviour (where one can reuse the same actionenabler clauses for both land-based and sea-based spies, for example). So, if we consider these actions to be attacks, could we not reuse unit nativity, UCF_ATT_NON_NATIVE, and UTYF_ONLY_NATIVE_ATTACK as a means to limit the actions that a unit may take against a given tile? Alternately, if actions are not to be considered attacks, I'd much prefer to see the nativity constructions be about unit definitions than about hardcoded terrains (this may require adding the ability to determine if a unit is native to a tile as a requirement). ___ Reply to this item at: http://gna.org/patch/?4671 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
