On Sat, 27 Jan 2001, Daniel A. Koepke wrote:
>How do you all propose handling the weather constants for times? As an
>example, the original weather.c line is:
>
> if ((time_info.month >= 9) && (time_info.month <= 16))
>
>which I changed to:
>
> if (time_info.month > (MUD_MONTHS_PER_YEAR/2) &&
> time_info.month < MUD_MONTHS_PER_YEAR)
The numbers and names aren't the best (i.e., don't take these verbatim
without thinking about it), but for illustrative properties:
#define SEASONS 4
#define SPRING 9
#define SUMMER 13
#define AUTUMN 17
#define WINTER 5
#define FALL AUTUMN /* :) */
#define IS_SEASON(t, s, e) (t >= s && t < e)
#define IS_SUMMER(t) IS_SEASON(t, SUMMER, AUTUMN)
#define IS_AUTUMN(t) IS_SEASON(t, AUTUMN, WINTER)
#define IS_WINTER(t) IS_SEASON(t, WINTER, SPRING)
#define IS_SUMMER(t) IS_SEASON(t, SPRING, SUMMER)
if (IS_SUMMER(time_info.month))
or
if (IS_AUTUMN(time_info.month + 1))
>I'm actually leaning towards the introduction of more #defines. The sole
>purpose for this is flexibility. I chose the more flexible approach for
>the hours of sun rise, etc. One particular effect this might have is
>redefining MUD_HOUR_SUN_x to use a table indexed by time_info.month so
>that you can realistically model longer days during the summer and shorter
>days during the winter, or maybe even have several days where the sun does
>not rise at all.
Sounds good.
>Flexibility is also the reason for keeping the days per week and the
>number of days per month separate (instead of doing, say, MUD_DAY_PER_WEEK
>and MUD_WEEK_PER_MONTH). If you wanted to model our calendar system, for
>instance, you could not because the number of days in a month cannot
>usually be evenly divided by the number of days in a week (the exception
>is February in non-leap years) and is dependent upon the month.
So how about:
unsigned char days_per_month[] = { 30, 28, 31, 31, 31, 30, 15, 45, ... };
The only problem being when people start changing defines and not changing
the values. We'll probably have to write a wrapper function that checks
the bounds to make sure it isn't exceeded.
>My thought on the ubiquitous beginning_of_time is to eliminate the
>constant, and let people define their starting year. The time of first
>running will be used to record the initial time so time will continue to
>elapse while the mud is down/etc.:
Yes.
> fwrite((char *) &epoch, sizeof(unsigned long), 1, fp);
No.
Make it editable, not some binary garbage.
fprintf(fp, "%ld\n", epoch);
> if (!fp || !fread((char *) &epoch, sizeof(unsigned long), 1, fp)) {
if (!fp || fscanf(fp, "%ld\n", &epoch) != 1) {
You might make it unsigned if you prefer.
--
George Greer
greerga@circlemud.org
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/03/01 PST