[Freeciv-Dev] Re: mapgenerator6 - single continent [cvs diff -u]

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 08:38 PM 02/10/30 -0500, =?BIG5?B?vbKr7bXY?= =?BIG5?B??= wrote:

> It seems redundant to me,
>for mapgen to read in and write back data it does not need to
>understand. I was hoping mapgen to be as standalone as possible.
>Meaning, you can copy a few include files and compile them with
>"gcc -o mapgen mapgen.c" without the need for other freeciv source.
>The more references you need, the less likely it is to be implemented
>in anything other than C or C++. Perhaps map_load() instead of
>game_load()?

The registry code is pretty simple and low level. It basically parses
an ascii text file with [sections] and property name=value pairs. You
don't need to understand what it reads beyond this level. It will then
write out anything in its in-memory version on save, again without any
understanding of the details beyond the property syntax rules.

Reimplementation of the registry operation in any other language is 
straightforward.

To load from the in-memory version into working memory you ask for the
section.name parameter values as you want them. For example most of the
map generation parameters are in the section [map] with names like
"map.generator" or "map.separatepoles". Read what you need to make your 
map and save back any updated values. Then save the full registry and 
you have a new civgame.sav.gz.

With this you don't need to know anything much about what constitutea
a Freeciv savegame file. Just load in any existing one and you will get
all the bits you need for free. Plus you didn't even need to know what
you were reading in. The only things you need to know and/or update are
the map specific details you are changing. If Freeciv changes its savegame
options, then read in a new savegame as your template instead. No code
change is required.

>> server admin "import" a list of trusted programs in a known server
>> location and select them by index is usually a pretty safe way to
>Would that require a lot of extra codes in server?

No. The server could execute a single hardcoded path to a (shell script)
program with a well defined set of option arguments. Anyone running the 
server just has to have the shell script pickup one of the options and 
use it to decide what program it wants to run and what option munging 
this requires. Presumably anyone writing a standalone mapgen program will 
understand and provide any conversion details or shell code necessary to 
run their program from such standard command options. The server admin 
just needs to fold this into a case statement in his master script.

Change to the server code is:
0)  Have the rulesets or commandline load/save a "game.mapeditor" string.

In mapgen, if the mapeditor value is defined (1-3 replace the mapgen call):
1)  Call savegame to dump a savegame into the (standard) filename.
2)  Execute its hardcoded command with options like the filename (and 
    possibly, but not necessary game.mapeditor string).
3)  Wait for the command to finish and call loadgame to reload the 
    savegame file.
4)  Sanity check the map/new parameters (done already) and continue.

>> 4) A lot of information needs to be transferred beyond the arguments of
>> the command in order to create a recognizable savegame map. The easiest
>They are needed for a savegame, but not a map (my fault, see above).

No, a lot of map generation detail is built into rulesets and squirreled
away in structs like game, terrain_misc or tile_type. Things like whether
the map should use T_RIVER type or do rivers as S_RIVER special overlays
on any T_<type> aren't really saved anywhere.

Any map that uses things like the food/shield/trade values for tile_types
needs to sync with the dynamically chosen ruleset definitions. Otherwise
you could end up with your map T_MOUNTAIN tiles actually being T_SEATRENCH
in the played game, or the balance in resources you laboriously computed
being totally scrambled because the game doesn't use your default values.

>Most of the map parameters should be defaults and can be supplied
>from a shell script.

There is a layer of hardcoded defaults, a layer of ruleset updates to the
defaults and finally a layer of individually selected override options.

> And if they are specific to mapgen only,
>we can remove them from server/savegame totally. Simplifying the
>server codes a bit.

Maybe. But the server is the primary user input point. the rest are
all default levels.

>>               [--generator {1-5}]
>>               [--maptype {0-7|EARTH_ISO==5}]
>Different generators should be implemented as seperate executables.

Possibly, but not necessarily. In any event, you still need to indicate 
which generator you are choosing at some point and a commandline argument
is one way. The master script might choose to run different programs
or one mapgen replacement for the 5 existing generator types, for instance.

>Regards,
>I.Q.
>-- 

Cheers,
RossW
=====