Dynamic Weather and Time System
Authors: ThallionDarkshine
Version: 1.0
Type: Custom Environment System
Key Term: Custom Environment System
IntroductionThis script changes the screen tint to correspond with the current game time. It also dynamically changes the weather, complete with sound and screen tint.
Features
- 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
Screenshots(http://i1202.photobucket.com/albums/bb363/ThallionDarkshine/Screenshot3.png)(http://i1202.photobucket.com/albums/bb363/ThallionDarkshine/Screenshot2.png)(http://i1202.photobucket.com/albums/bb363/ThallionDarkshine/Screenshot1.png)(http://i1202.photobucket.com/albums/bb363/ThallionDarkshine/Screenshot4.png)
Demohttps://rapidshare.com/files/2898565759/Weather_Demo.exe (https://rapidshare.com/files/2898565759/Weather_Demo.exe)
ScriptFor right now, see demo for script.
InstructionsTo use, place directly under main.
To turn on or off random weather (replace true with false to turn off):
$weather.rand_weather = true
$weather.update
To change the varience of weather:
To change the base time between weather changes:
To change the second equivalent of one minute realtime:
CompatibilityMay be issues with other weather systems.
Credits and Thanks
Author's NotesUse 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.
$game_system.min_equiv
$game_system.rand_weather
$game_system.base
etc...
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
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
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
Thanks.
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.
http://forum.chaos-project.com/index.php/topic,22.0.html
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.