Daily Life Project (part 1 - time and lighting)

It feels a bit strange that, after all this time, I finally get to repost the script that started this blog, a long while ago, long before I had made myself a name - that is, long before the ACMS. :p The loop is getting looped, and it feels like a nice parting gift with all of my faithful RMXP followers.

The Daily Life project initially is my own attempt as a day/night system. If you would like a day/night system and...

• you think most of those look ugly or otherwise unrealistic
• you would like to control the flow of time
• you would like to make variations on events based on the time of the day or day of the week

OR

• if you would like a realistic, dynamic lights system

Then it is exactly what you need.

---

Features

---

Event-controlled time.

• time does not advance automatically - unless you command it to with a parallel event. You get to control how time changes with game variables, down to the second.

• a wide range of variables and switches allows you to set event to appear/occur only at specific times - specific hours and/or days in the week and/or months and/or years...

Natural-looking day and night.

• progressive transition between dawn, day, dusk and night

Progressive change in daylight on a summer solstice

• progressive change of daytime duration according to the season (daytime lasts longer in summer)

Progressive change in daylight on a winter solstice

• fading overlay effects according to time of the day (sunbeams at noon and haze at night)
• events named "Shadow" automatically fade out as night gets closer

• day/night can be disabled when inside closed spaces, and luminosity set manually

Closing the curtains forces the luminosity to zero despite the fact it is noon

Realistic, dynamic lights

• any number of light sources can be set and blend naturally into each others

• real-time calculation allows light sources to flicker and even move around
• adjustable radius and strength
• lights tear through darkness but do not overlay ambient light

---

Known issues

---

• This script is known to make the interpreter lag, depending on the user's machine. It is not the script's fault. RPG Maker's graphic engine has such poor performances, that how the script works will necessarily confront it to its limits sooner or later. It is pointless to ask me for an optimization, since there's absolutely nothing more I can do to address this issue. However, here are a few guidelines to avoid lagging:

1. More light sources mean more calculations - do not make too many of them
2. Map scrolling requires recalculation at each frame - avoid making maps that exceed the screen size
3. Having light sources flicker or move around also requires frequent reclaculation - do not overuse those effects
4. The darkening overlay which gives the illusion of night is arranged in small blocks. The DARKNESS_PRECISION constant in the Constants - Custom entry controls the size of said blocks - the smaller they are, the better the quality and the worse the lagging. It is set to 2 by default, which I found to be the best quality/performance ratio. Setting it to 1 will make the overlay appear blocky but will cut the load in quarter.
5. The DARKNESS_FRAME_SKIP constant in the Constants - Custom entry allows to force the calculations to wait for a set amount of frames, thus effectively cutting the load. It is set to 0 by default (no skipping) but you can set it to small numbers (like 4 or 5) so that the overlay does not appear too jumpy, and you gain a little performance boost.

---

Download

---

The following link provides a script bundle meant to be used along with the Script Manager. Terms of use and instructions are provided within. Please credit me if you use it in your own project. A nice comment is always appreciated.

Download MP Daily Life (10 KB)

The following link provides a demo for said script.

Download Daily Life Demo (1 MB)

The Variables Binder or How I Made Something Easy Even Easier

Faithful users of my works know that I like event-controlled system, when appliable. For example, my Balloon Messages System relies not on clumsy commands input in messages or stuff like that, but rather on regular switches and variables, which are easier to handle. Those switches and variables are then read by the scripts which in turn do their job. To achieve this, the scripts have to know which switches/variables were appointed to this or that purpose, because from one project to another, a same switch/variable may very well have a different ID - like, if I use switches #2 and #3 in my demo, they might already be allocated, and you'd like to use other ones instead.

Up to now, you had to manually set up constants for that purpose. You had to choose free switches/variables in your project editor, then you had to open the script where the constants were set and replace each of them with the ID you'd chosen, and then it was all cool and easy. That was, until I decided I was too lazy to do the manual part anymore. I decided it was not that hard for the scripts to find the matching switches/variables after all and they could very well do it on their own. From that decision, a new script was born. Behold... here's the Variables Binder!

---

So what does it do?

---

Basically, automate the process of binding switches/variables as set in the project editor with the scripts. Say you install the Balloon Messages System to your project, you run it just after, then return to your project editor and poof! a couple of variables and switches which control this system have installed themselves in free slots, saving you the trouble of naming them manually. From then on, those switches/variables will automatically be recognised by the script you've just installed and you don't need to worry about that anymore. So, in short, it's simple as 1-2-3.

---

Any recommendations?

---

The Variables Binder will never ever mess with switches/variables which already have a name so it's absolutely safe to use on a project you have already started a while ago - however, it decides whether a switch/variable is free based on whether its name is empty or not, so make sure all of the switches/variables you're using at this time have a name, otherwise you could get surprises.

You can see that your newly named switches/variables have got a tag before their name. This makes it easier to see which variables group together, but it also works as an identification code. That is, you're free to rename the switch/variable as long as you keep its tag intact.

If you were already using one of my event-controlled scripts prior to the arrival of the Variables Binder, please make sure the variables you've set manually have the exact same name (without the tags) as in the original demo, since when the tag is absent, the Variables Binder will identify them based on their name, and automatically add the matching tag - so you end up with the exact same settings as if starting a fresh new project with the scripts' latest version.

If the switches/variables have not been installed prior to the Variables Binder's first launch, it will claim the first free slots it can find, so you might want to have several of them in a row so that they don't get scattered. Also, make sure you have set the maximum number of items so that there's enough room for the newcomers in the first place!

---

What if I still want to set the variables manually?

---

If you're not satisfied with the Binder's automated setup for whatever reason, there's nor problem at all. Just cut/paste the name of the variable you want to move to another slot. Since the setup is dynamic, the script will recognize the newly named variable as if it had set itself up on the next time you run the game.

---

Where can it be found?

---

The Variables Binder is part of the latest version of my Common pack. You should re-download it to ensure compatibility with my future scripts.