Page 1 of 1

Lua scripts - unit's veteran level

Posted: Fri Dec 21, 2018 1:23 am
by Dino the Dinosore
You can assign a unit's veteran_level when creating a unit with edit.create_unit(), but there's no way to find out a unit's veteran_level or changing it. There should be a "unit.veteran_level" & "edit.unit_veteran_level()".

Re: Lua scripts - unit's veteran level

Posted: Fri Dec 21, 2018 4:56 am
by Ignatus
Yes, API still lacks many necessary things. I believe, it's better to open ticket on HostedRedMine for it. With basical C and Lua knowledge, you can suggest a patch yourself, the mechanism of this function is rather simple.

Re: Lua scripts - unit's veteran level

Posted: Sun Dec 23, 2018 2:36 pm
by Ignatus
Sum of unit properties (see common/unit.h, v.3.1 was studied) that don't have yet a get and/or set Lua function and should have it:
  • int homecity; - can be got but not set; we may need to assign a unit to a city with empty free slots as a kludge for civ3 ruleset.
  • int upkeep[O_LAST] - unit upkeep (should not be set), need (Unit):upkeep_gold() etc. We also have int server.upkeep_paid[O_LAST].
  • int moves_left;
  • int hp;
  • int veteran; - the veteran rank;
  • int fuel;
  • struct tile *goto_tile; - the goto or autoexplorer destination
  • enum unit_activity activity; - mining, irrigating etc.
  • int activity_count; - how much of the work is done by the unit, is counted in turns but is multiplied by ACTIVITY_FACTOR (which allows fractional values in some cases).
  • struct extra_type *activity_target; - we currently refer extras by rulename in Lua, maybe Extra_Type type is needed?
  • enum unit_activity changed_from; - we can on certain conditions resume this without losing progress.
  • int changed_from_count;
  • struct extra_type *changed_from_target
  • bool ai_controlled; - if the unit is automated, i.e. autoexploring, autosettling... Likely can be defined by the unit's activity.
  • bool moved; - will the unit regenerate
  • bool paradropped; - need to be automatically reset in civ2 ruleset, since AFAIK CivII allowed unlimited hops from city to city by paradrop (but only at full mp)
  • bool done_moving; - if the unit is either out of mp or is waiting in the goto process (that currently happens only to fueled units), read only needed
  • struct goods_type *carrying; - in v.3.0 caravans can carry different goods and thus found different traderoutes
  • int battlegroup; - don't know what is it, some grouping used by the client but stored on the server, up to 4 battlegroups are allowed
  • bool has_orders; - accelerator: if there are some orders on the list, read only needed
  • struct {...} orders; - a list of orders for the unit, i.e. actions to perform one after the another in given direction with given sub-target, may be cycled or cancelled if an enemy is met
  • enum action_decision action_decision_want; - you have pressed 'd'. Probably not needed until you understand it better.
  • struct tile *action_decision_tile;
  • bool stay - can be set by (unit):movement_(dis)allow but can't be got
  • The following are server-only:
    • bool debug;
    • struct unit_adv *adv; - advisor's task: none, autosettler, auto-build city
    • void *ais[FREECIV_AI_MOD_LAST]; - pointers to any data associated with this unit by the AI, should not be accessed by Lua - let the AI define them on its own, some callback must be called on changing all the rest
    • int birth_turn;
    • struct vision *vision; - We definitely need some Lua to support any vision/known tile toggling. But this field likely describes what is seen by this unit and should be changed only automatically.
    • time_t action_timestamp; - needed for unitwaittime in Freeciv-web
    • int action_turn; - also
    • struct unit_move_data *moving; - don't understand it good, likely it is about who have seen the unit leaving its previous tile, thus hardly needed
    • bool dying; - should not be set, or would we need to be able to abort unit removal?
    • int upkeep_payed[O_LAST];
  • These are client-only:
    • enum unit_focus_status focus_status; - some selection manipulation is needed
    • int transported_by; - don't underatand well. Used for unit_short_info packets where we can't be sure that the information about the transporter is known.
    • bool occupied; - TRUE if at least one cargo on the transporter, read only needed
    • bool colored;
    • int color_index; - Equivalent to pcity->client.color. Only for cityfounder units.
    • struct act_prob *act_prob_cache; - we should get somehow action probability even if not cached, this is likely by "request server - await response - activate got_response callback" mechanism