MV - Community Lighting MV & MZ

Looking back, the project really was a learning experience for me, that whole massive change to the code definitely put it “above my pay grade” at the time. So updating was a real challenge at best. In hindsight I should have required people to put comments in their code so at least parsing through it wouldn’t have been such a challenge. Definitely something to think about if I ever start another group project.

I do think my interest in this project really started to fade more when I stumbled up on a way to make shadows based on the images themselves. But it required essentially a completely different method to do so, so it wasn’t really compatible with what we had here.



Is the only example of it I bothered to record though. I never did figure out the math to shift the shadows based on time of day or anything. It was definitely in the proof of concept phase.

I suspect it would be too complicated for the average user here though, so it wouldn’t really garner much overall interest. Probably not worth continuing the project since I don’t even use the engine any more.



Thanks, life’s definitely on the up and up these days for me. And no worries take your time, it’s been sitting around in limbo for pretty much ages anyway. So it’s not like it will hurt to let it sit a bit longer.

I have no problems with you working on it to fix the problems it has. I have one request... Don't change anything that is in it now. I'm using the most recent stable version and it's working really well for me. After I worked to get it to work for me.

I might stick with this version unless there is a major improvement to performance on bigger maps and/or a really cool new feature or two that I think would enhance my game's atmosphere.

Yeah I don't intend to remove any features, just get the codebase back to something mor ein line with how other plugins are made. That's also why I want to have some things to add/improve before I post any sort of updated version. The current version works just fine for end users, it's just dogshit for those of us who have been working with it for awhile on that end, and want to adjust the code. ;)

Just a quick question... I know this plugin is based on another plugin, but it seems to be rather inefficient with the FPS randomly on large and medium maps. I remember reading a comment some time ago that mentioned that the code would be more efficient [or something] if the code was rewritten, but it would mean getting away from the other plugin and its compatibility with it.

My question is... If the code was to be rewritten and broke the compatibility with Terrax's plugin would that mean that all the features that are there now would change as well? Like the light on/off, smooth lights, etc.? These are things that I don't think Terrax's plugin had. Would they have to change to fit the new code, thus breaking all the work someone did with the Lighting Plugin?

I have hundreds of lights throughout my game... most of them have different features operating on them to allow them to do advanced lighting things [Glowing enemies where the glow vanishes when you defeat them, light switches that turn on/off, etc.] but the FPS drop from 140 to 30 whenever I enter a room with the lighting plugin operating. Sometimes the FPS drops to 3 FPS randomly whenever I enter a map that is bigger than 30x30.

I do mean randomly. I can enter a large map on one play-through, get 20-30 FPS, and then get 3 FPS on another without changing anything.

I'm wondering if rewriting the code as mentioned before would fix this rather annoying bug. But I would rather not have to go through all the lights in my game to fix the broken note tags if it does.

Just out of curiosity.

EDIT: I guess that wasn't as quick I thought it would be...

I think at this point, any "compatibility" with terrax's plugin is unnecessary, especially in MZ since that was an MV plugin.

I was thinking the same thing, but I also didn't want the plugin to change to the point that I would have to spend hours "fixing" the lights in my game.

But would getting away from Terrax's plugin help with the FPS issue I mentioned or is that something else? I remember reading a comment that it could help with it at least.

The only thing the Terrax compatibility did was enable anyone using his plugin (and thus, crappy implementation of note tags...as in, just using the entire note field instead of proper tags) to not require changing their note fields around. This is of course completely irrelevant for the MZ version.

Anyway, after looking at the plugin and all the damage @snaphat did to the existing code to make it completely unrecognizable, even 2 years later, still makes me a bit angry. I'm unsure if I want to try to fix it so this project can continue in some form, or say just say screw it and suggest people either use it as is, or switch to one of the other lighting plugins out there.

So after giving it some thought (and reviewing the code a bit) I've decided on a different path. I've been working on a split-off version for MZ based on version 4.4 that isn't going to follow the "anyone can contribute code" model, although I'm open to suggestions for things to add, which I'll then add myself if I think they'll add to the plugin in a useful way. This should prevent a few issues:

- No more incidents like the one I've already complained enough about, and more consistent code in general.
- It'll keep the contributors/credits size for this plugin from getting any more massive than it already is. Speaking of that...

One thing I'd like to do, but not sure if I *can* is change what people are required to credit in their game if they use this plugin. Currently it's "list all of the contributors" which I've seen some people say is offputting, and I get it. Use some MOG plugins, and you credit Moghunter, use some YEP plugins and you credit Yanfly. With Community Lighting, it's one whole huge list.

Anyway, what I'd like to do, if that's even doable, is change the in-game credit requirement to "Community Lighting Team." All individual contributors would of course still be included front-and-center at the top of the game's help comment.

That said, so far I've done the following:

- Cleaned up a lot of the older code--converting snake_case and completelylowercase variables to camelCase, moving random orphan functions into the IIFE, etc. Things to make it pass the JSLint test.
- Stopped the weird Game_Variables object abuse. Now it's all on Game_System, but the individual properties are now stored in a single object on $gameSystem.
- Broken up the HUMUNGO function (you know the one!) into several more clearly-categorized functions for easier management.
- Implemented my own version of smoother lighting that doesn't add an extra bitmap layer (!) like 4.6 did. The lights themselves looks slightly different, but this method is still better than the original method and keeps the overall light size closer to the original method instead of shrinking it.
- Unlocked the blend modes for lighting--now the developer can set the blendmode for lights, region blocks, and the overall lightmask layer. (this is probably the only thing end-user developers will care about so far.

Still on the to-do list:

- Fix features that are half-done or don't even work. This is where (anyone reading this) should mention things that don't work in this plugin, or have never worked, so I can get them working!)
- Update plugin parameter system to one I use in my other plugins (it's a lot easier to deal with!)
- Add a more modern flashlight. I'm probably not going to use Snaphat's code here, either. All that weird extra utility function stuff he dropped in makes it too more of a pain.

Is there going to be an MV version in the future?

Can I use this for the version I currently have? It would be easier...

Do any of these changes make it run better on larger maps?

It sounds like you are going for it on this and I appreciate that. I hope you can find time to work on an MV version. Unfortunately, I'm too far along on my game to try and switch to MZ for it. Especially when most of my plugins on MZ are trapped behind a paywall [I got most of my plugins before they went to paid]. It's not feasible for me to switch to MZ at the moment, but I would still like to have a better working COmmunity Lighting plugin...

The version I have works fine for most cases, it's mostly when I'm on a large map is when the FPS drops.

So, if you find the time, could you consider taking a look at the MV version's code? I Can provide the code for the most stable version I've found if you need it.

The problem is that MV and MZ, despite many similarities, do certain things (plugin commands, windows, certain pixi functions, etc) very differently. I'm not planning on an MV version, but I'm not going to outright say no, either. Problem is I just don't use MV anymore, so there's not a lot of motivation for me to give it attention.

I still don't even know if I can do this for the version I'm working on. For the time being, I'm going to say "no." :(

Some should. One thing you can try though is the "set active radius" plugin parameter to prevent lights from turning on if they're too far away from the player. Not sure if that'll work or not, I haven't looked at the large map lag issues just yet, although it is on my to-do list since it's one of the plugin's major flaws.

This is one of those cases where, as much as I'd like to, I don't want to make any promises I can't keep. At their core, they're similar enough that it's feasible though. So maybe but that's not a promise.

I'll take that as a tentative "Maybe", with hope and a prayer for the possible future. :)

I have set that parameter to as low as the number can go without being noticed in the game. It works as intended, but the lag on larger maps is very noticeable. I have somehow managed to keep the FPS drop to 50% if I cap the game to 60FPS [around 30FPS]. If I uncap the game, the map still drops my FPS to around 30, but the difference is more noticeable since the FPS is usually around 140 uncapped.
*I'm keeping the game capped at 60 since the cutscenes and skills run better and the game just generally seems to work better.

So on my smallest large map [92 x 80] the FPS drops to 30FPS... I have larger maps and walking them seems to get roughly the same amount, but I have yet to populate them with lighting and other events so I can't tell if the FPS will drop anymore after that.

I see little to no drop on FPS for maps that are 50-60 or below [my 34x65 map has practically no drop]

I'm not sure what's in the Larger map that makes it drop so dramatically, but I suspect it might be the number of events overall, not just the number of light events... But I'm not an expert on this just my trial and error analysis.

At the moment the FPS drop is tolerable if not annoying... But if it drops anymore then I'm going to have to figure something else out.

@firestalker
I'd say it is quite easy to drop your fps around 30 in MV(not sure about MZ), and when I press F2 twice it shows 18ms or so.

Yeah, I see periodic dips in FPS whenever I'm transferring to a new map or battle transition. sometimes during conversations whenever the text window pops up, I'll drop like 10 Frames or so for a second.

Those things don't bother me... It's when the FPS drop and stay dropped that gets me. Which only happens on those maps. Every other map [that I've tried] stays at a consistent 60 FPS. Those are the only maps that drop to 30FPS.

As I've said, it's tolerable for now, and I can usually offset the slowdown with the "dash" button. I'd just like it if I didn't have to do that.

The FPS drop on the large maps is the only complaint I have of the MV version, in fact.

So, @Aesica, if you find time to work on only one thing for the MV version may I suggest that one?

Everything else works pretty darn good, to be honest.

It sounds strange. @firestalker , do you experience any fps drop in any of the demo maps?
My current pc uses i3-4160 CPU (3.60 GHz) and there's no fps drop(render time is somewhere between 1-3 ms).

Actually I don't know... I haven't been on the demo project in years... I got the plugin back when it was still a version 2 or something... I've upgraded since then to the latest stable version but I haven't been on the demo since I download the original all that time ago.

I just tried the Demo and there are no problems with any of the maps there.... They are all small and the lighting is in relative small form so my computer was able to handle it great. None of the maps there are big enough to cause a problem though...

Aside from map size, how big is your light sources, and how many do you use?
For exaple, if I copy the light source evetns in the map Light gallery a few dozens of times, and the game still runs at 60fps.
I don't think changing map size alone will cause fps drop.

Ah fair enough, the whole community experiment was interesting to say the least. I can understand why you’d want to drop that.

As for the license… It’s MIT so per the license you have to keep the copyright stuff. Personally I’m fine with being called the Community Lighting Team. But I don’t really know if it’s my decision given the way the MIT License is worded. I mean you’d have to get everybody who contributed to agree to a name change from how it’s written. At which point it would be Terrax and the Community Lighting Team.

But it was Terrax who established it as a MIT License, so it’s not like I wanted it to be like that in the first place. Then again it’s also why we were free to build this plugin off of his. So hard to complain now I guess.

But really it’s also not a challenge to copy and paste one line of text either. So anybody who wouldn’t use the plugin over that has no business being game dev, which is an excessive amount of work in general. I have little sympathy for laziness like that.


What's really funny is in one of the earlier versions I broke up that huge code blob and made it modular. You can see it in the Mini version... But then someone put it back one version later and I was like... “Nah I'm good, I’m not doing it again.” It’s a definite flaw in the community design philosophy.

Sounds like a lot of work has been done though, I’m just glad it’s you and not me doing it. :LZSwink::thumbsup-right:

On the first map that drops the FPS, I have 63 Light sources, each one varying in size from 150 pixels to 300, with smooth lighting. The "Lights Active Radius" is set to 25 tiles. After some experimentation, I found this is the lowest number of spaces I can use and have the lights look like they are always on without having them always on.

With the Light Active Radius, I have maybe 6 or 7 lights on at a time on the map... But I think the plugin is constantly cycling through all the lights [whether they're on or not] to see if they're within the radius. This is why I think that the larger maps are slower.

Okay that's what I was afraid of. Yeah some of these people (Terrax for sure) are completely unreachable, so I guess we'll just stick with the huge credit list.

That said, the free-for-all version could still continue to remain as is if anyone else wanted to run with it. What I'm working on would just be my own curated branch, kind of like the mini version is with you.

Necessity makes fools of us all. I knew I'd eventually need to get a good lighting plugin because I still do things in MZ, but there just aren't a lot of good lighting plugin options. So here I am. ;)

You know, your lag issue might be something else. I just made a 256x256 map and it runs at 60 fps, but it also only as one event and light source. Does it still lag with other plugins turned off? Are there a lot of events and light sources, even if most are "off" due to active radius?

@firestalker Oh I see, but I don't think cycling through 63 events is a big impact to cpu. We are drawing millions of pixels per frame.
300 is 3.75 times (and 14 times in area) bigger than 80 pixel which the demo uses for small light.