[freeciv-dev] More comments re help text.

["Bobby D. Bryant" <bdbryant@xxxxxxxxxxxxxxx>]

I learned this morning that the help text is split between an external
file (data/helpdata.txt) and hard-coded text in client/gui-*/helpdlg.c.
(The latter handles text that is associated with flags in the rulesets.)

Except for minor problems such as the one described in the patches I
just sent out, the latter mechanism works very well with my modpack.
Unfortunately, the helpdata.txt mechanism doesn't, since (for example) I
changed "Marketplace" to "Caravanserai" and "Harbour" to "Fish Market",
with the result that they are not found in helpdata.txt.  The actual
effect of these improvements is hardcoded, based on the B_* value, which
is apparently based on the position of the improvement in the ruleset,
whereas the help text is based on the human-readable name of the
improvement, as matched in helpdata.txt.

So I was curious what the longer-range plans for help text was.  I
personally would prefer to see both effect and help text completely
controlled by flags in the rulesets, for the following reasons:

 o it would free me from having to count positions in the rulesets when
entering an item,

 o it would avoid the possibility of an error arising when the text in
helpdata.txt did not agree with what the actual game effect was, and

 o it would allow novel new units/structures/etc to be created by
combining the flags for two or more of the standard units/structures/etc
(e.g., you could have an improvement that boosted both food production
and income).

However, I could live with the helpdata.txt mechanism as well.  But if
that's the way you want to go, I think we should either convert it into
a .ruleset or else disperse its contents among the existing rulesets, so
that it can be more easily customized and loaded into the server along
with the other components of a modpack.  (At any rate, I don't see a
command for loading it from a non-default location.)

Treating it like a ruleset might be a desirable quick-and-dirty fix even
if it is not the preferred long-term solution, since it would probably
require much less coding.

Bobby Bryant
Austin, Texas