Tharsis . Design . ChangingRooms	Tharsis webs: Design | Guilds | Combat | Website
	Design . { Home | Changes | Index | Search | Go }

Weather

Assumptions:

• Room descriptions don't mention the weather.
• Weather might alter light levels.
• Even inside rooms may wish to be effected by weather.
• Outdoor rooms descriptions will have a line added indicating the weather (possible to turn off).
• The bulk of rooms don't alter anything except their description and light based on weather, and possibly a couple of actions such as being able to make snowmen.

We don't want to update the entire world every time the weather changes - IE the sun comes out from behind the clouds.

Most updates will just be textual messages to players - and can be delivered to players as such.

We do not include weather descriptions in the room description - we add it at the time someone does a look - thus adding a short amount of processing each "look" but not enough to make it considerable.

• Does this include winds which include smells and such that in a storm wouldn't be noticeable -- FreD - 18 Nov 2003 05:06
  • We can always tie the smell/listen commands into the weather. We can also make random messages appear based on the current weather conditions - eg the current snow handling at christmas. -- FantoM - 18 Nov 2003

For changes altering light level see the stuff below regarding night/day.

For changes to the room which alter functionality - eg the ability to make snowballs - we probably have to provide the command at all times and only accept it during the right weather condition.

For changes which make gross alterations to the room, eg the room filling with water during a storm, there must be hooks to the weather daemon.

Coding

Day/Night

• We want greater variation in light levels than 0 = dark, 1 = normal day.
• We don't want builders defining light levels unless there is a damn good reason ( or the room is inside ).
• We don't want to have to alter every room in the game to introduce this system, so all the existing "set_light" calls need to be handled.
  • There should be a 'window'-setting available, determining how much of the current sunlight that reaches this room. -- PumaN
• The system must be capable of changing light levels without having to update every room in the game.
• What you can see varies based on light level. This should be more than just an on/off system. In less than pitch dark you should be able to be aware of the existence of something without knowing what it is. In a little more light you might be aware that something is alive vs being a tree. With too much light you might run into similiar problems due to glare.

I figure a range of light levels from -10 to 10 indicating "night with no moon" -> "midday" is probably going to provide enough range to keep us happy. We don't have to do anything different for each level in that range at this time - we can handle -10 as dark, 10 as light and 0 as "lit enough to see vaguely shapes" to get us to the point of release.

Note: torches are currently light level "1" - this seems to fit into the scale I have listed above.

Coding

We further presume that we have just 1 light level across the whole world - although this might change in the future by adding time zones - highly unlikely.

The light level in a room is the ambient level + the level returned by the current query_light() call. For rooms which currently set_light(1) this will not have enough effect to screw things up on a scale of -10 to 10 if we break it up as -10->-4 is pitch dark, -3 to 3 is dimly lit and 4+ is daylight.

Presume for the first release that the time daemon just moves between -8, 0, 8 at different times of the day.

We should probably jack up torches to provide 3 light and provide lanterns with 8 light. This means in total dark you can see somewhat with a lantern and normally if you have a torch as well. In all times except total dark you can see normally if you have a torch.

• Double lightsources dont really add up all that well -- PumaN

By incorporating the ambient light level into the result returned by query_all_light() we make the change to room light levels very easily. All that then remains is updating /std/modules/living/m_sight to make query_can_see capable of returning the appropriate range of values rather than just 0 or 1 and then using those values appropriately in commands such as look.

If we return 0 = can't see, 1 = can see outline, 2 = can see detail then any usages of query_can_see will continue to work as they do now as they check by doing "if ( query_can_see(..) )". All that means is that commands treat objects as completely visible even if they are only visible as an outline.

Over time as commands are converted to support "outline only" and you do a look in a room and see "5 somethings" rather than "2 soldiers, a pram and Fantom" we will need to upgrade player.locate_object() to handle id checking properly - for you should not be able to do a "look at pram" unless you can see a pram and you should be able to do "look at something 2" - of course that opens a whole new can of worms relating to how we present a "something" when you look at it.

The concept of items being of varying visibility is currently ignored - you either see something or you don't ubt even if you don't and it talks you still see "Fantom says hi!". We have survived with this level of sophistication to date and there is no reason to use this as a sticking point now. We are aware that there is a large amount of effort required to use locate_object() everywhere it should be, to integrate it into verb handling and to integrate varying levels of visibility per viewer into the messaging code. This should not be seen as a reason not to press ahead with this coding as it's not going to be any worse under this system.

• Verbs centralizes locate_object so all uses a single one. -- PumaN

-- FantoM

First I'll tackle night/day

We (Fred/Ranma) have determined two ways of doing this.
1) We add a second long description to every room that describes the room at night. This set_night_long would only be viewed when the "time module" determines that it is "night time" If a room is indoors, or lit by something, we can avoid adding a night description. The downfalls for this is a lot of work, adding descriptions to over 3000 inplay rooms

• At this time I'm not working with rooms which have different longs for night - I'm going to presume the bulk of the rooms in the mud are coded such that they can survive with a single long and those that change can tie into a hook provided by the time daemon to make the alteration to their long -- FantoM - 12 Nov 2003

2) We make up several generic descriptions for every terrain type "coniferous forest, plains, beach" etc. We then give every outdoors room some extra code that would detail what type of terrain type it is. When night fell, the long description would change to suit what type it was. For instance if it was a forest room, a night description could read "The outlines of trees cut a stark constrast to the darkened sky"

• Possible but unnecessary at this time. There will be the opportunity to add an extra string to the appearance of a room and it may alter based on terrain but it will be done as per the coding description above rather than making any changes in the room - due to the cost of having to update 3000 rooms every time the time daemon ticks over "eg evening/sunset/twilight/dark/moon rise/moon overhead/moon set/dawn/sunrise/etc.". By and large if we do these changes with messages to the users and provide a way of looking at the sky to see the extra stuff we can avoid extra work at this time. -- FantoM - 12 Nov 2003

Perhaps a combination of these two would help us quickly fix generic rooms (backbone rooms) and allow us to go into detail on specific rooms

• Regardless of what I said above there are other benefits of adding terrain info into rooms. -- FantoM - 12 Nov 2003

A problem I see is that some current descriptions describe actions and mobs in their descriptions. The idea was that you'd get the night message, if you had no light source. But if suddenly you bring a light source and you see all of these people wandering around (see Tolnedra's market) it makes these methods that I've described useless.

• Worry about them as they happen and make sure new areas going into play don't have such problems. We can't fix all rooms prior to the release of something like this or we never release it. -- FantoM - 12 Nov 2003

now if we fixed all inplay room descriptions so that they just describe the environment we could have seperate day_chats and night_chats to describe the action

day_chat:Throngs of people wander the marketplace night_chat:A solitary figure darts out of the market

We could also add code that would allow us to add monsters during certain times of the day add_monster("/file/name/man.c", "2", "DAY"); <--add two of this monster file only during the day.

• Night vs day monsters is relevant in some areas - as are chats. Other things can also be worked into this however. If you wish a changing population with time of day you are better off to tie into the time daemon and upon the start of evening you make 1/2 the monsters walk home and then at night the rest go home and some others come out. Then reverse at dawn. -- FantoM - 12 Nov 2003

Weather
Weather is easier I feel. It involves adding appropirate chats to outdoor rooms and another line to what a person sees when they type look. Both of which would detail the weather

The weather module would determine what the weather is like, then each room would get weather_chats (room_chats that are specific to the weather)

So you'l see...
Several tall trees dot the edge of the road. The road itself is made of cobblestones and heads north and south.A sign is here.
(Hail pours from the sky)
exits (north, south)
many hailstones are here

then the occasional chat, Hail pours from the sky..

With a system like this we could again add weather specific mobs, only come out in good weather, or during bad weather.

Problems, weather over distances. Is the weather in the north the say as it is to the south? No, how do we fix this?

• As I said above - we don't at this time but it's not especially hard - we can have more than one weather daemon instance and tie a domain to a weather daemon. -- FantoM - 12 Nov 2003

Also, using both systems we could have weather dependant objects, and we can keep the dark descriptions seperate from the weather.

• This way we will cover the middleground of the current "pitch black or uplit" system that we have right now. Also rooms will be more dynamic to light/dark settings. The builder can overide this and add as much detail he wants at night.
  • As per my discussion above I have a means of handling greater light variation and also making it unnecessary for builders to specify light level at all. -- FantoM - 12 Nov 2003

Ranma 12 Nov 2003 21:02 - FreD 12 Nov 2003 21:02

I'd say that we can get away with chats for 90% of the stuff at this time - with the option (possibly player-based-preference) of turning on weather and light-level descriptions for rooms in the future. Like the time daemon the weather daemon provides hooks for weather alteration thus you can code weather-reactive items/rooms/mosnters.

This topic is about how to code it - there are other topics regarding what happens in rooms as time and weather changes.

-- FantoM - 12 Nov 2003

Perhaps we would need a tool that makes local weather changes and override night/day/time cycles to the current room only. For testing purposes. Might come in handy depending on how the whole thing is done -- FreD - 21 Nov 2003 15:46