Page 1 of 1

Internal actions

Posted: Fri May 12, 2023 9:28 pm
by Ignatus
I see a conception of "internal action" introduced in 3.3. It seems nice but... it breaks doc/HACKING # Generalized action meaning undrstandings:
actions should keep having clear semantics
Please don't make non actions actions because they are similar to actions or because some of the things Freeciv automatically does for actions would be nice to have.
An action is something a player can order a game entity, the actor, to do.
Either rewrite the Sveinnung's guidelines, or rewrite the patches. Actually, do we need anything specific for NoVeteran unhardcoding when it is, effectively, already done (just without other part reqs) with "Veteran_Combat" effect setting to -200? Maybe just introduce "non-action-enablers" with one or more req vectors (or not req vectors, e.g., how to control if NoVeteran is attacker or defender?) that might have another, different names?

EDIT: I thounght "Gain_Veterancy" has target_reqs. Since it is, as I see now, on-self action, I see no difference with using the effect at all. A non-actionenabler that cares both sides would look like

Code: Select all

[conseq_enabler_veteran_attacker]
type = "Gain_Veterancy"
actor = TRUE
actor_reqs = {"type", "name", "range", "present"
 "UnitFlag", "NoVeteran", "Local", FALSE
}
target_reqs = {"type", "name", "range", "present"
 ; something could be here
}
just maybe a better design should appear. For e.g. a diplomat escape possibility we could have reqs on the diplomat (actor_reqs), the affected city (target_reqs) and the city to escape to (dest_reqs), and maybe a switch if the diplo can escape to the city just incited (dest_target = "possible").

Re: Internal actions

Posted: Sat May 13, 2023 6:35 am
by cazfi
Thanks for bringing this up.

Clearly the documentation in HACKING does not match, and something needs to be adjusted - but I think it's likely HACKING documentation. Maybe it's a bit outdated regarding the concept anyway?

Sveinung himself seemed to accept the concept of internal actions (use of action enablers) as a way to implement such checks in some tickets requesting them. He also has implemented concepts where actions get forcefully executed (i.e. not something that player orders - though that does not break the letter of "player can order")
I want to unify "actions" and "internal actions" on code level, as for most part they behave the same way, so there's no point in introducing new 20000+ lines (and growing) concept. Presenting them differently to ruleset author would be easy to do, but maybe confusing when you could still, e.g., have a requirement: "Action" "Gain Veterancy" "Local"

Whether "Gain Veterancy" specifically could be better implemented via effects; maybe. It would require adding at least Veteran_Work effect (osdn #43186).

Re: Internal actions

Posted: Sat May 13, 2023 7:32 am
by cazfi
cazfi wrote: Sat May 13, 2023 6:35 amMaybe it's a bit outdated regarding the concept anyway?
E.g. I've been shortening "action enabler" to simply "enabler" in some places for some time. To me they seem better way to implement "boolean effects" than effects system (Sveinung originally presented the idea of action enablers that way when I was having hard time with some boolean action enabling effects)

Re: Internal actions

Posted: Sat May 13, 2023 8:34 am
by cazfi
FYI: I put osdn #48023 on hold. (like this thread would have been disagreeing review of that ticket)

Re: Internal actions

Posted: Sun May 14, 2023 2:11 pm
by Ignatus
cazfi wrote: Sat May 13, 2023 6:35 am Whether "Gain Veterancy" specifically could be better implemented via effects; maybe.
Just in a global scope... In CivIV promoting units is an action in HACKING sense, player can select a specific promotion after the unit gets enough exp.