Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

weather/day/night/climate





	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.