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