[freeciv-data] Re: [Freeciv-Dev] new generalized calendars

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Sun, Aug 25, 2002 at 08:47:26PM -0500, Mike Kaufman wrote:
> On Mon, Aug 26, 2002 at 02:05:16AM +0200, Raimar Falke wrote:
> > > 
> > > game.date = 1941,12,7,0,0,0
> > > 
> > > for labeling savegames, which is what I suppose you want, I sould have
> > > to say:
> > > 
> > > "civgame-%d.%d.%d.%d.%d.%d.sav.gz", cal.cdate[0], cal.cdate[1], ...
> > > 
> > > alternately, we could add a "calendar_unit?.savelabel" boolean field
> > > that specifies if the unit is needed as part of the above. That way, the
> > > default calendar would save games as they do now.
> > 
> > You need a numeric/short version in the gamelog and the scorelog.
> 
> use the format above.

For the scorelog a simple numeric value may be nice (turn can be used
here). For the gamelog you need something which is space-saving and
easy to understand. I don't think that
  12,3,56,1,7,8 St. Petersburg (66, 6) founded by the Russians
achieves this. Turn can be used here. But in general this isn't this
important.

> > > I'm not so sure. Give an example where this is not the case.
> > 
> > The freeciv default calendar. You can't tell the turn of the year
> > without the knowledge about the spaceshipparts.
> 
> "turn of the year"? I don't know what that means. If you mean I can't do
> a reverse mapping, well, no unless we keep track of the turn that a
> change of timeframe happened.
> 
> > And this knowledge isn't in old savegames.
> 
> this doesn't matter. all old savegames are "freeciv calendar" ruleset
> games, so game.year will be used to fill cal.cdate[0] and all will be
> well.

Not if the year_to_turn function was modified by spaceshipparts (and
you don't have info about this in old savegames).

> > You still don't got it. The difference between your and my model is
> > that I have another layer of indirection (game.calendar). This layer
> > is unnecessary if all (by modpack authors or similar) requested
> > calendars can be implemented with one (your) calendar. You cheated
> > because with the ability to extend the calendar (builtin) you can
> > model any calendar. You must agree that other calendars/whatever is
> > necessary if we remove this ability from your model.
> 
> there may be some smattering of truth here, but this is really orthogonal 
> to what needs to be discussed.
> 
> > > I suspect that the major features of civ should be integrated:
> > > o the building of (the first of) a certain unitype.
> > > o the building of (the first of) a certain improvement.
> > > o discovery of a tech.
> > 
> > > o I suspect that Per might like something like the death of a certain
> > >   unittype (like a Sauron unit), but I think that might be going a bit
> > >   far...
> > 
> > And exactly this is the problem: where do you draw the line? You may
> > also want certain modifications like:
> >  - building of a unittype is possible
> >  - building of a unittype is possible for all players
> >  - first player builds the unittype
> >  - all players built the unittype
> >  - all players have an existing unit of this type
> >  - and so on
> > 
> > Where do you draw the line?
> 
> Yes, this is exactly the problem, and I would like the people on 
> freeciv-data's opinion about this. After all, what we're _really_
> talking about here is only ONE change (aside from ignoring the spaceship
> and tech doubling rules) in the mechanics of the game and that is that
> with the change of timeframe, we get a possible change in the end game
> date. Since everything else [should] be determined by turn number,
> changing how "time flows" really only materially could change the number
> of turns left in the game.
> 
> Example: if we were to only throw out the spaceship and tech doubling
> rules, AC would have its calendar. Nothing else is necessary. The only
> thing generic calendars change is making the representation of a turn 
> look pretty. (not to say this is completely unimportant)
> 
> So which of the above features should be implemented, keeping in mind
> that we only thing they might change (depending on how you write the
> ruleset) in the number of turns until the end of the game?
> 
> Raimar appears to want none as well as getting rid of the patches
> tech_req and tech_trigger. I have no strong argument against this. As a
> pro: the code's already in the patch, it's not large and it'll probably
> be useful to somebody. However, the code is certainly not as elegant as
> it would be without. Do any of the modpack writers (or anyone else) see 
> a clear need for such a feature?
> 
> I would support writing code for my first two above (1st of a certain 
> unittype and 1st of a certain improvement (the 3rd is already in the
> patch)) The reason for doing so is analogous to the the tech code.
> Again, opinions on usefulness?

> I don't like Raimars strawman ideas, either because they're covered
> already by by the 3 I've suggested, or they're far too esoteric.
> However, I have no strong opinion. 

Where are the modpack authors?

> > But the time in the game is measured in the current calendar of this
> > age. Or isn't it. Well this is a philosophical question.
> 
> I see your meaning. It actually would be kind of neat to associate a set
> of [calendar_unit?] definitions with a particular timeframe, so you
> could start out in lunar units, move to Julian units, move to Gregorian 
> units, and then move to Stardate units. It'd be awfully flexible, but
> then again, really, what's the point?

About the "awfully flexible": Keep in mind that we only have to make a
tranformation from a turn number to a string. It shouldn't be hard.

> > I agree that you have to prodive an "espace" mechanism.
> 
> eh? "escape"?

A way which alllows you to change to meaning of something. Like in
"\"" (backslash) or "foo $bar foobar" (dollar).

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 A life? Cool! Where can I download one?