"Daniel A. Koepke" wrote: > How do you all propose handling the weather constants for times? ... > Is this technique sufficient or should I introduce more constants > to defines the seasons? You can figure seasons by dividing the number of months into four equal chunks and offsetting by a constant which sould signify the start of one of the seasons, something like this... #define MUD_MONTH_PER_SEASON (MUD_MONTH_PER_YEAR / 4) #define SPRING_START 3 #define SUMMER_START (SPRING_START + MUD_MONTH_PER_SEASON) #define FALL_START (SUMMER_START + MUD_MONTH_PER_SEASON) #define WINTER_START (FALL_START + MUD_MONTH_PER_SEASON) > 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. You can do this with a few fancy calculations and a single #define that defines the number of hours of light on the shortest day of the year (that day being the middle of winter). It is assumed that there will be the same number of hours of darkness on the longest day of the year. > 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. Well, if you want really true flexibility you can set up a table for the months that defines the number of days in each month individually. If you're gonna do this, I would recommend offsetting everything else by the day, though for easier calculations. > 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.: Agreed. Regards, Peter -- +---------------------------------------------------------------+ | 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