Meteorology in E16 Reborn (Patreon)

hi there. today we're going to be talking about the weather system, which as you may know, is approximately busted-as-fuck in E16. i'm going to go over how the system works, what went wrong, and how we fixed it.

so let's start with the old weather system that existed before E16, and why it had to be replaced. The old system worked like this: An event randomly selected one of like what, seven? preset weather patterns for a week. That pattern filled up a value slot for each day of the week with a type of weather. Then events were placed in each out door map that would update the weather periodically based on the day of the week and its value. The weather also needed to be called or cancelled whenever moving between maps meaning every single teleport event had to handle the weather. Then after a week had passed that original event could choose a new pattern and so on. 

so, what was so bad about this that it needed to be done completely? several things, as it turns out. this version of the weather system was implemented in e4 back when i was still all-too-shy about getting my hands dirty with the actual scripts, so i did everything the way i would have in RM2k3 (which did not have a script editor)-- through events. so this causes problems: 

• firstly, it is wildly inefficient from the development side of things to have to put weather handlers and teleports on every single map. 
• second, all those parallel events contribute to lag. scripts are always more efficient than events because there's less hoops to jump through. they also tend to be more reliable than events. 
• third, the controller event that decided the pattern had to use essentials' timekeeping which does not work for common events-- only map ones. which means i had to choose a map to place the controller event on, and i could only choose one. i chose the most central location in the game, opal ward. unfortunately that also meant that during the time the player is trapped up in carnelia, the weather pattern was stuck in the same one forever.
• the wind animation was handled via parallell common event, was very blocky, and inefficient. again, scripts > events. the problem is that unlike rain snow and sand, rpg maker doesn't have premade animations for windy weather, nor does essentials which added storm and sun. so i had to make it myself. basically we use a picture graphic, pull it across the screen and then put it back to the other side and do it again-- 12 times or so at once. it was very janky. 

okay, so eventually i was like hecc this and i designed our current weather system around episode 13 or so. it wasn't until 16 that it actually got implemented which i'd love to say was because it took a lot of time and revisions to get right but that would be a blatant lie and actually it was just because nobody got around to it and i didn't yet feel like i had the ability to. so. shucks. eventually kuro did it. mostly. it kind of wasn't finished so i finished it. 

so let's talk about how E16's weather system works and how it solves the previous problems:

• firstly, it is in the scripts. we also moved the wind animation to the scripts making it properly the same way rain is drawn. yay less lag.
• it now updates globally depending on when the player is stepping outside. no more need for those common events from every teleport, and i could delete all of those weather controller events on the maps
• when it updates it also asks for the time all on its own so the opal event can be deleted too bye binch

so that's nice. the actual structure of the weather controller is like this:

• when the player changes maps, we figure out if they're outside or inside now. if they're inside, we erase the weather cuz that shit don't go through rooves. if we're outside then we've got some work to do.
• first we've got to figure out if we need to define a new pattern. we've saved the time we last selected a pattern, and we've kept in a global game_variable which is a little bit extra but it's the quickest way to make sure that information is written to our save file. we ask if it's been 5 days since then. if so, time to set a new pattern. i opted for 5 days instead of a week to make it more dynamic. 7 days is unusually clean for weather, after all. why would it follow a calendar? x]
• if we need to set a new pattern we do so. i'm pretty sure it's just pure random, and you can get the same thing twice in a row. the patterns are: dry spell, scattered showers, chilly, wet, blizzard, variety. these are pretty similar to the original system's patterns. 
• so we've set our pattern, now let's look at it. it contains an array of weather types and their strengths (as in, more or less of the weather-- eg storms can be much fiercer than we set them as, with many more raindrops and lightning). even something like blizzard is not just snow the whole time. i'll make this up but as an example it would be like clear-clear-clear-rain-clear-clear-wind-wind-wind-snow-snow-snow-snow-snow-wind. each one is 15 slots because it covers 5 days of 8 hour segments. i chose 8 hour ones to be more dynamic again, instead of 24 hours. anyway i usually try to fade in and out of the more intense weathers. taking that snow train for instance the strengths might be like: 1-2-3-5-2.  higher is stronger-- more snow. we make it arc in and out. blizzard picks up and falls off. the difference is subtle but there. 
• the computer will do some math based on the time the pattern was assigned and the current date in order to figure out which 8 hour segment we're in right now. then it checks the pattern and sees what kind of weather we've got there. using our previous made up example if it had been exactly 88 hours from our start date we'd get the slot that has snow with a strength of 3. 
• do we play the weather yet? NO, says the man in washington! one more thing to check! the weather system asks what region of reborn the player is in. our regions are: apophyll, reborn city, reborn city post-E16, tourmaline, carnelia, and 'everything else' (which is mostly chrysolia/aventurine/wasteland + some stray uncovered spots). the difference between the two reborn cities is that the pre-16 one has sun and the post-16 one has snow. so anyway we use the metadata to figure this out, i.e the thing that shows where your lil character appears when you open the town map.
• ok so we have our region, what does that matter? we're going to grab another array of numbers based on where we're at. this array contains two key values: it has a value for a type of weather than is each region's default, and it has values for how much that region likes each type of weather. that value is a modifier that's subtracted from the strength of the value. now depending on our result one of several things will happen:
• if after applying our regional modifier, the strength is more than 0, then congrats! we get to play the weather! it snows with that remaining strength. 
• if our strength value is exactly 0, then it fizzles out and no weather plays at all. #NormalizeClearSkies
• if our strength is -less- than 0 then the region has decided it actively dislikes the provided weather, and therefore is going to reject that reality and substitute its own. the negative strength value is multiplayed by -1 making it a positive integer, and the weather as strong as it was hated, and then it also changes the -type- of weather to the region's preference. this is how i get away with having sun and snow in our normal rotations without making it snow in apophyll or tourmaline, or be sunny up in carnelia's coldlands.
• so example: we've got our snow-3 from before. we're in carnelia, which is the region that likes snow the most, so there's actually no modifier. it'll just play the snow-3 happily.
  but then if you fly to reborn city, reborn city does not like snow especially pre-16 so there's a modifier of -5. the strength becomes -2, so reborn city is inserting its own weather. incidentally reborn city's own weather is no weather, so we're not going to play any weather at all.
  now let's say we fly to tourmaline. tourmaline also dislikes snow so it has a modifier of -5 as well. our snow-3 becomes -2 so tourmaline is going to overwrite it with its favorite weather, which is sandstorm, and that -2 strength will be flipped into a strength of 2. therefore tourmaline will display sand-2.
  with this system i can keep the same weather pattern consistent in all places, but applicable to each of them. 

so that's about it for how it works.

now that's all good and well but why is it so gosh darn broken in E16? well. haha. 

basically, here are the main problems with E16's weather:

• it is always raining
• it is never windy
• even if we call wind it uses the storm weather animation but without the lightning
• sometimes events don't properly update for the weather that's very clearly currently active and sometimes the wrong events activate
• seriously why is it always raining pleasestop

so that's kind of a messy. whycome this???

...is what i was asking until marcello and i took a closer look at it a few days ago. he was ready to spend a good couple weeks figuring out what was wrong with the system and hammering it back into shape. 

in the end the fix didn't take even an hour because all of those issues stemmed from the same root problem. and that problem was......................................

there were two weather patterns in the code that we didn't even know about. 

what? how?
idk dudes. i don't think any of our devs added them but i'm also pretty sure they weren't there when i started using essentials. it is possible they were added in an update to essentials and i did not know about them though i have not confirmed this. anyway i had no idea they were a thing. 

the patterns were blizzard, and-- ah, here we go-- heavy rain. 

okay, so each weather has a value assigned to it. clear is 0, rain is 1, storm is 2, etc. wind is 6. and wind is the problem child here because it was refusing to exist and using the wrong animation even when i forced it. so it's value 6 because i assigned that to it back in like episode 5 whenever wind was added tbh because the highest weather value at the time was 5 and so for a while the scripts and events all agreed and that was fine

so then we have these new weather patterns. when they were added in, how they were added in-- who knows, but they also got values. blizzard is 7. we're never going to use this because the animation is terrible. heavy rain's animation is nothing to write home about either. it's just the stormy animation with no lightni-- wait a minute

heavy rain was assigned to value 6 because wind didn't exist in the scripts before. i made it up and the update naturally did not know i made it up so it put heavy rain on 6 and booted wind to 8. meanwhile the new weather system, having been written by people who did not know heavy rain existed in essentials, pointed all of the wind cues to value 6.

marcello was upset with me. i was upset with essentials. we agreed that there's no point in pointing points and just switched wind back to 6 and put heavy rain on 8. let's go over our problem list:

• it is always raining -- explained because wind was heavy rain. now that we're calling rayquaza instead of kyogre we should be good.
• it is never windy -- check! wind is properly called now!
• even if we call wind it uses the storm weather animation -- check! it was actually heavy rain the whole time!
• sometimes events don't properly update for the weather that's very clearly currently active and sometimes the wrong events activate -- check! this makes sense because people would see the heavy rain animation and go look for the rain events, but they're not there because those events depend on the values for rain and storm, 1 and 2, and are not looking for heavy rain on 6. meanwhile the wind events still think it's windy when it's heavy rain so people are seeing those show up in what is very clearly rain. no longer a problem!
• seriously why is it always raining pleasestop -- well. does wind being heavy rain really explain all of the excess with this? maybe not. the 'other areas' region's preferred weather is rain so maybe we can remove that, or maybe just tweak the numbers for the city to like rain less. but at this point it's reasonable to conclude the excess of rain was because of the bug and any further issues with it should be well within our ability to tweak to perfection. 

so there you go! amethyst liddell and the case of the winding rain is closed. 

and thank god it was way simpler than either of us expected it to be