On 31 March 2013 08:43, Emmet Hikory <[email protected]> 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
[email protected]
https://mail.gna.org/listinfo/freeciv-dev
