[Freeciv-Dev] (PR#12706) Events framework

["Guest" <rt-guest@xxxxxxxxxxx>]

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=12706 >

> You seem to be *very* confused indeed. 1.14.2 did not even have working
> configurable effects: it was all hardcoded in C at the client and server.

Nah, I just seem to have made you confused. I was talking about 2.0.0
and 2.0.1, where edditing effects does work. (but the comment I found
was about someone complaining that 2.0 was bad (I don't think so mind you)


Still, don't get the Lua part. Will the rulesets have Lua code?

Or is Lua just for creating new types of effects or event tags (that
would be great).  Thus, I (and other dummies) could still change the
effects and add events to the game, just not create new 'concepts'.

If currently it's all Lua, then I would suggest the next step to be
making a 'script' layer of the difficulty level as found in the 2.0.1
buildings ruleset. Then you could create all the flags with lua, and use
them in the rulesets (where you would have things like "After_Year",
1800 ; "id = choice","chance of choice happening (fraction of total" :
"choice", 1, etc..) 

As for Actually seeing what the rulesets look like, I'll wait until
2.0.99 becomes 2.1.0 (stable), cause I'm not looking into delving into
the CVS source, just yet. Thus I don't understand what the 'event
interface' is and other such terminology.

For a simpeler layer to be added later, or for consideration as 'tags'
to be used in the ruleset (and you would also need this kind of level of
explanation for 'simple' people to understand it and use it properly in
the rulesets):

for tag type "id", ("value" used for certain id types):
 "self" (default: means id applies to entry (can be ommited))
(cummulative lines are therefore, per default 'added' (AND statement
links them)
 "choice",INT (for every choice the chance is INT/Sum of INTs of
happening.) (randomness is automatically included in the the lua thing
that defines 'choice' )
 "if" (the rest is a condition to be tjekked. and only one of the lines
with "if" need to be true for the rest of the building to work (non if
lines) (this means that the OR statement links the two conditions) Note,
if lines are not effects given to the buildings/units etc, they are only
used to qualify as true.)
 "then" Used to specify a result after an if (this line will be excecute
(bonus given, extra condition to be checked, etc...) only if one of the
if-lines before it is true (it uses all if lines directly above it,
until it finds a line that is not an if-line (including self lines).
(two then lines after one another will both use the same if (or set of ifs)
 "else" Used to apply a bonus if all 'if'-lines fail.

"Name" (the name of the tag, just like it is now (2.0.0) for buildings)
"Value", "req_type", "req" as they are now, but with more different kind
of entries (such as specific terrain-specials).
All the choices to be used in scripts (both tag types, and tag entry
values) would be defined in Lua, as well as some 'calculation' tags (ie
the ability to use 'total cities', 'player1,player2,city.count.diff (ie
the diff between a player and another, specified in the rulesets:
"Player","Strongest_Player","City-count_Diff" (you would have tags like
strongest player, weakest player, All players (makes this line look at
city-count diff of you and all players (or strongest player and all
players, or whatever), because you don't always have French as
participants of the game, for example)

That way, the complicated stuff would be in Lua, and you would use the
'numerous' (because there are many variations on one team) tags to
specify the effect, in the rulesets, just like you specify an effect={}
line in the buildings. (and you could have many other type of
dependancies such as: 'building_req', 'obsolete by', made into effects.
Thus a building would just be one big group of effects:
Ie: [building_aqueduct_example]
    "Aqueduct" = {"name","value",
                  "Cost", 80,
                  "City_Size_Max_Plus", 4,
                  "Equiv_replacement", "Sewer System"
                  "Graphics", "aqueduct.art" (or whatever it's exactly
called), "defaultbuilding.art" 
                  "Sound","aqueduct.sound","defaultbuiding.sound"
 (name sound looks through a list of sound references until it's found
one that works (the first one usually), same for graphics.
                  "Upkeep","Variable" ;Ie have an effect_variable, that
is a short script in the same file as where all effects are defined)
where is defined what value 'variable' is, and how it's calculated (with
the req_type "return" 
                  }

    "Aqueduct" += {"req_type","req",
                  "City_Size_At_Least", 6
                  "Tech_Req", "Construction"
                  "Building_Req", "Marketplace" 
                  "Building_Have", "Marketplace"
                   (must both have a marketplace to build and keep
alive) (probably forgot a few) (note you could have building_req and
have as special entries: Table:BuilDep (Building Dependancies) and
Table:BuilOppDep (BuildingOpperatingDependancies) Ie 2 tables that
contain all the dependancies of buildings seperately, and that are used
in the individual building entries with "Name" = "Deps" (dependancies)
(no further entry, just Deps, then it will look in Deps for the relevant
conditions (such as "if","Building","Aqueduct",
                    "then", "Building_req","Marketplace"
                    "then", "Bruilding_Have","Marketplace"
                    "if","Building","Airport",
                    "then", "Building_req", "Factory",
                    "then", "Building_Have", "Bank", etc...
                    (hmm Building_Need is clearer than Building_Have)
                 }

    "Aqueduct" += {"id","Name","value"
                   "if","Event:OAD","Has_Happened",
                   "then","Skip";(skip the rest of the += entry)
                   "if","Event:VictoriousLegion", "Has_Happened"
                   "then","MakeHappy","","
(this special happiness thing only happens if you have a victorious
legion, and only before 0AD (events, would be kept track of. Thus if you
build an aqueduct, the event:OAD will be initiated (with value
Has_Happened), and it will return 0 if it fails (the 'if' will fail).
However, once attention to the event is made, it keeps looking if
Event:OAD,Has_Happened, is true (every turn). If it becomes true, every
 place it is referenced in (aqueducts in this case) are reevaluated.
(thus effects can change, due to an event.) Since Event:OAD is defined
as "Once_only" in the event script (this should also be a simplified
layer over lua), it will stop checking after it is satisfied. For every
new building (aqueduct) built, it will immidiatly pass the check,
execute the then (ie: skip), and thus no 'event variables' will remain
in memory. (making Event:OAD permanent would make for a lot of redundant
 calculation, but if 'time travel' is part of the game, then it makes
sense. (hmm..., you would have to keep all save games and revert to
them, upon certain events(it'd be weird)) 
Event:VictoriousLegion is of the type permanent, but is removed when
'Legion' is obsolete (this is part of how 'Event:Victorious' works in
general)  
    (end building aqueduct entry)

Note that with "Name of entry" = {} 
               "Name of entry" += {}
you can easily group effects/conditions/events to be carried out,
depending on the syntax (thus only contidions (applied to the building
itself) would only require req_typ and req, where the normal entries
(cost=X, graphics_tag=name etc..), would be of the type "Name","value"
(value doesn't implying a number (banana is a value for fruit, for
example)) It also keeps 'event' related effects to the building seperate
from normal effects. Also all the effects to apply on a building are
grouped toghether. 
There could be an effect Effect:Barrack, and this effect would be used
in all 3 barracks entries, reducing their size to practically nothing
(as they are practically identical, only the tech_req and obsolete by
change. ) Thus: [Effect:Barrack] [Barracks] [BarracksII] [BarracksIII]
would be the order of effects. Note that in case of redundancy,
'Effect:buildingtype' is handy to avoid having to guess where you will
find a particular effect. (when it can aply to more than one building)
ie: if supermakets improve harbours, is it a harbour's thing or a
supermarket thing? It's a Effect:ImproveFood thing, that's what it is.
And both harbour and supermarket have 'improveFood' entries. (which is
then sorted out in the table, along with any extra bonus you would get
for having at least 10 buildings (you could do that with such a 'simple'
scripting language.)

Actually, I think most of the entries are self explanatory, and
Event:OAD isn't a tag, its a ruleset-script entry itself (that uses Lua
made tags such as 'WHEN','Turn',50 (or how many turns 0AD corresponds
to); 'HOWLONG','Moment' ,'WHOM',ALL ; (or whatever, I'll look at the
events when 2.1 ships to get an idea of how you use events (will it be
like in Civ2 (as the original idea was, mentioned in forum)?'


Ok, maybe this nees more thought... but what's the point if you want to
keep most of the versitality of scripting in the Lua level. 

IMPORTANT SUMMARY (hey, it's long, so I thought it better to summerize)
Lua should only, I think, be used in cases where you are trying to make
an effect that doesn't yet exist, or cannot be achieved through a
combination of effects. This should warrant the creation of a new Event
tag or new effect tag, or tag value, rather than 'Black box'
functionment.(Ie effect and event that are too powerfull, that could
have been split up, should have, otherwise the 'effect' is rather
'closed', and only for 'insiders'-use (read use by developers and script
kiddies. I need something simpeler, more 'high' level.)

Albatrossix