This is for after the 1.3.2 release.
As some of you suspected, a goodly number of the utility macros in
data/utils are very rarely used, often only by one campaign or
scenario. With macroscope this is very easy to check using the
--refcount option. Doing several runs with --from ../data/utils and
small reference counts is extremely revealing.
The question is: what to do about it?
For a long time, the safe answer would have been "Nothing. We don't
want to silently break existing content." But macroscope liberates us
in two ways:
* We can check usage against the entire contents of the campaign
server (I routinely do this).
* Campaign authors can be expected to check their macro usage against
mainline -- and if they don't, our campaign server upload process
will soon do it for them.
This means that we can remove, rename, or reorganize macros without
risking any unforseen consequences. So...if we were designing a
macro utility library feature from scratch, what would it look like?
I see two goals in apparent contradiction to one another:
1. Encourage reuse of documented and debugged WML macros.
Scenario WML is easier to read, and easier to maintain, when
it uses macros that bundle up key constructions. We want
to encourage this, which argues for making the library as
large as possible.
2. Minimize load time.
On the other hand, we don't want every trash macro in the universe in
the default load path, because reading WML costs load time. Why
should every player have to pay startup overhead for macro definitions
that are rarely used? This argues for making the library as small as
possible.
Now let's distinguish two concepts.
* A "public" macro is one that has a documentation string and is
advertised as part of the WML interface of mainline, either through
the UtilsWiki page or the HTML-reference-page generator I just wrote.
* A "core" macro is oner that is always loaded at startup time.
Right now these two concepts effectively coincide -- the entire public
macro library is loaded on every Wesnoth startup. I think the right
solution is to split them apart -- make the public macro library big, but to
keep the core part of it that is loaded every time as small as
possible.
(It may turn out that *nothing* should be on the default load path.)
What I would do is create a third category of "library" macro, one which
is public but part of a macro package that scenario writers must
explicitly load.
Thus, for example, I'd take data/utils/teleport.cfg off the default
load path. Both macros in it are currently unused, but they are
reasonable things to have in the documented public interface.
As an example of a library I would add, I have a couple of macros I
wrote for NR that can be used to perform image effects on a unit.
Those probably shouldn't be core macros, but they probably do belong
in public space where they can be reused.
Inperatice, this will mean changing the default load path in game.cfg
and adding appropriate library inclusions where needed throughout
mainline.
I intend to move on this after 1.3.2 release, unless someone
explains to me why it would be a bad idea. It's my second agenda
item after merging Northern Rebirth.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
Before a standing army can rule, the people must be disarmed, as they
are in almost every kingdom in Europe. The supreme power in America
cannot enforce unjust laws by the sword, because the people are armed,
and constitute a force superior to any band of regular troops.
-- Noah Webster
_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
