[Freeciv-Dev] [patch #4104] Don't hard code pollution/fallout specials for global warming/cooling
Follow-up Comment #10, patch #4104 (project freeciv): 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. ___ Reply to this item at: http://gna.org/patch/?4104 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4104] Don't hard code pollution/fallout specials for global warming/cooling
Update of patch #4104 (project freeciv): Category:None = general Status:None = Ready For Test Assigned to:None = sveinung Planned Release: = 2.6.0 ___ Follow-up 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. ___ Reply to this item at: http://gna.org/patch/?4104 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4104] Don't hard code pollution/fallout specials for global warming/cooling
Update of patch #4104 (project freeciv): Status: Ready For Test = In Progress ___ Follow-up 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. ___ Reply to this item at: http://gna.org/patch/?4104 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4104] Don't hard code pollution/fallout specials for global warming/cooling
Follow-up Comment #5, patch #4104 (project freeciv): 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. ___ Reply to this item at: http://gna.org/patch/?4104 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4104] Don't hard code pollution/fallout specials for global warming/cooling
Follow-up Comment #6, patch #4104 (project freeciv):
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;
}
___
Reply to this item at:
http://gna.org/patch/?4104
___
Message sent via/by Gna!
http://gna.org/
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4104] Don't hard code pollution/fallout specials for global warming/cooling
Follow-up Comment #3, patch #4104 (project freeciv):
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
http://www.freeciv.org/wiki/Math_of_Freeciv#Global_Warming_and_Nuclear_Winter
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
[Freeciv-Dev] [patch #4104] Don't hard code pollution/fallout specials for global warming/cooling
Follow-up Comment #4, patch #4104 (project freeciv): 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. ___ Reply to this item at: http://gna.org/patch/?4104 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4104] Don't hard code pollution/fallout specials for global warming/cooling
Follow-up Comment #1, patch #4104 (project freeciv): Update the effect version. (file #18784) ___ Additional Item Attachment: File name: globalWarmingCooling_effects.patch Size:7 KB ___ Reply to this item at: http://gna.org/patch/?4104 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4104] Don't hard code pollution/fallout specials for global warming/cooling
Follow-up Comment #2, patch #4104 (project freeciv): 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) ___ Additional Item Attachment: File name: globalWarmingCooling_setting.patch Size:7 KB ___ Reply to this item at: http://gna.org/patch/?4104 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4104] Don't hard code pollution/fallout specials for global warming/cooling
URL: http://gna.org/patch/?4104 Summary: Don't hard code pollution/fallout specials for global warming/cooling Project: Freeciv Submitted by: sveinung Submitted on: Fri 23 Aug 2013 03:18:14 PM GMT Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: 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. ___ File Attachments: --- Date: Fri 23 Aug 2013 03:18:14 PM GMT Name: globalWarmingCooling.patch Size: 7kB By: sveinung http://gna.org/patch/download.php?file_id=18745 ___ Reply to this item at: http://gna.org/patch/?4104 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
