[Freeciv-Dev] Re: patch for long-term play

[Jeff Mallatt <jjm@xxxxxxxxxxxx>]

This is based on a very quick look at your patch.

At 2000/03/27 09:17 , Justin Mason wrote:
>  > explain minturn
>  Option: minturn  -  Minimum seconds per turn
>  Description:
>    Each turn will not end until this amount of time has elapsed, even if all
>    players have hit "end turn". Zero means turns will end without a minimum
>    time.
>  Status: changeable
>  Value: 0, Minimum: 0, Default: 0, Maximum: 99999

This seems mostly okay.  Note that Robert Rendell
<rob@xxxxxxxxxxxxxxxxxxxxxxxxx> is also working in the countdown/timeout
area, so you two may need to coordinate.

I notice that the implementation should use secfile_lookup_int_default(),
so that old save files could be read.

Also, the clients don't seem to know about this, so they can't give the
players any feedback?  (See last point.)

>  > explain turntrigger
>  Option: turntrigger  -  Trigger file for next turn
>  Description:
>    This should specify the filename of a file used to trigger turn changes,
>    relative to the data directory.  If this isnon-empty, turns will not end
>    until the modification dateof this file changes.  This file must exist
>    before the gamestarts.  Default is empty (i.e. turns happen
normally,under
>    game control).
>  Status: changeable
>  Value: "", Default: ""
>
>The second bit is the most important. Rather than reinventing the wheel
>(and it would have been quite a tricky wheel at that!), I decided to let
>cron do the hard work; this patch allows you to "touch" a file from cron
>at any time you choose, triggering a turn change.  The code only stats
>once every 10 calls (roughly 10 secs in this case), so (a) there may be up
>to 10 second delay between the "touch" and the turn start, and (b) the
>load incurred should be minimal.  I chose this file-based method as I
>reckon it'd be more portable than signals.

Personally, I don't like relying on cron like this.  Not only does it add a
dependency that may not be satisfied everywhere (what's the Mac version of
cron?), but also not everyone thinks cron is easy to configure.

And again, how do you get feedback to the clients?  (See next point.)

>Both turntrigger and minturn are NOT currently sent to clients. Not sure
>if they should be, or how this is handled -- so I left them as
>server-only.

These only need to be sent if the client needs them for some reason.

There doesn't seem to be any client-side feedback for these options.
Specifically, in either case, how does a player determine when the current
turn is going to end?  If you sent minturn as game data, the client could
figure this out.  But, how do you inform the client as to when a file is
going to be next touched by cron (this is the feedback problem I mentioned
above).

I think it would be possible to come up with something that is both fairly
simple and "good enough" for Freeciv -- something that could also be
communicated to the clients so they could give the players some feedback.

This is just a real quick notion, but perhaps a list of things like the
following:

  +3h       --  means wait three hours
  +123m     --  means wait 123 minutes
  +2d       --  means wait 2 days
  +1h2m3s   --  means wait 1 hour 2 minutes 3 seconds
  =18h30m   --  means wait until 18:30, local server time
  =5d19h    --  means wait until 5th day of week at 19:00,
                local server time (0=Sun, 1=Mon, ...)
  (4+3h+1h) --  repeat "+3h+1h" four times; if the number
                after the "(" is missing, repeat forever
                (if 0 or 1, repeat once); may not nest
                repeat clauses
  :         --  if ever reach end of spec string, skip back
                to the place in the string of the first ":"
  * all characters except 0123456789smhd+=:() are ignored

This could be implemented with two state variables (pointer into string and
current repeat count).  It would always be easy to compute when the next
end of turn was.  Parsing is the only hard part, and it's not really that
difficult, either.  (If someone wants to do the rest, I could (in my
copious free time ;-) write the parser -- I think I've spec'd it simple
enough that a quick implementation would take little time.)

jjm