The thing is, using just s as the variable name might conflict
with string variables, and ss is not much better (but probably
as good as op, if some other pointer-to-object variables do
not use it already). Another possibility is psetting (like there
is pcity, punit, etc.), though it is quite
Those are the 3 that are being actively developed. My
longterm goal is to merge them all into one project.
Looking through the patches of longturn and warclient I found the
patch 'Setting to control distance of traderoutes.' (longturn 20090623). This
is something I also wanted to implement
On 01/07/2009, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote:
Those are the 3 that are being actively developed. My
longterm goal is to merge them all into one project.
Looking through the patches of longturn and warclient I found the
patch 'Setting to control distance of
On 01/07/2009, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote:
I did rename op_* to pset_* as it matches the purpose of the variable: a
pointer to a setting struct
Do this for variable names whose type is 'struct setting *' or 'const
struct setting *' only, not function names.
How
Hello all,
at the moment I'm working with the settings definition. It started with the
idea to load the settings from the ruleset (https://gna.org/bugs/?13621).
After the discussion to this patch I started to rework the entire settings
code. With help from mbook and pepeto I did
1. removed
On 30/06/2009, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote:
I would rename settings as options, ...
In the client the name option is already used for settings that
are client-only (client/options.[ch]), so I don't think renaming to
this in the server would be very helpful or useful.
On 30/06/2009, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote:
Am Tuesday 30 June 2009 22:36:11 schrieben Sie:
On 30/06/2009, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote:
I would rename settings as options, ...
In the client the name option is already used for settings
