On Fri, 26 Jan 2001, FRASHiE wrote:
> First off, pally, I didn't say prior to. [...]
I've taken this privately and FRASHiE has sent me what I will interpret as
an apologetic reply. Suffice it to say that he is frustrated. Please do
not bother continuing his thread on the list, especially not with the
intent of flaming him for his impetuous reply. I will be attempting to
help him off-list.
ObCircle:
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)
similar code, someone pointed out, appears in db.c for the middle of the
year. Is this technique sufficient or should I introduce more constants
to defines the seasons? The current list of constants needed:
MUD_HOUR_PER_DAY
MUD_DAY_PER_WEEK
MUD_DAY_PER_MONTH
MUD_MONTH_PER_YEAR
MUD_HOUR_SUN_RISE
MUD_HOUR_SUN_LIGHT
MUD_HOUR_SUN_SET
MUD_HOUR_SUN_DARK
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.
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.
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.:
unsigned long make_epoch_file(void)
{
unsigned long epoch;
FILE *fp;
if (!(fp = fopen(EPOCH_FILE, "w"))) {
perror(EPOCH_FILE);
exit(1);
}
epoch = (unsigned long) time(0);
fwrite((char *) &epoch, sizeof(unsigned long), 1, fp);
return (epoch);
}
unsigned long fetch_epoch()
{
unsigned long epoch;
FILE *fp = fopen(EPOCH_FILE, "r");
if (!fp || !fread((char *) &epoch, sizeof(unsigned long), 1, fp)) {
if (fp) {
log("%s: Badly formed. Overwriting.", EPOCH_FILE);
fclose(fp);
}
epoch = make_epoch_file();
}
return (epoch);
}
Thoughts on this method?
Hopefully with these (and other) changes, it'll be much easier to define
the time period for your CircleMUD. CircleMUDs are almost always in the
fantasy genre and, without regard to genre, tend to de-emphasize themeatic
elements such as the period. I don't believe this is endemic of the
developers, but a problem with the software not making it convenient to
design for your theme. Hopefully, the removal of the bizarre constants
will open the door for more variety.
-dak
--
+---------------------------------------------------------------+
| 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