On 31 March 2013 08:43, Emmet Hikory <per...@shipstone.jp> wrote:

> On Sat, Mar 30, 2013 at 10:02:02PM +0200, Marko Lindqvist wrote:
> > On 30 March 2013 18:42, Emmet Hikory wrote:
> > >     For terrain.ruleset, there are [options] and [parameters] sections.
> > > Do most of these still serve useful purposes?  From a quick look at the
> > > code and a bit of testing, I would think they are mostly also handled
> in
> > > a different way:
> > >
> > > [options]
> > >
> > > may_road:
> > > may_irrigate:
> > > may_mine:
> > > may_transform:
> >
> >  Their removal has been in my TODO for a very long time, but I've
> > never initiated the discussion (they have originally been added for
> > some reason, right?)
>
>     Given the timing and history, I think they can be safely removed now
> that everything else has landed (arguably they might have been candidates
> for removal post 7513, but the more recent work gives ruleset authors
> enough flexibility that the original options seem awkward).
>

With the requirement of xxx_Possible effects they have effect (sigh) only
if ruleset author first explicitly adds those enabling effects and then
uses may_xxx to disable them. Sounds like an odd configuration to do.


> > > [parameters]
> > >
> > > road_superhighway_trade_bonus:
> > >     This appears to be used only to store the value in the ruleset and
> > > send ruleset packets continaing the value, but not in any of the code
> > > that actually checks the trade value of a square.  For all the shipping
> > > rulesets that have a "Super Highways", this appears to be managed with
> > > the Output_Per_Tile effect.
> >
> >  Is this true for stable branches too, or have I changed this as part
> > of gen-roads? If stable branches are affected, their documentation
> > (ruleset comments) should be updated to describe the situation. With
> > ruleset format and network protocol freezes we can't remove it
> > completely from stable branches.
>
>
>     For the ruleset comment patches, which releases are still sufficiently
> supported to benefit from this?  For 2.4, can the parameter just be
> dropped?
> For trunk, I presume it should be dropped.  Also, procedurally, should this
> be one ticket or multiple tickets?  Is it better to call it "patch" or
> "bug"?
>

 S2_3 and S2_4 are the actively maintained branches. S2_4 has been in
datafile format freeze for a long time, so unless parameter was optional to
begin with (so that beta1 would load ruleset without one defined) it cannot
be completely dropped.


>
> > pollution_* and fallout_*:
> >     These seem like they would be better handled by effects.  Something
> > like:
>
>  As we're going to rework specials for 2.6, I don't think it makes
> much sense to change this to temporary format that would change again
> to next version (forcing ruleset authors to update it for each
> version)

     I looked through the mailing list archives a bit trying to find
> discussion of the plan for extras, without success.  Is there a
> reference available?
>

 It's still mostly in my head only, sorry. The general idea is to combine
all of specials, bases, and roads, back under one construct, this time
called 'extras'.


 - ML
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to