patchFreeciv - Patches: patch #4004, RFC: Generalized actions

Show feedback again

patch #4004: RFC: Generalized actions

Submitted by:  Marko Lindqvist <cazfi>
Submitted on:  Mon 15 Jul 2013 07:19:24 PM UTC  
Category: NonePriority: 5 - Normal
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Planned Release: 

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Fri 16 Aug 2013 01:50:09 PM UTC, comment #6:

> I'll go through your patches within a week (sorry for the delay, but I have limited time) for at least commenting them.

Great. Hints when you read them:

  • As there currently only are two supported actions I have left them in an enum for now. This will change when autogenerated and/or rule set defined actions are added.
  • A change from the design in comment #2 is that I now use two requirement vectors: one on the actor and one on the target. This makes it possible to have unit requirements on the actor AND the target. It also avoids confusing rule set authors on who a requirement applies to.
Sveinung Kvilhaugsvik <sveinung>
Project Member
Thu 15 Aug 2013 07:27:58 PM UTC, comment #5:

> Please let me know if it still is to early to judge.

I'll go through your patches within a week (sorry for the delay, but I have limited time) for at least commenting them. As for committing stuff, I'm currently mainly trying to get extras work to some susteinable/stable state. As I don't want "everything broken at the same time" kind of situation, other patches may go in slower than usual.

Marko Lindqvist <cazfi>
Project Administrator
Thu 08 Aug 2013 08:06:55 PM UTC, comment #4:

> As for the rest, I want to see some code before judging the design for performance etc.

A snapshot of my progress is found in patch #4077, patch #4078 and patch #4079. Please let me know if it still is to early to judge.

Sveinung Kvilhaugsvik <sveinung>
Project Member
Fri 02 Aug 2013 08:39:06 PM UTC, comment #3:

> I think spy actions are a nice place to start

I don't think current AI code ever does spy actions, so starting from them would also free you from thinking AI in initial version. AI does do diplomat actions (such as bribing units).

As for the rest, I want to see some code before judging the design for performance etc.

Marko Lindqvist <cazfi>
Project Administrator
Thu 01 Aug 2013 11:05:04 PM UTC, comment #2:

A suggested approach. It separates the concept "action" from the concept "action enabler". An action is something a player can do. Examples of actions include building a road, building a rail road and inciting a city to revolt. It may be random if it will cause the desired result. It may cost something like movement points. It may have a text for menu entries, a shortcut on the keyboard and graphics for a graphical button (for the SDL-client). An action enabler makes it legal for a player to do the enabled action. An example of an action enabler is the effect Irrig_Possible.

Currently actions are hard coded (like "Poison well") or generated from information in the rule set (like "Build Road"). Some action enablers are effects (like Irrig_Possible), some are parts of other definitions (like an extra's requirement vector) and some are hard coded (like the requirement that one must be at war to poison a well).

It is not realistic to add an action enabler effect for building each extra. Generalized action enablers do the same job. Generalized action enablers also solve the current issue of road/river/bridge and will remove the need for effects to enable some extras. Actions could be made impossible by not defining any enablers for them. Generalized actions, should they be added, will need something like generalized action enablers to avoid having to implement the same action twice from different requirements and hoping they both won't be active at the same time. Thinking about generalized actions can be delayed until someone tries to add stuff like cost, menu text, keyboard shortcuts or risk of creating a diplomatic incident to action enablers.

A generalized action enabler has the action it enables and a requirement vector. Requirements that can't be expressed in an action enabler's requirement vector will still apply but not move to the action enabler. They will be tested for if the requirement vector is active. I think spy actions are a nice place to start so I'll use them as an example. In the beginning only the unit flag requirements would live in the generalized action enablers. If it becomes possible to require a war between two players (for example by adding a local range to the diplrel requirement type of patch 4051) that requirement will move to the generalized action enabler as well. But until that is done (and someone remove the war requirement from the enabler) poisoning the well of an ally will still be impossible.

Sveinung Kvilhaugsvik <sveinung>
Project Member
Tue 16 Jul 2013 10:17:10 AM UTC, comment #1:

> I wonder if we could tie that "actions" stuff to "causes" I've partly implemented.

One possibility is to have all actions cause EC_PLAYER_ACTION. Another is to make player actions a subset of causes.

Sveinung Kvilhaugsvik <sveinung>
Project Member
Mon 15 Jul 2013 07:19:24 PM UTC, original submission:

This ticket is split from patch #3976 for continuing discussion about generalized actions.

Marko Lindqvist <cazfi>
Project Administrator


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by sveinung (Posted a comment)
  • -unavailable- added by cazfi (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    No Changes Have Been Made to This Item
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup