[CF-Devel] Questions to developers

[Mark Wedel]

First, the question people following the standard programming practices
seem to be failing.  MT is probably the biggest offender, but not the only
one.  To me, the core principals that should be followed are:

1) Discussion of proposed changes.  Now, if you just fixing a bug or making
a minor change, this isn't really necessary.  Definition of minor change
is obviously vague.  But if your change includes changes/additions
to the client/server protocol, how objects works, or will be more than
a few hundred lines, a note about what you plan to do should be sent to
the mailing list.  I've seen many commits done where my impression is
'that is a really stupid way of doing that', but I'm not goint to spend
my time fixing it or getting in a lengthy discussion to the author on what
the proper way would have been (since they've done the code, they don't
really feel like going back and fixing it themself)

2) Documentation. Most new things should get documented - this is
especially true with changes to object structures or changes to the
protocol.  If we don't follow this, documentation gets hopelessly behind
and/or someone else needs to figure it out later (which tends to be much
more difficult because that later person has no real idea how it was
done.)

3) Writing clean code.  Code written should not generate any warnings when
compiled with gcc -Wall.  This is mostly just simple things - removing
unused variables, making sure functions that are not void actual have
return values, proper commenting, etc.  C Code should also conform to the
ANSI C & Posix specs (this last point may be a bit iffier in some areas
as code written specifically for one platform but with proper #ifdefs for
other platforms may not really need to meet that).

 Now I am soliciting the developers opinions on how important these three
aspects are.  All have upsides and downsides which I won't bother going
into.  My main point here is to see if the developers at large are willing
and able to abide by these and if not, for you to present alternatives.
Note that whatever in the end is agreed upon would become unilateral for
all developers - if 80% (for example) agree that those are the guidelines
that should be followed, that remaining 20% who did not agree can't ignore
them - they must follow them or else.


Second MT's latest commit comment below:
++
Include mapstats cmd for extended clients (sdl iso). Cmd is needed for
automaps ambient media infos, map name and map parameter infos. Paramter infos
are used for "fire & forget" animation tags inside the map2 cmd (next patch).
server/main.c: include a automatic mapstats cmd every time the player enters a
new map. Its the "default" mapenter cmd. The script event should used for
special cases.
++

 Note the main thing that patch does is send the size of the map the player
is on, the name of the map, as well as exactly where the player is on that map.

 There have been past discussions and issues about how much information
we give to the clients about various aspects of server known details.  In
the past, it was decided that the client should not know about map size
or where the player is on the map.  But we should really decide this once
and for all.  Note that this will make playing easier (you will know exactly
where pits and teleporters dropped you for example).

 Like most things, there are plusses and minuses to this informatin.
The plus is things like automap or fog of war or whatever else will work
better.  The minus is that it may be much easier for players to navigate
themselves around maps that use teleporters and pits (some maps transport
you such that you need to find your way out - if you know where the exit is
from where you are now, that becomes much easier.)