patchFreeciv - Patches: patch #4104, Generalize global warming/cooling

 
 
Show feedback again

patch #4104: Generalize global warming/cooling

Submitted by:  Sveinung Kvilhaugsvik <sveinung>
Submitted on:  Fri 23 Aug 2013 03:18:14 PM UTC  
 
Category: generalPriority: 5 - Normal
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Planned Release: 2.6.0

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)

Tue 04 Mar 2014 04:59:33 PM UTC, comment #11:

The original issue was solved by another patch. Retitling to be about a more general system that also was discussed here.

Sveinung Kvilhaugsvik <sveinung>
Project Member
Thu 05 Sep 2013 12:56:02 PM UTC, comment #10:

Thank you for reviewing it. Allowing multiple extras is reasonable to expect no matter what bigger solution ends up being implemented. I can add it to the basic solution. The effect solution already support it. I don't mind waiting for the extra work to get a bit further.

I would like to avoid the extra cause solution. As you pointed out it has problems. What concerns me the most is that it would tie climate change to the stuff you "get for free" from nukes and polluting cities. Use cases for separation:

  • Each "Atmosphere enrichment station" built helps global warming in a rule set where a frozen world is terraformed. The suspension of disbelief isn't broken by a free "Atmosphere enrichment station" each time a city is polluted.
  • Detonating a nuke creates a "Blast Road" in a science fiction rule set. The rule set author isn't lynched by a mob of angry climate scientists for claiming that roads cause global cooling.
Sveinung Kvilhaugsvik <sveinung>
Project Member
Thu 05 Sep 2013 02:36:25 AM UTC, comment #9:

Sorry I have not looked into this earlier. I've sort of wanted to get extra work a bit further before deciding anything about this. Anyway, I veto your patch. It hardcodes the assumption that there's exactly one extra that counts toward global warming or fallout, while I'm getting close to getting rid of such limitations in the existing code.

One more solution would be to iterate over extras of relevant cause (EC_POLLUTION or EC_FALLOUT) but that has its problems too.

Marko Lindqvist <cazfi>
Project Administrator
Thu 05 Sep 2013 12:17:53 AM UTC, comment #8:

Suggestion: I commit the simplest patch (the one not involving effects) for now. This way one direct use of a special disappears without getting in the way of a future solution.

Sveinung Kvilhaugsvik <sveinung>
Project Member
Mon 02 Sep 2013 10:36:51 PM UTC, comment #7:

I've not really looked the details of your plan, but as a general note I prefer keeping stuff in ruleset level rather than requiring lua scripting. Even the ruleset editing in its complexity is stated as major reason keeping custom content creators from freeciv - assuming coding skills from them is almost insane.

Marko Lindqvist <cazfi>
Project Administrator
Sun 01 Sep 2013 01:41:05 PM UTC, comment #6:

> Of course, once the climate change script becomes ruleset-dependent then the transformation arcs could just be rendered directly in the code: "if forest then jungle" etc. Can we do better?

Another possibility is to generate a multidimensional table from the generator data. If a neighbor exist it becomes its result in that direction. On the other hand arbitrary key/value pairs are more reusable.

> we'd probably want to provide a ruleset-adaptive Lua version of the current engine in default.lua taking its parameters from the ruleset.

Some (old but cleaned up) notes I have regarding that:

#define SPECENUM_NAME temperature_change
#define SPECENUM_VALUE0 TCH_MORE_EXTREME
#define SPECENUM_VALUE0NAME "More Extreme"
#define SPECENUM_VALUE1 TCH_LESS_EXTREME
#define SPECENUM_VALUE1NAME "Less Extreme"
#define SPECENUM_VALUE2 TCH_COLDER
#define SPECENUM_VALUE2NAME "Colder"
#define SPECENUM_VALUE3 TCH_WARMER
#define SPECENUM_VALUE3NAME "Warmer"
#define SPECENUM_VALUE4 TCH_RANDOM
#define SPECENUM_VALUE4NAME "Random"
#define SPECENUM_VALUE5 TCH_SAME
#define SPECENUM_VALUE5NAME "Same"
#include "specenum_gen.h"

#define SPECENUM_NAME humidity_change
#define SPECENUM_VALUE0 HCH_MORE_EXTREME
#define SPECENUM_VALUE0NAME "More Extreme"
#define SPECENUM_VALUE1 HCH_LESS_EXTREME
#define SPECENUM_VALUE1NAME "Less Extreme"
#define SPECENUM_VALUE2 HCH_WETTER
#define SPECENUM_VALUE2NAME "Wetter"
#define SPECENUM_VALUE3 HCH_DRYER
#define SPECENUM_VALUE3NAME "Dryer"
#define SPECENUM_VALUE4 HCH_RANDOM
#define SPECENUM_VALUE4NAME "Random"
#define SPECENUM_VALUE5 HCH_SAME
#define SPECENUM_VALUE5NAME "Same"
#include "specenum_gen.h"

#define SPECENUM_NAME global_disaster_flags
/* Don't create islands/inland lakes when not transformable */
#define SPECENUM_VALUE0 GDF_CONTINUEOUS_CLASS
#define SPECENUM_VALUE0NAME "Continueous Class"
#define SPECENUM_VALUE1 GDF_SPARE_CITIES
#define SPECENUM_VALUE1NAME "Spare Cities"
#define SPECENUM_BITVECTOR bv_global_disaster_flags
#include "specenum_gen.h"

struct global_disaster_type {
int id;
struct name_translation name;

bv_extras triggers; /* or requirement vector? */

enum temperature_change temperature;
enum humidity_change humidity;
bv_global_disaster_flags flags;
}

Sveinung Kvilhaugsvik <sveinung>
Project Member
Sun 01 Sep 2013 01:40:09 PM UTC, comment #5:

> What would we (or ruleset authors) lose from this?

The AI would lose ability to predict. You point out that clients have the same problem. Perhaps some mechanism to notify clients and the ai about Lua code could fix that? Adding a code analyzer to Freeciv is, IMHO, a bit excessive. Rule set authors can indicate that there exist a relationship between visible game state, invisible Lua code, and visible consequences. Data like scope, how accurate the information is, if the code being triggered is always good/sometimes good/sometimes bad/always bad, probability, client text and client icon may also be useful. I may be interested in planning and coding that in the future but for now I would like to focus on action enablers.

Sveinung Kvilhaugsvik <sveinung>
Project Member
Sat 31 Aug 2013 11:21:28 PM UTC, comment #4:

Sigh, missed some bits:

  • Re UI/state: since the notion of risk of warming/cooling must remain hardcoded, the state for that should probably remain in the server and be accessed from Lua via get()/set() methods. But the intermediate variables in the calculation can move out of the server into Lua.
  • Re configurability: currently we have server settings 'globalwarming' and 'nuclearwinter'. Lua script can access those, and since these notions remain hardcoded that's probably sufficient here, but for other features the question of how a server operator similarly controls them arises. They can use '/lua cmd feature=0', which exposes the detail that a thing's implemented in Lua (and we need to ensure it works correctly in a .serv file). Otherwise we could invent some way for scripts to register operator-tweakable settings via init hooks, or just a name/value dictionary exposed to Lua.
Jacob Nevins <jtn>
Project Administrator
Sat 31 Aug 2013 11:13:04 PM UTC, comment #3:

Maybe this is an appropriate point to post a musing I've had for a while.

== Lua-scripted climate change ==

The current rules for climate change (see "Math of Freeciv" on the wiki) are somewhat arbitrary, and ruleset authors might well want to customise them, but they are baked into the game engine and not very configurable at all (even numerically).

As a thought experiment, how much of the climate change engine could we move into Lua script? What could we do to our Lua framework to enable this, and ideally other similar ruleset-specific game features? What would we (or ruleset authors) lose from this?

Input: It should be possible to hook this all onto the 'turn_started' signal. To implement today's behaviour where it depends on pollution/fallout on the map, the Lua function can do a 'whole_map_iterate'. Missing: Lua code can't actually see if pollution/fallout is on a tile currently; that would need adding. (Per this ticket, this would be the code you edited to remove that hardcoding.)
I don't know how much slower Lua is than C code, but hopefully any overhead would be bearable once per turn.

State: The variables that accumulate climate change risk (heating/warminglevel/globalwarming etc) could perfectly well be Lua global variables; simply-typed variables are saved and reloaded in savegames, so can be removed from the server C code (but see below for more on this). The most arbitrary/tweakable part of the engine, the calculation, could be implemented entirely in Lua and be completely up to the ruleset author.

Output: When the algorithm decides climate change has occurred, it must change the world. In principle do-able, but there are several missing parts (easily added): Lua can't change terrain type; nor has it got a way to know map dimensions, necessary for current random terrain alteration (maybe it can use 'server.setting.get()' on xsize/ysize but that's a bit of a hack). It also needs to emit a message to players, which it can do with 'notify.event' (there is a special event type E.GLOBAL_ECO that users can filter on, but in general Lua-added functionality that we haven't foreseen won't be able to have its own distinct event types).
To implement today's behaviour, this code would need access to terrain.warmer_wetter_result etc from the ruleset (more on this below), and also to terrain_control.ocean_reclaim_requirement_pct (can_reclaim_ocean()), and to terrain type flags (TER_NO_CITIES), none of which are exposed currently but could easily be.

UI: What the client sees must necessarily be fixed; we can't generalise away from there being exactly two kinds of catastrophe ('global warming' and 'nuclear winter') which have a linear scale and particular sprites, because that's baked into clients and the network protocol, and we have no way of generalising it.
This is the strongest hindrance to ruleset authors unilaterally adding new similar features entirely via script; at most they can notify players by textual messages (perhaps disasters could have been implemented like this).

Configurability: One of the problems about pushing functionality and configurability to Lua script rather than providing server and ruleset options is that, if done lazily, it forces ruleset authors to code. It would be nice if the requirement for this could be minimised; ideally an engine author in Lua could make a parameterised engine which non-coding ruleset authors could tweak by editing simple setting-like parameters. (For instance, we'd probably want to provide a ruleset-adaptive Lua version of the current engine in default.lua taking its parameters from the ruleset.)
Thoughts on possible parameterisation and how it might be achieved:

  • The terrain transformations (warmer_wetter_result etc). Currently these four ruleset parameters are only used in the climate change code, so if that were moved to Lua the presence of these parameters remaining hardcoded in the ruleset format would be an ugly restriction.
    • Of course, once the climate change script becomes ruleset-dependent then the transformation arcs could just be rendered directly in the code: "if forest then jungle" etc. Can we do better?
    • Perhaps we could arrange for arbitrary key/value properties not understood by the Freeciv core to come from the ruleset (associated with terrains and similar objects) and be accessible by name from Lua in a dictionary-like object?
      • We could just implicitly put any unrecognised property seen in the ruleset in this dictionary (but this loses ability to spot ruleset typos and also potential namespace management problems between us and script authors);
      • or we could give script-accessible properties their own namespace (and move warmer_wetter_result etc into it).
    • This would keep all the terrain knowledge in one place in the ruleset.
  • Maybe the causes of climate change: if pollution/fallout become objects (extras?) which are available as a type in Lua (not currently true), they can have a property or flag associated with them in the ruleset ("WarmingCause") that causes the Lua script to take notice of them. If ruleset authors want to configure this they just change which extras have the "WarmingClause" flag and don't have to understand whether it's the script or server that's interpreting that.
  • The various parameters of the current calculation (currently not configurable). Could these go in a specific ruleset's [script] section as simple name=value type code setting global variables, and be picked up by the parameterised climate change engine? (This also opens the possibility of server operators being able to tweak these on a per-game basis via the /lua command, where otherwise we'd have to add a full server setting.)

=== Conclusion ===

It would be possible with a fair amount of work to move the climate logic entirely into Lua script where ruleset authors could play with it.
As usual when trying to do anything with our Lua interface, the gaps in what we've got round to exposing become evident (usually when I think of trying to do something I find at least one essential function/property I need is missing). But it's just work to fill those gaps, nothing complicated.
There are some simple things we could do in the core to make script parameterisation and configurability easier and not force ruleset authors to become Lua coders.

Jacob Nevins <jtn>
Project Administrator
Wed 28 Aug 2013 12:08:20 PM UTC, comment #2:

A setting version. A lot less flexible. Introduce no new flexibility that may be lost if global disasters are implemented some time in the future.

I don't know if this approach or the effect approach is the best.

(file #18785)

Sveinung Kvilhaugsvik <sveinung>
Project Member
Wed 28 Aug 2013 10:21:16 AM UTC, comment #1:

Update the effect version.

(file #18784)

Sveinung Kvilhaugsvik <sveinung>
Project Member
Fri 23 Aug 2013 03:18:14 PM UTC, original submission:

In stead of counting each special directly sum the effects. This may not be the best way to do it. Something like disasters, only global, would be better. Letting rule set authors specify an amount now would makes it harder to implement global disaster in the future (if regressions are to be avoided). If this is an issue I can change it to increase by 1 if the effect is above 0.

My primary motivation for this patch is to speed up the extras work. If it gets in the way (say the problem is solved in a private branch) feel free to ignore it.

Sveinung Kvilhaugsvik <sveinung>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by cazfi (Posted a comment)
  • -unavailable- added by jtn (Posted a comment)
  • -unavailable- added by sveinung (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.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 04 Mar 2014 04:59:33 PM UTCsveinungStatusIn Progress=>None
      Assigned tosveinung=>None
      SummaryDon\'t hard code pollution/fallout specials for global warming/cooling=>Generalize global warming/cooling
    Thu 05 Sep 2013 02:36:25 AM UTCcazfiStatusReady For Test=>In Progress
    Thu 05 Sep 2013 12:17:53 AM UTCsveinungCategoryNone=>general
      StatusNone=>Ready For Test
      Assigned toNone=>sveinung
      Planned Release=>2.6.0
    Wed 28 Aug 2013 12:08:20 PM UTCsveinungAttached File-=>Added globalWarmingCooling_setting.patch, #18785
    Wed 28 Aug 2013 10:21:16 AM UTCsveinungAttached File-=>Added globalWarmingCooling_effects.patch, #18784
    Fri 23 Aug 2013 03:18:14 PM UTCsveinungAttached File-=>Added globalWarmingCooling.patch, #18745
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup