RMMV Community Lighting MV & MZ

[Aesica]

i really don't see the flickering on the player radius :/

I'm not so sure the player fire ever really worked to begin with. I'll take a look at some point though. Perhaps today.

Is there a way to adjust amount of flicker a fire can have?

So you can make a big fire have more flicker than a small campfire... for example

Unfortunately no. SetFire applies to all fires

---

Edit: Player fire flicker fix is up at: https://github.com/Aesica/community_lights

Assuming this was for the MV version. I didn't touch the MZ one yet. Sorry this came in as an edit, but I'm not sure if I'd be breaking any double-post rules.

 

[ImaginaryVillain]

Doh I guess I should have posted my update to the GitHub instead of putting it here to test. Oh well, I approved your changes on the Github and at some point I'll add the other changes I made to that version.

edit: The GitHub version has been updated with the assorted changes I made for both the MV and MZ versions. The MV version still includes the @Aesica changes (which work great BTW), I didn't push them to the MZ version though since I have no means of testing it.

 

[KaYsEr]

This version for MV changes how coordinates are calculated and should fix the problem of lights not following events during their move routes. If nobody finds any problems I'll see about pushing it to the MZ version as well.

@ScorchedGround Give this version a test and see if it works. I ran it through the demo and couldn't find anything that didn't work. Still it never hurts to have multiple testers.

@KaYsEr As I have redone how coordinates are calculated. I did some minor testing with UltraMode7 and didn't see any problems. If you end up testing it let me know how it goes.

Edit: I accidentally edited the wrong version without the Lights Active Radius option, so I reuploaded the correct version.

Great job you fixed it! I only quickly tried and it seems to be fine. I've been using OcRam recently though, because of a rare visual glitch when using Terrax (and this one then), but it's very specific to my situation and I doubt anybody will encounter that kind of glitch anyway.

You need to use an ABS and put lights on enemies to see that kind of problem, lights that don’t properly disappear when an enemy die for example.
It might be caused by some kind of “overlapping of IDs” or something similar, and maybe OcRam uses a unique instance for each light and this is why it works, idk.

But at least as it is, the community lighting plugin is fine for a regular use with Mode7 so this is cool.

 

[ImaginaryVillain]

Interesting. So much depends on how an ABS handles event info, it's hard to say what causes that issue. I'd need to see the error in action to have any idea. Glad the other error is fixed though. I figured that it would do so, Terrax had a note in the original plugin talking about how the coordinates needed a recalculation because they did something weird with the parallax. So even he knew something wasn't right.

 

[KaYsEr]

If you're curious to see that glitch in action, the fastest way would be to take the Mog "Chrono" Demo, simply add Terrax/CL in the demo and put lights on enemies like slimes, you'll see the lights will remain after killing them.

But yes MODE7 is now ok. One remaining little glitch would be that the "player light" is still disappearing (and reappearing on the opposite side haha) when going too close to the edges of a M7 map when the camera no longer scrolls (if you use the function <UltraMode7_BorderHorizontal:8> to limit the scrolling on a 30x30 map for example) but it's something you can prevent through level-design so it’s not that big of a deal. Good job everybody involved with that plugin.

 

[DarkSearinox92]

Edit: Player fire flicker fix is up at: https://github.com/Aesica/community_lights

You are amazing ç_ç you all. Thank you so much!

 

[Aesica]

I didn't push them to the MZ version though since I have no means of testing it.

That's okay, there shouldn't be any changes to the MZ version, at least not on my end. I only fixed the MV version.

 

[DarkSearinox92]

Ok, guys... please, listen to me because i think that i found a very strange problem.

In my little game I am using many many plugins. An annoying problem that I run into every now and then, is that sometimes, when I switch to a new scene, for example the main menu or the save menu, or a bit heavy map transfer, I run into an annoying problem , that is, the game starts not running smoothly as I move around the screen, and if I go to see the fps, it gets stuck at 30.
Magically, if I close and reopen the menu, the problem is solved and the fps goes back to 60.

I've done countless tests, trying to figure out who the damned is, deactivating all plugins, and ... I don't know guys, it just seems to be this script...

WITH ONLY THIS SCRIPT: The problem appears with much more difficulty. But it happens.

With light AND yanfly, appears much more easily.

Without no plugin: Even closing and opening scenes a thousand times, it is easier to crash the game than to see the fps drop and freeze at 30.



If you try to slightly load a scene, when the screen closes, the fps remain locked at 30.


I did this test like this:

- Yanfly Core Plugin
- Yanfly Save Engine
- Community Light

A GIF for you... plese, see the link here: https://ibb.co/DLFYc0M

The map in this case is small, but if I tried to move in a scrolling map, you would have noticed the lag of the locked 30fps.



Many times the whole game crashes if you close and open quickly either the main menu, or the save menu (Even without plugins, this is not normal, but... it's rpg maker, i think that it's a bug :/ ). But the fps block, apparently, only freezes me if I run the test with the lights script and I repeat, it often happens if you start to weigh down the scenes themselves, such as menus.

For achieve the problem fastly, you have to quickly open and close, for example, the save menu, with the save core engine that "It weighs down the save screen a bit, with drop fps" (perhaps using an event with the command "open save screen" and then pressing esc. Just like what i did in the GIF.
You can even open and close the main menu. It also happens in that case.

Now, I don't care if the game slows down for an instant.
I am interested in understanding why the engine blocks the entire game at 30fps, and it seems to do so when the community light is active.
I have done countless tests without the community light and the game has always crashed, but without ever getting to the block of the fps.

I think this thing triggers when the game gets heavy for an instant, doing certain things.
Now this is a way to trigger the problem, but during the various playtests, I have often noticed this problem, without obviously having to close and open the menu a thousand times.

Another interesting thing: Initially I was testing the scene in a room with 4 lights inside. And it happened.
I tried to create a new area, placing only the crystal light and I could not get the problem out.
The moment I added the three lanterns, the problem started popping up.

Now, you will say: but who opens and closes the menu so many times ...
Correct, but this problem sometimes happens even by simply opening and closing a single window, or when moving to a heavy map, with parallel animations or processes. I remember this happening many times in the past, and I used the Terrax script.
This is just a way to show you how it turns out, forcing it and going to find out just what happens.

Does something come to mind? I really don't know what to say.
Do I know this is a strange enough problem, and perhaps even difficult to replicate? Try it ...

 

[ImaginaryVillain]

A lot of people don't realize that whenever you open a menu, save or start a battle.... MV/MZ actually changes the scene. Then when you close it quickly reloads the map scene. Hence the sudden drop in frames briefly. Unfortunately MV/MZ is quite terrible about clearing it's memory footprint when not completely transferring maps. So I suspect it's stacking extra instances of the lights faster than the memory is emptied.

Also a lot of people just accept Yanfly Core as a 100% positive thing. Keep in mind it makes considerable changes to a lot of MV's core functions including stuff such as how scenes clear their memory, imposing a try/catch on all script commands (causing massive slowdown if they're used frequently), and altering how events interact based on their Z coordinate... Just to name a few.

I'm not badmouthing it though, Yanfly's work is great. Just alerting you to the fact it's not a free roll, there is a cost to it's usage. In my game I ended up having to stop using his Self Variables plugin because his core plugin was causing a 15-20 FPS drop when enabled (with none of his other plugins enabled).

So my advice is to try the same experiment again but with just Community Lighting, and no other plugins to see if you get the same results. If you do, the problem is either with your event setup or the plugin itself. If not the issue is in how the other plugins handle stuff.

 

[DarkSearinox92]

A lot of people don't realize that whenever you open a menu, save or start a battle.... MV/MZ actually changes the scene. Then when you close it quickly reloads the map scene. Hence the sudden drop in frames briefly. Unfortunately MV/MZ is quite terrible about clearing it's memory footprint when not completely transferring maps. So I suspect it's stacking extra instances of the lights faster than the memory is emptied.

Also a lot of people just accept Yanfly Core as a 100% positive thing. Keep in mind it makes considerable changes to a lot of MV's core functions including stuff such as how scenes clear their memory, imposing a try/catch on all script commands (causing massive slowdown if they're used frequently), and altering how events interact based on their Z coordinate... Just to name a few.

I'm not badmouthing it though, Yanfly's work is great. Just alerting you to the fact it's not a free roll, there is a cost to it's usage. In my game I ended up having to stop using his Self Variables plugin because his core plugin was causing a 15-20 FPS drop when enabled (with none of his other plugins enabled).

So my advice is to try the same experiment again but with just Community Lighting, and no other plugins to see if you get the same results. If you do, the problem is either with your event setup or the plugin itself. If not the issue is in how the other plugins handle stuff.

Hey Imaginary, i understand what you say. However, i tried. If you look, i wrote this:

WITH ONLY THIS SCRIPT: The problem appears with much more difficulty. But it happens.

So, it happens even without yanfly core, and with only light script.

And, with yanfly script, it happens most frequently.

How is it possible that it stuck fps?
It almost seems that something freezes and fails to bring back to 60 fps...



I found a nice comment in a thread:

For people coming here after the v1.6.1 update: it's most probably the sound. MV runs at 60fps but when it needs to load a song on the memory that the program sees as "too big" (>45 sec.) it automatically jumps to 30fps (and stays there till after the map is changed, MV thinks your PC is too weak). Tomorrow I'll try to find a solution, the standard audio lag bug fix that streams the audio instead of loading it didn't work. If you loaded the map without any audio check your on map parallel events (should be as less as possible since they cause low fps and high input lag) and pictures it's trying to load and lighting.

Now, i tested it in that room without sounds. However, is it true that MV stuck fps to 30 if he think that the pc is not good? Because if it's in that way, maybe this script interferes with this thing and when you go to weigh so much on the functions, for a moment it goes crazy and sends the game to 30fps fixed...?

 

[Aesica]

It sounds to me like MV is detecting what it thinks is a lower end PC based on a lot of factors (number of active objects in memory, audio, images, active plugins, other things it has going, etc) and that means it's beyond the scope of what this plugin can (and should) be doing. Try using a bunch of plugins besides this one and see how easily it happens.

 

[DarkSearinox92]

It sounds to me like MV is detecting what it thinks is a lower end PC based on a lot of factors (number of active objects in memory, audio, images, active plugins, other things it has going, etc) and that means it's beyond the scope of what this plugin can (and should) be doing. Try using a bunch of plugins besides this one and see how easily it happens.

I realized that it happens very easily if I activate them all together. it happens often.
The final touch was that during a test I tried to change the classic 30 fps rpg maker animation to the 60 one and instantly on the save point and, after closing the save scene, it capped the fps to 30. Suddenly. I got nervous and started doing extensive tests on the case. But in fact I noticed that only already with 3 plugins, in a not too difficult way, it happens.

In the GIF, I only had the three plugins included in the post active.

Could it be that rpg maker feels that the computer's ram is quite full and then scales that way? Because everything else is fairly recent.

The cpu is an i5 2500k, the video card is a gtx 960. The ram is 8 gb of which 6 are almost always full.

The only test I can still do is to enable anything, without the lights script... but as i said in the first topic, the problem popped out even with only yanfly core and save core. So it's almost useless to try to activate all the others too, if it already does so.

But the strange thing is that I don't have any slowdowns while playing. It only happens sometimes, to scene changes, and the moment I simply open and close the menu, the fps goes back to 60 as if nothing had happened. :/

 

[ImaginaryVillain]

A lot of people really misunderstand what's going on behind the hood of MV/MZ. As I talked about earlier, when you open a menu, MV/MZ is actually changing the scene. Then when you close it it's quickly reloading the map... Yes the whole map. So by opening a menu then closing it quickly, over and over, what you're doing is loading the menu scene, loading the map scene, loading the menu scene, etc.

Normally this is fine. But what we need to talk about is how Javascript handles memory. Javascript maintains info in memory as long as there is any reference to it. I won't get too deeply into how each type of variable, function, etc is handled. But suffice it to say, MV/MZ doesn't clear it's references very well, so much information is maintained until a map transfer. Where it actually does a pretty good job of clearing the memory.

Now let's talk about why MV/MZ lags so easily even though it's actually not even using much memory or processing. Javascript is a single core language, it doesn't divide up instructions and split them amongst all of the cores a processor has. Instead it takes it's ever increasing set of instructions and dumps it onto a single core. Sure you processor might be amazing, but unfortunately only the strength of a single core will matter.

Now there are workarounds, webgl for instance passes it's instructions to the GPU. Javascript also has "workers" which can divide the task up to multiple cores. Or the sudo answer that MZ "kind of" uses, the ask/promise system which still uses one core but waits until a task is finished before progressing.

I bring these up because essentially the situation you're setting up is creating a set of instructions that's too great for a single core of your processor. So stuff slows down, not due to any particular limit in MV (BTW it's up to version 1.6.2, not 1.6.1 in that thread)... But instead too much for a single core of your processor. And that's the abridged answer for why MV/MZ lags when it looks like shouldn't.

As for why your game lags during testing but not deployment... That is two factors. The first is the obvious, the editor is opened and thus it's using some amount of resources on top of what your game normally uses. However the main reason is NWJS. During testing MV uses the version of NWJS in the nwjs-win-test directory. Where as deployment uses the version in nwjs-win directory. Both of which can be found in the home directory of your MV installation.

For what it's worth, you can actually upgrade both of those to increase your game's performance. Though later versions of NWJS also increase your game's deployment size. So it's not entirely a free roll.

 

[DarkSearinox92]

A lot of people really misunderstand what's going on behind the hood of MV/MZ. As I talked about earlier, when you open a menu, MV/MZ is actually changing the scene. Then when you close it it's quickly reloading the map... Yes the whole map. So by opening a menu then closing it quickly, over and over, what you're doing is loading the menu scene, loading the map scene, loading the menu scene, etc.

Normally this is fine. But what we need to talk about is how Javascript handles memory. Javascript maintains info in memory as long as there is any reference to it. I won't get too deeply into how each type of variable, function, etc is handled. But suffice it to say, MV/MZ doesn't clear it's references very well, so much information is maintained until a map transfer. Where it actually does a pretty good job of clearing the memory.

Now let's talk about why MV/MZ lags so easily even though it's actually not even using much memory or processing. Javascript is a single core language, it doesn't divide up instructions and split them amongst all of the cores a processor has. Instead it takes it's ever increasing set of instructions and dumps it onto a single core. Sure you processor might be amazing, but unfortunately only the strength of a single core will matter.

Now there are workarounds, webgl for instance passes it's instructions to the GPU. Javascript also has "workers" which can divide the task up to multiple cores. Or the sudo answer that MZ "kind of" uses, the ask/promise system which still uses one core but waits until a task is finished before progressing.

I bring these up because essentially the situation you're setting up is creating a set of instructions that's too great for a single core of your processor. So stuff slows down, not due to any particular limit in MV (BTW it's up to version 1.6.2, not 1.6.1 in that thread)... But instead too much for a single core of your processor. And that's the abridged answer for why MV/MZ lags when it looks like shouldn't.

As for why your game lags during testing but not deployment... That is two factors. The first is the obvious, the editor is opened and thus it's using some amount of resources on top of what your game normally uses. However the main reason is NWJS. During testing MV uses the version of NWJS in the nwjs-win-test directory. Where as deployment uses the version in nwjs-win directory. Both of which can be found in the home directory of your MV installation.

For what it's worth, you can actually upgrade both of those to increase your game's performance. Though later versions of NWJS also increase your game's deployment size. So it's not entirely a free roll.

First of all, thank you very much for the valuable information, many of these things I just did not know.

I wanted to tell you that the tests I did were only in the testing phase and not in the deployment phase.

Second, to trigger the problem, yes, in this case I have opened and closed the menu many times. But as I said in the previous posts, with all the scripts active, it sometimes happens to see it even during the normal game. Not always huh! But randomly, EVERYTHING, it can happen. As I said, for example it happened immediately, when I tested a simple animation at 60fps instead of one at 30, before opening the save menu. Once closed, pam. I see the game drops to 30fps and crashes there.
But the second time that i tested it, in the SAME SITUATION, it didn't happen!

Now I want to try to increase the ram, so as to keep it a little more free. As for the cpu, I really don't know. I would like to try to run more tests.

In the end, here the real problem is only MV which records (perhaps due to a drop or a sudden heaviness in loading the map) that the pc is weak, when it is not true, and limits the fps to 30, not making them go up anymore automatically to 60. This is the real problem.
Do you think it is possible through a script to remove this automatic function? I speak in ignorance.

 

[ScorchedGround]

@DarkSearinox92
It might be worth to open a new thread about this topic. Considering this is not entirely about this plugin anymore. Also more people might be able to tag in to the conversation about this.

 

[Moon_Haven]

Hello! I'm running the day/night cycle with this plugin. What is the proper way of keeping the clock running, without getting the lighting effect? For instance: when characters enter a house, I don't want the day/night lighting to affect the lights inside the house, but I still want to have time moving forward.

Edit: I looked into the demo sample and couldn't find a way in there, as it seems time is stopped when getting inside a building.

Edit 2: Worked on this, I'm stuck and I need help if anyone would be so kind? I'm unable to find a way to set the time of this plugin using variables. All I seem to be able to do is set time with hard coded time.

Edit 3: I found a way to make it work. After figuring out that you cannot pass a variable to a plugin command, I dug into some archives and found that Yanfly had made a specific plugin just for that. I've implemented it and it works as intended. I'll leave the thought process below in case someone is looking to do the same.


This is what I did:

When entering a building:
1- Copy Community Lighting time variables to temp variables
2- Stop day/night cycle from this plugin
2- Apply lighting

Spoiler

Inside the building:
Manage time in a localized time event

Spoiler

When exiting building:
Force time change in Community Lighting plugin using variables. For this, you will need Yanfly plugin here:

Plugin Commands - Switches & Variables Access (YEP) - Yanfly.moe Wiki

www.yanfly.moe

Spoiler

 

[ImaginaryVillain]

@DarkSearinox92
Everything can be changed via plugin, as a plugins can literally just overwrite or obsolete any portion of MV/MZ's code. Though I am agreement with ScorchedGround and Aesica on this one, changing other MV stuff that isn't related to this lighting plugin is outside of the scope of what we're trying to do here. You'll want to open a specific thread for it.

 

[Monkeynugget]

Does anyone know by any chance a means of knowing whether the player is within the light?

Just wondering if there's a call check i could make before a fight?

 

[DarkSearinox92]

Yeah, thank you very much to all of you, for precious advise

 

[firestalker]

Does anyone know by any chance a means of knowing whether the player is within the light?

Just wondering if there's a call check i could make before a fight?

You use a plugin like YEP_EventHitProx... which would allow you activate an event from a distance.

Or you can use regions in the lights influence and use a parallel process with a variable that keeps track of the players region ID...