I've been idling on my (smaugfuss 1.9) mud most of the day, just standing in the middle of what is typically known as New Darkhaven when I started noticing how spammy and inconsistent the weather messages are. Being curious (read irritated) I dug into how the weather system works. I know Kayle took great pains to redo the entire system (kudos to you) and anything I say should not be taken as offense, I'm just trying to understand everything. So I have a few questions.

1. There are no help files for 'setweather', 'showweather' or 'climates'.
I found most info in the weatherhowto.txt file and syntax help when typing setweather with no argument enough so that I could piece things together, but I can't find any help or explanation for each climate value. That would be very useful to know before setting an area as such. All I found was what appears to be an old help file for a climate command that no longer exists. Noobies need help files.

2. Showweather command - Syntax showweather (x) (y). So I looked it up in astat for New Darkhaven. I assume 0,0 is just the default, since I haven't set anything yet.


You can set two different climates in one cell? (btw, it seems to snow quite frequently)

3. From the weatherhowto.txt file;


There's no help for calendar, how does this work?

4. How can I change the frequency of the dynamic weather messages?

5. The existing help file for weather command states you must be in an outside room to see the weather yet I can get a weather check from inside rooms too. Is this behaviour part of the old weather or still incorporated in the new?

6. While this is all nice to have, does weather have any actual effect on gameplay? Is it harder to fight when knee-deep in snow during a blinding blizzard? Does that gale force wind and sheets of rain make a fireball less effective?

An interesting aside, after typing this post I looked back into my mud window and saw this;


I assume it's part of the seasons changing, but I'm now standing in an Inside room, why would I see this? And how can this be changed to not show in inside rooms?

If you search weather on smaugmuds, you'll see Kayle answers many of those questions already in posts. I know he posts to someone on how to slow weather update down, and goes over that you have to spread the weather out over a large grid, for it to work effectively, choosing where you want it to be hot on one end, where you want it to be cold on another, etc.

Vladaar

There are helpfiles included with the snippet, but I guess they were missed when the snippet was added as part of FUSS, when I have the time (read: not swamped with work) I'll see about getting the helpfiles in FUSS updated.



It shouldn't be doing things like that, I'll have to take a look at the code when I have some free time.



Samson'll need to field this one as the calendar work was his, and was then integrated into the weather for FUSS.



The easiest way to do this is to change the update cycle that it's called in. (There should be another post somewhere on the forums here where I go into detail about how to do this.)




This might be remnants of an early bug that was caught shortly after release where I had used the wrong macro in the if checks. I'll have to poke at the base to give you a definite answer. (Although, in complete honesty I've been considering overhauling the weather and making use of a little bit more C++.. but that's a whole other can of worms.)



Stock? No. Though the ground work for that is already laid. It would be a simple matter to look at places in the weather code (or more specifically the functions used to interact with the system) see how they work, and then work up your own modifications to make situations more difficult. At the time, I had already put nine months into the system as it is, and I was ready to work on something else, so as I finished working on it, I made sure it would be easy for others to make other systems interface with it easily.

You see this because it's not a weather message, it's a message signifying that the seasons changed, because it's hard to display subtle hints as time progresses.

Thanks for your time, Kayle.



I've just downloaded the weather snippet and I see no mud help files in there either. In fact, after reading the Install.txt I noticed there are no mud help files for any of the new commands that were added - setweather, showweather, timezone, holidays, setholiday, saveholiday. Most won't even give a syntax help when typed alone. I would really appreciate if anyone has mud help files already created for these if they would share.


See #1. Also, can I change the current season in the mud?


Sorry, I've searched the entire forum and can find no reference to do this. I did however find in the Install.txt again a reference to


Is this it? (I'm only assuming based on the 60 second weather messages)

Kayle's enroute to home where he's without internet so he asked me via text messages to post for him, since he forgot to do so before he left work, that the help files are in the how-to. Hope that helps resolve that aspect of the issue for you.

Thank you Conner (and Kayle).

Of interest to note, the 'helpfiles' are included at the bottom of the howto.txt within the snippet, but are not included in the howto.txt of the SmaugFUSS 1.9 stock base.

I suspect that the howto.txt of the SmaugFUSS 1.9 stock base is still the one that was written by Thoric back when it was Smaug 1.2 and has nothing to do with the howto.txt from the weather snippet written by Kayle for SmaugFUSS 1.8, but I could be wrong about that.

Maybe someone should replace it

Now that that's settled I'm still wondering how to change the frequency of the dynamic weather messages. I've tried changing

#define PULSE_AREA       (60 * sysdata.pulsepersec)

to other values but no effect so I guess that's the wrong place.

In regards to slowing the messages down see: Weather Message Frequency

Also, I'm going to try my best to make some headway on the other issues you brought up this week. Works been a little crazy. =/

Thank you Kayle, and no worries about the other issues, no hurry, we all know real life comes first.

As for the msg frequency, I'm trying to understand it all, I really am. I read and followed the instructions in the linked thread you posted above. I adjusted the PULSE_TICK #'s to no avail. Messages still come randomly every 30-60 seconds, plus now some even come after 10 seconds. Sometimes it rains in the middle of two snow messages.

I'm going to ask the really dumb question now. Could it be because the area is still at default cell 0,0? Do I have to set up all the cells for this to all fall into place properly?

If you post your update_handler function I'll have a look at it and might be able to give you a more targeted response, but without seeing what you've actually done, I can't really be of much help aside from what I already went over in the other thread.

Having a map that's completely set up, will make the system more stable, and will make it less random, but it won't help with the speed the messages are coming. However, given the number of issues you've had with the system, it might be time to give it a seriously look over, and see if there's anything that can be done to simplify it. Or at the very least make it easier to set up.

My update_handler;

void update_handler( void )
{
   static int pulse_area;
   static int pulse_mobile;
   static int pulse_violence;
   static int pulse_point;
   static int pulse_second;
   static int pulse_time;
   static int pulse_weather;
   static int pulse_start_arena = PULSE_ARENA;            /* new arena */
   static int pulse_arena = PULSE_ARENA;                  /* new arena */
   struct timeval sttime;
   struct timeval etime;

   if( timechar )
   {
      set_char_color( AT_PLAIN, timechar );
      send_to_char( "Starting update timer.\r\n", timechar );
      gettimeofday( &sttime, NULL );
   }

   if( --pulse_area <= 0 )
   {
      pulse_area = number_range( PULSE_AREA / 2, 3 * PULSE_AREA / 2 );
      area_update(  );
   }

    if(in_start_arena || ppl_challenged)                      /* new arena */
    if( --pulse_start_arena <= 0)
    {
      pulse_start_arena = PULSE_ARENA;
      start_arena();
    }

    if(ppl_in_arena)
    if(( --pulse_arena <= 0) || (num_in_arena()==1))
    {
      pulse_arena = PULSE_ARENA;
      do_game();                                               /* to here */
    }

   if( --pulse_mobile <= 0 )
   {
      pulse_mobile = PULSE_MOBILE;
      mobile_update(  );
   }

   if( --pulse_violence <= 0 )
   {
      pulse_violence = PULSE_VIOLENCE;
      violence_update(  );
   }

   if( --pulse_weather <= 0 )
   {
	   pulse_weather = number_range( ( int )( PULSE_TICK * 0.5 ), ( int )( PULSE_TICK * 2.00 ) );
	   UpdateWeather(  ); /* New Weather Updater -Kayle */
   }

   if( --pulse_time <= 0 )
   {
      pulse_time = sysdata.pulsecalendar;
      char_calendar_update(  );
   }

   if( --pulse_point <= 0 )
   {
      pulse_point = number_range( ( int )( PULSE_TICK * 0.75 ), ( int )( PULSE_TICK * 1.25 ) );

      auth_update(  );  /* Gorog */
      time_update(  );  /* If looking for slower passing time, move this to just above char_calendar_update(  ); */
      UpdateWeather(  ); /* New Weather Updater -Kayle */
      hint_update(  );
      char_update(  );
      obj_update(  );
      clear_vrooms(  ); /* remove virtual rooms */
   }

   if( --pulse_second <= 0 )
   {
      pulse_second = PULSE_PER_SECOND;
      char_check(  );
      check_dns(  );
      reboot_check( 0 );
   }

   if( --auction->pulse <= 0 )
   {
      auction->pulse = PULSE_AUCTION;
      auction_update(  );
   }

   mpsleep_update(  );  /* Check for sleeping mud progs -rkb */
   tele_update(  );
   aggr_update(  );
   obj_act_update(  );
   room_act_update(  );
   clean_obj_queue(  ); /* dispose of extracted objects */
   clean_char_queue(  );   /* dispose of dead mobs/quitting chars */
   if( timechar )
   {
      gettimeofday( &etime, NULL );
      set_char_color( AT_PLAIN, timechar );
      send_to_char( "Update timing complete.\r\n", timechar );
      subtract_times( &etime, &sttime );
      ch_printf( timechar, "Timing took %ld.%06ld seconds.\r\n", ( time_t ) etime.tv_sec, ( time_t ) etime.tv_usec );
      timechar = NULL;
   }
   tail_chain(  );
}

And, just to show more clearly the issue, here's a peek at what I see.



That's a 3 minute interval between area resets. Ideally, what I'm trying to achieve is weather messages every 4 or 5 minutes. An idea to make it easier to set up: Add a 'freq' field to the setweather command, like the area reset msg. That way people can set their own preference.

Thanks again Kayle for your time and help.

Look real close at those two blocks, and see if you can figure it out before reading the following:



(Just highlight it to read it.)

Finally found a use for the spoiler tag within a code discussion, eh?

Hmm, I never would have noticed that. I'm by no means a coder. I can guess what most of this means but I wouldn't know what should or shouldn't be there. It was there and nothing said to remove it.

However, did as you said and removed the UpdateWeather() call from if( --pulse_point <= 0 ). I'm not really seeing much of a difference. Still getting about 4-5 weather msgs every 3mins. I've adjusted the values in

both up and down but it's basically the same.

I'll continue to troubleshoot tomorrow by comparing the stock with the weather snippet, see if anything is there that shouldn't be or missing. Unless someone can think of something else.

Been a while since I checked in here, figured I might just do that.

The way I handled it on my mud was to add another pulse entry to system_data, and then making that as long as I wanted the weather messages to be.

in the update_timers function, you'll need to add an entry for sysdata.pulseweather something like this:

void update_timers( void )
{
   sysdata.pulsetick = sysdata.secpertick * sysdata.pulsepersec;
   sysdata.pulseviolence = 3 * sysdata.pulsepersec;
   sysdata.pulsemobile = 4 * sysdata.pulsepersec;
   sysdata.pulsecalendar = 4 * sysdata.pulsetick;
   sysdata.pulseweather = 6 * sysdata.pulsetick;
   return;
}

Update your update_handler to use the new value, something like this:

if( --pulse_weather <= 0 )
   {
	   pulse_weather = sysdata.pulseweather;
	   UpdateWeather(  ); /* New Weather Updater -Kayle */
   }

Then in the system_data struct you'll need to add an int pulseweather; in there somewhere, like:

int pulsemobile;
   int pulsecalendar;
   int pulseweather;

And lastly, in do_cset, you'll need to add a spot for it to display, like:

pager_printf_color( ch, "  &wPULSE_CALENDAR&W: &G%d  &wPULSE_WEATHER&W: &G%d&D\r\n",
					sysdata.pulsecalendar, sysdata.pulseweather );

If you use the values provided, your weather update cycle will update I believe every 1680 pulses, which would be something like... every 7 and a half minutes. If that's not long enough changes the 6 to an 8, and that'll update every.. let's see.. 8 * 280 = 2240. 4 pulses per second, so 240 pulses in a minute. So then 2240 / 240 = 9.3333333. So, changing the 6 to an 8 in update_timers function will slow your updates considerably. But it's up to you how you want to handle it. I'm still trying to find time to look into your other issues, in addition to work, there's now talk of the possibility that being a father might be in my future. So I've spent a lot of time at the Doctor with the wife the last couple days as well. Anyway, hope all this helps.

First of all, best of luck to you and your wife. I hope it all works out well.

Second, I followed your instructions explicitly and I am now quite happy. The "6" works well and at least I now know where to change it if I want to.

Let me tell you what I found. My update_timers and system_data struct were already the same as above. My update_handler was different because of the previous linked post that I tried to follow using the 'alternate' solution. I've changed that back to above. I may have found the problem in do_cset. It had the pulse_calendar but it did not have the pulse_weather piece (your weather snippet instructions also don't mention adding pulse_weather here).

As always, thank you so much for your time and attention. I really appreciate it.