[XP] Dynamic Weather and Time System

Started by ThallionDarkshine, May 26, 2012, 10:51:43 pm

Previous topic - Next topic


May 26, 2012, 10:51:43 pm Last Edit: May 26, 2012, 10:59:13 pm by game_guy
Dynamic Weather and Time System
Authors: ThallionDarkshine
Version: 1.0
Type: Custom Environment System
Key Term: Custom Environment System


This script changes the screen tint to correspond with the current game time. It also dynamically changes the weather, complete with sound and screen tint.


  • Changes screen tint with game time

  • Random weather can be disabled ingame.

  • Can disable weather on certain maps by adding (in) to the map name




For right now, see demo for script.


To use, place directly under main.
To turn on or off random weather (replace true with false to turn off):
Code: text
$weather.rand_weather = true

To change the varience of weather:
Code: text
$weather.varience = 

To change the base time between weather changes:
Code: text
$weather.base = 

To change the second equivalent of one minute realtime:
Code: text
$weather.min_equiv = 


May be issues with other weather systems.

Credits and Thanks

  • ThallionDarkshine

Author's Notes

Use freely, no credit necessary.


A few things. Template is slightly messed up. Please, pleeease, use something other than rapidshare. >.< Mediafire is a great filehost. As well as Box or Dropbox. Now onto the script, I'm gonna nitpick a bit here. You have your weather class in a global variable "weather". Now I haven't looked at the script itself but I'm automatically assuming that your variable doesn't get added to save data. So that means, all of these values reset once the game gets closed. I would recommend implementing your class into Game_System. Game_System already gets saved in save data, which makes things so much more compatible. You should try and set it up like so these script calls can be used instead.



Just a suggestion anyways, it'll make things more compatible and consistent anyways. I'll fix up the template, there's just one minor mistake (you forgot the [XP] tag in the title) and I'll move it to the database for ya. ;3


May 27, 2012, 12:17:29 am #2 Last Edit: May 27, 2012, 12:22:00 am by Ryex
Is it compatible with my Dynamic Weather system? if yes then awesome! if no then shame on you >:( . LOL jk also I think it would be a good thing if you enabled a script call to shut weather off and on for the current map instead of a tag in the map name. and I don't mean a true false thing I mean a method you call to switch the weather off that would set the varible and call the update for you so all you had to do was

$weather.off  #turns weather off
$weather.on   #turns weather on

more user friendly that way
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />


Btw, game_guy, I am saving the weather class in save data.

Ryex, I'll look into your weather system and see if they're compatible.


Quote from: ThallionDarkshine on May 27, 2012, 08:51:09 am
Btw, game_guy, I am saving the weather class in save data.

Alright, I wasn't sure as I haven't looked through the code. Though I still recommend converting it to Game_System just to increase compatibility and whatnot.


How would my variable decrease compatibility??


I think game_guy is probably referring to the possibility of name clashes. Since you're using a rather common word (weather) for your global variable, the possibility of name clashes with other scripts is higher. Generally, it's recommended to use more instance variables than adding more global ones.

Let's say someone was using their own custom scripts in their game and already defined a variable called $weather (it is far more likely that this would happen in this situation because a lot of times developers don't release their custom scripts). This would cause a lot of weird errors that the developer might not anticipate since a name clash does not necessarily lead to an error.

Of course, you can also remedy this by naming your variable to something far less common like $weather_thdks but that isn't the best way to go because it makes it hard for other people to use it.

Anyway that's just my 2 cents. I hope this was what game_guy was getting at. xD


While tginick is partially correct, I'm more worried about people who use Custom Save and Load Systems. Custom Save and Load systems might use different methods when it comes to dumping and reading data. So if you have everything stored in Game_System, you have a sure way of saving and loading that data. And all it requires is a simple alias made to Game_System.

This guide by Blizzard mentions that Game_System is your best friend when it comes to saving. You should read up on the guide, it definitely helped me learn a lot.


Well, game_guy, I don't think it would really decrease compatibility with custom save/load systems because all I'm doing is aliasing the save and load functions.


G_G is most definitely correct.

Anyone who uses a custom CMS or save system that uses a different scene to save/load immediately cannot use this script without editing other scripts. This is the reason the convention is to use Game_System (or other Marshalled class that makes sense) to use as a container for their own class(s). Its actually easier to do anyways.
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.