Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
weather/day/night/climate
- To: crossfire (at) ifi.uio.no
- Subject: weather/day/night/climate
- From: Brian Thomas <>
- Date: Wed, 6 Dec 1995 15:26:19 -0500
Hi,
I have managed to sort-out all of the previous
mentioned difficulties within the lighting code *and*
add a few features. I will be posting again later
to describe this.
I am posting now to discuss another idea that
came out of this project--namely the possiblity to
have weather, climate and night/day cycles on (specified)
maps. These changes would occur "globally" ie all (loaded)
maps change at the same time.
For the maps, we would need to specify only the "climate".
The value of the climate along with the current season
could be used to determine the weather on that map.
CONFIGUREABLE?
-------------
A file could be made to control the timing of the changes
so that the server maintainer would have some control
over the occurance and duration of "night" and "day"
and the "seasons".
For example, In the file to specify the changes, we set
variables/def's like:
#define NIGHT 3600 /* base seconds to make night */
#define DAY 3600 /* base seconds to make day */
#define TWILIGHT 600 /* base seconds for sunrise/sunset */
#define START_TIME 1 /* which part of the day do we start with?
* "1" for day, "2" for night, etc. Allow
* a negative value to mean its random */
/* ordering of the seasons. Give the name and fraction to multiply
* the day and night times by and relative duration of the season
*/
season[] = {{"winter", 0.5, 2.0, 10},
{"spring", 1.0, 1.0, 5},
{"summer", 2.0, 0.5, 10},
{"fall", 1.0, 1.0, 5},
{ NULL, 0, 0, 0}
};
So in the above we see that "winter" and "summer" will last
2x as long as "fall" and "spring". Note we could make up our
own names and/or add entries.
/* which season to start with when we power up the server.
* Allow it to be specific season, random, or tied to the
* season it is in reality */
starting_season = "random";
If the starting season is "reality" the relative durations
of the seasons are meaningless. Allow another array to define
the seaons by month in the case you want to have starting_seaon
== "reality"
/* array used for defining CF season by real month. I simulate
* a schedule for Pennsylvania, USA below :) */
season_by_month[] = { {"winter", JAN},
{"winter", FEB},
{"winter", MAR},
{"winter", APR},
{"spring", MAY},
{"spring", JUN},
{"summer", JUL},
{"summer", AUG},
{"fall", SEP},
{"fall", OCT},
{"winter", SEP},
{"winter", SEP} };
Lets define the climates as flags:
#define MAP_FLAG_DESERT 1
#define MAP_FLAG_TUNDRA 2
#define MAP_FLAG_FOREST 3
#define MAP_FLAG_PLAINS 4
... and so on.
Now, the most complex part, which is the heart of the scheme: lay
out the effects which occur in each climate by season. Probably
this will have to be done in some hardcoded function. Perhaps
there is a more general way to do this but it escapes me at the
moment. It would be nice to say, be able to configure the effects
in a given season and climate.
Well, its something to chew on.
b.t.