MV - Community Lighting MV & MZ

ImaginaryVillain · 2020-07-20T18:57:26+0900

Today I propose an experiment. For awhile now I've been editing and "improving" Terrax Lighting, which was originally released under the MIT License (as is Community Lighting, so it free to use across the board)... After awhile it is now thousands of lines different than the original. So rather than confusing it with Terrax Lighting by posting it in that thread with the same name, I've forked it to Community Lighting. So why call it Community Lighting? Well that's simple, and where the experiment comes in. Everybody is invited to edit this plugin (with the hopes of improving it). If you make any changes, please post your updated version of the plugin here along with your change notes. Then we the community will test your changes and see if they're better. If they are, I'll put your version of the plugin in the first post. Oh and don't forget to add yourself to the authors if you do (though don't delete anybody). The hope here is that by getting everybody involved, we will end up with the best possible lighting plugin... Or at the very least, if that fails you'll get whatever edited version I've done for my game at the time. Contributors: Terrax, iVillain, Aesica, Eliaquim, Alexandre, Nekohime1989, Snaphat Change Notes: Spoiler: Click Here 1.0 @ImaginaryVillain Rescoped all of the variables to no longer be global. Updated for PIXI 4 & 5 Removed the outdated Terrax ABS, Quasi ABS, and Mog Time stuff references. Added compatibility for Ultra Mode 7 Fixed the issue with the Lighting plugin needing to be in a specific order in the plugin list. The plugin is now roughly 800 lines shorter and much faster, at least in my testing so far. Not going to lie, I made some other changes... But wasn't noting them because I didn't know I was making this thread at the time. 1.01 @ImaginaryVillain var rnd = -Math.floor((Math.random() * 20) + 10); $gameMap.setPEmitterZ(this._eventId, rnd); Removed the "fix" for the plugin order list due to issues with other plugins. Fixed issue with Mog Character Particles giving a "Clamp" error. 1.015 @Aesica Organized the plugin parameters into logical sections Removed the redundant "Add to options" plugin parameter. It can be ommitted from the options menu by leaving "Options Menu Entry" blank Changed the casing in a few plugin parameter names to be more consistent (minor nitpick, I know) Added the option to use modern note tag syntax " " to avoid conflicts with other plugins that may also use event/map note tags. Those note tags currently break Terrax's tagless implementation Added better default day/night colors. These can also be changed in the plugin parameters now for easier customization Added a "night switch" which, if assigned to a switch, will set to true during night or false during day (which hours count as day and night are user-defined) Expanded the "Daynight" note tag in maps so you can also set the speed if desired: "Daynight 10" for the default speed, "Daynight 0" to stop time and use the current hour's tint in one go. "Daynight" by itself uses the current speed Fixed a bug where the "Daynight" tag wouldn't tint at all if the speed was 4999. Added "Tint daylight" plugin command which is essentially "Tint set [whatever the current hour's color is]." "Tint daylight" should be used instead of the "Daynight" map note tag if you plan on applying any manual tints on the map. (Daynight blocks the use of the tint command) Changed map note tag reading to happen only once per cycle instead of X times per cycle, where X is the number of events on the map (seriously why was it done that way!?) Replaced the word salad in the help section with (what I hope is) a clearer breakdown of each command/tag and how to use it. I hope I didn't leave anything out. Added a "version" property to Community.Lighting so other plugins can ask it what version it is. 1.016 @ImaginaryVillain Removed a strange debug system that ran twice per light per frame. Removed a speed test system. Restructured the code to use a switch statement and objects instead of a huge stack of Ifs. Removed assorted commented out code from the original plugin. 1.017 @Aesica Fixed a variable scoping issue introduced by the latest optimization pass. Added explanation how to set speeds via the daynight map note tag to the help section. 1.018 @Eliaquim 1. Stored the RegExp note tag into a variable for the code does not compile the RegExp every time he uses getTag() function. 2. Replace the plugin command switch statements with an array/object lookup table. 3. Optimized some for loops changing the way they are handled from this: for (let i = 0; i < tilearray.length; i++) to this: for (let i = 0, len = tilearray.length; i < len; i++) *I did not reverse the iterator order because I don't know how the plugin works, to be sure if the order matter or not. 4. Some minor changes to if statements that are redundants like: if(args[0] == 'on' || args[0] == 'ON') to if(args[0].toLowerCase() == 'on') 1.0185 @Eliaquim…

● ARCHIVED · READ-ONLY

Started by ImaginaryVillain Jul 20, 2020, 09:57 AM 1279 posts Page 8 of 64 View original ↗

Aesica

#141 Aug 27, 2020, 07:24 AM Source

DarkSearinox92 said:
I will test it!
I've another question. Now, the script, works better and it's more anti-lag friendly?
Lights beyond the screen will always working, or they are more intelligent and they popup only if they are near the edges of the screen?
Because with Terrax all lights are always ruinning, they said.

And i think that is crazy that lights run even if they are out of the screen...
Yeah, it's less laggy than the original, although I'm not sure about offscreen lights. I haven't touched that part, so unless one of the other contributors worked on it, assume it still does.
DarkSearinox92

#142 Aug 27, 2020, 07:44 AM Source

Mh, i understand... i have not lag on my pc but if i think to play it with a computer not strong or a phone, lag will have fun.

I think that the best thing is to work on that function and, in general, make it softer and increase performance without lose quality.
ImaginaryVillain

#143 Aug 27, 2020, 08:20 AM Source

Oh, it leaves the lights on. Though the script does have a way to turn lights off based on a number you assign to each. Personally I just spawn the lights in when the player is close to them and despawn them when they're too far away. So I didn't bother to fix that.

Honestly the current script is super far away from what it was when I last looked at it. Then again 1.16 was the last version I truly did a lot of work on. Ever since then I've just been cutting pieces out of a variant of it... I literally only ever use Tint and the Light note tag. I suspect I can get the script down to sub 500 lines that do just that.... it's only 760 lines at the moment. And it's sooooooooooo fast. :LZSwink:

At some point when I get some time to familiar myself with the changes people have made, I can take a look at making it more efficient. It's probably possible to add a distance calculation to the lightmask to auto turn off lights that are too far away.
DarkSearinox92

#144 Aug 27, 2020, 08:34 AM Source

ImaginaryVillain said:
Oh, it leaves the lights on. Though the script does have a way to turn lights off based on a number you assign to each. Personally I just spawn the lights in when the player is close to them and despawn them when they're too far away. So I didn't bother to fix that.

Honestly the current script is super far away from what it was when I last looked at it. Then again 1.16 was the last version I truly did a lot of work on. Ever since then I've just been cutting pieces out of a variant of it... I literally only ever use Tint and the Light note tag. I suspect I can get the script down to sub 500 lines that do just that.... it's only 760 lines at the moment. And it's sooooooooooo fast. :LZSwink:

At some point when I get some time to familiar myself with the changes people have made, I can take a look at making it more efficient. It's probably possible to add a distance calculation to the lightmask to auto turn off lights that are too far away.

I know that there is that kind of way for Light on 1 / Light off 1, but it's a lot of work todo, every time, in every map... I think that a build-in function that do this automatically is the best of the best.

I read that now it's a lot more softer than the original, that's why i wrote that i've not tested it yet. But i remember that this kind of light process, take "a lot" of cpu and if you use it on a phone, maybe it's very hard have lot of lights on the same map, all turned on without any intelligent function that automatically turns them off if you are very far from them.

My words are only just an advice to improve the script more and more :) Just like i said, you've done an amazing work and i love this kind of collaborations.
Aesica

#145 Aug 27, 2020, 09:19 AM Source

Let me just say that this is super tedious. Just finished adding ALL of the plugin commands in the comment metadata and I'll tie them into the code (the easy part, thankfully) tomorrow.

In the meantime, just look at how much easier this is to understand. TileLight, TileFire, RegionFire, RegionBlock, and all of those are all consolidated into one command with easy-to-change parameters. This should make using the thing a lot less cryptic.

...Just looking at it makes me realize the two player light commands should also be consolidated.

ImaginaryVillain said:
At some point when I get some time to familiar myself with the changes people have made, I can take a look at making it more efficient. It's probably possible to add a distance calculation to the lightmask to auto turn off lights that are too far away.
I can take a look at that tomorrow too. Unless you beat me to it. :)
ImaginaryVillain

#146 Aug 27, 2020, 09:29 AM Source

Reminds me of a my personal text plugin.... almost 300 lines of parameters so it could have ALL the PIXI text options and build fonts within it. The new plugin system is almost identical at least in that part of it. The other half creating the actual command is new. But yeah the MZ stuff is all you, I don't own a copy.

Also I'll add this update to whatever you add later. But for those who want to test it, this MV update should cause a sizable speed increase. It doesn't include the whole distance calculation idea yet though. I'll look into that later.
ScorchedGround

#147 Aug 27, 2020, 10:05 AM Source

Yay! As much as I appreciate the possible MZ port on the horizon, by all means keep the MV updates coming as I don't intend to fully migrate any time soon. All perfomance improvements are highly welcome.

Thank you for your efforts!
Aesica

#148 Aug 27, 2020, 09:38 PM Source

I don't know why I told myself this would be the "easy" part. I guess I forgot what code i was working with. ;)

Anyway, I found a completely undocumented feature: You can specify the speed of the player light radius change when using radiusgrow. Neat. I wonder what other buried treasures I'll find as I really dig into this stuff.
ImaginaryVillain

#149 Aug 27, 2020, 09:44 PM Source

It really is the "Oak Island" of plugins.
DarkSearinox92

#150 Aug 27, 2020, 09:52 PM Source

Aesica said:
I don't know why I told myself this would be the "easy" part. I guess I forgot what code i was working with. ;)

Anyway, I found a completely undocumented feature: You can specify the speed of the player light radius change when using radiusgrow. Neat. I wonder what other buried treasures I'll find as I really dig into this stuff.

AHAHAHAHA, Amazing Terrax! Who knows where it ended up... I just hope he's fine!
Aesica

#151 Aug 28, 2020, 04:03 AM Source
So doing this and trying out each thing has also made me realize just how much of this plugin is barely working or broken entirely. This is going to take longer than I thought, and I'm done for tonight.

Also, were the battle tint plugin commands ever actually implemented, or did somebody accidentally revert them? I can't seem to find anything that actually invokes them, yet I can see merit in their existence.

Edit: Checklist time!
Things that are verified to work:
- Master plugin on/off switch
- SetFire (the flicker adjustment thing)
- Set Tint (map only) including fades and daylight
- Region and Terrain Tag lighting (although shapes either don't work or I'm doing it wrong. did they ever work?)
- Player light radius/color adjustment
Things that probably work, but haven't been verified:
- Player fleshlight (the "it doesn't work if player light is radius 0" bug is fixed too!)
- Set/add time (added a way to subtract as well as add
- Set total hours in day
- Set hour color
- Set time speed
Things that probably or definitely don't:
- Light colors by ID. I have half a mind to make this key off event id + map id, not whatever the it uses now.
- Reset light switches. Dunno, maybe it does?
- Battle tint mainpulation via plugin commands. Battles still tint normally though
- effect_on_event and effect_on_xy: These are part of the bizzare ABS thing that got removed. Somehow, they're still there. The idea of placing an effect on an XY coord is intriguing and I might make it an actual thing. No promises though, and otherwise these are gone completely.
ImaginaryVillain

#152 Aug 28, 2020, 04:34 AM Source
Huh... And here I just thought you tested it all for the demo. Honestly I could have easily broken them during the first pass when I removed all that extra support for weird plugins. Entirely possible, half the options I didn't even know existed.

Which I think kind of illuminates a problem with this plugin. Up until now people haven't really mentioned anything not working. Which means they're not even using the stuff that was broken. Kind of seems like it's not really necessary to keep it.
Aesica said:

Player fleshlight (the "it doesn't work if player light is radius 0" bug is fixed too!)
The function we never knew it had? :LZSwink:
Aesica

#153 Aug 28, 2020, 05:54 AM Source

ImaginaryVillain said:
Huh... And here I just thought you tested it all for the demo. Honestly I could have easily broken them during the first pass when I removed all that extra support for weird plugins. Entirely possible, half the options I didn't even know existed.

Which I think kind of illuminates a problem with this plugin. Up until now people haven't really mentioned anything not working. Which means they're not even using the stuff that was broken. Kind of seems like it's not really necessary to keep it.

The function we never knew it had? :LZSwink:
Ha! I think a few use the flashlight (oh god, I typed fleshlight! screw it, gonna leave that typo in) mostly for horror games, but yeah some of the other things are...less useful. I think (working) plugin commands to switch lights on and off by map/event id, rather than by juggling a kill switch or using the wtf-non-intuitive id system currently (barely) in place would actually be pretty useful. I only settled on killswitches for my project because they're what worked at the time.

I think in a lot of cases, people won't bring up bugs unless specifically asked to report problems or unless they really want that feature and have no other choices. In most cases, I think they just let the bug pass and find another approach.
ImaginaryVillain

#154 Aug 28, 2020, 06:34 AM Source

Huh, usually I find people with a problem are the first to complain. It's the people who don't have problems that tend to never voice their appreciation.

I do think the ability to turn a particular light on/off based on event ID would make a lot of sense. The current ID system is well, weird. Not so sure they need to do it by map ID plus event ID though, after all who cares about a light on another map?

Since I have a system in place in my game that adds/removes events based on proximity to the player, I'll likely add something similar to that to this plugin. Though it will only disable/enable lights that are just too far for the player to see. I haven't added it to the plugins so far since my version for my game is all encompassing, so it serves no purpose for me.

I'll look into that whenever you're done messing with it. Currently I'm working on the "Ultra Mini" version. It's now under 600 lines. And it runs 60FPS at 1920x1080. :LZSexcite:
Aesica

#155 Aug 28, 2020, 07:03 AM Source

ImaginaryVillain said:
I do think the ability to turn a particular light on/off based on event ID would make a lot of sense. The current ID system is well, weird. Not so sure they need to do it by map ID plus event ID though, after all who cares about a light on another map?
It'd mainly be because that's the easiest way to store the light IDs (taking a page out of the self switch playbook, as they're stored like {"map,evt,type": true}. Per-event light states would be similar: {"map,evt": true}.

I suppose it's reasonable though to allow the user to omit the map id if desired and have it default to the current map.
ImaginaryVillain

#156 Aug 28, 2020, 08:05 AM Source

Mostly it just seems like we could use $gameMap.mapId(); as the map in question, and never bother to let the user mess with it. To me it just seems really unlikely/unusual that someone is going to want to turn a map off on a different map. But as is always the case, I'll leave it to whoever builds it to decide how they want it done. :LZSwink:

And now for the Ultra Mini Community Lighting variant. This little variant is built for speed, it comes in at a scrappy 596 lines of code. And really just supports 3 things... On/Off, Tint and Light event note tags. So what's the trade off for less options? It's insanely faster than the main script. Like 60fps at 1920x1080 fast (that's my game's resolution which I test at), I also get as many as 80 lights on a map..... On top of the gross amount of particles I use. So chances are it should work "probably okay" for the rest of you. :LZSwink:

The script uses no plugin commands, as a result the second version is 100% compatible with MZ. The script also defaults off so you will need to execute the umc.Lighting.on(true) script to turn it on (it's in the help file).

The first is the MV version, the second is the MZ version. Let me know how it goes. :LZSexcite:
DarkSearinox92

#157 Aug 28, 2020, 08:17 AM Source

ImaginaryVillain said:
Mostly it just seems like we could use $gameMap.mapId(); as the map in question, and never bother to let the user mess with it. To me it just seems really unlikely/unusual that someone is going to want to turn a map off on a different map. But as is always the case, I'll leave it to whoever builds it to decide how they want it done. :LZSwink:

And now for the Ultra Mini Community Lighting variant. This little variant is built for speed, it comes in at a scrappy 596 lines of code. And really just supports 3 things... On/Off, Tint and Light event note tags. So what's the trade off for less options? It's insanely faster than the main script. Like 60fps at 1920x1080 fast (that's my game's resolution which I test at), I also get as many as 80 lights on a map..... On top of the gross amount of particles I use. So chances are it should work "probably okay" for the rest of you. :LZSwink:

The script uses no plugin commands, as a result the second version is 100% compatible with MZ. The script also defaults off so you will need to execute the umc.Lighting.on(true) script to turn it on (it's in the help file).

The first is the MV version, the second is the MZ version. Let me know how it goes. :LZSexcite:

amazing, if someone need a very very tiny plugin! :) I need other things so i will remain on the big one <_>
Fortunastreet

#158 Aug 28, 2020, 03:14 PM Source
Aesica said:
So doing this and trying out each thing has also made me realize just how much of this plugin is barely working or broken entirely. This is going to take longer than I thought, and I'm done for tonight.

Also, were the battle tint plugin commands ever actually implemented, or did somebody accidentally revert them? I can't seem to find anything that actually invokes them, yet I can see merit in their existence.

Edit: Checklist time!
Things that are verified to work:

Master plugin on/off switch

SetFire (the flicker adjustment thing)

Set Tint (map only) including fades and daylight

Region and Terrain Tag lighting (although shapes either don't work or I'm doing it wrong. did they ever work?)

Player light radius/color adjustment

Things that probably work, but haven't been verified:

Player fleshlight (the "it doesn't work if player light is radius 0" bug is fixed too!)

Set/add time (added a way to subtract as well as add

Set total hours in day

Set hour color

Set time speed

Things that probably or definitely don't:

Light colors by ID. I have half a mind to make this key off event id + map id, not whatever the **** it uses now.

Reset light switches. Dunno, maybe it does?

Battle tint mainpulation via plugin commands. Battles still tint normally though

effect_on_event and effect_on_xy: These are part of the bizzare ABS thing that got removed. Somehow, they're still there. The idea of placing an effect on an XY coord is intriguing and I might make it an actual thing. No promises though, and otherwise these are gone completely.
Just to be sure we are speaking about the same things, this checklist is about the 1.026 MV version, or its MZ counterpart?

Aesica said:
It'd mainly be because that's the easiest way to store the light IDs (taking a page out of the self switch playbook, as they're stored like {"map,evt,type": true}. Per-event light states would be similar: {"map,evt": true}.

I suppose it's reasonable though to allow the user to omit the map id if desired and have it default to the current map.

Why not, more useful features is rarely a bad thing.
I personally have a big preference for the current id system who is more flexible and isn't affected by events' ids changes, although I will easily admit there is room for improvements, notably about how light ids are named inside the notetags (name your id d1, and it will be interpreted as a light direction for example), but I didn't found yet a way to do it without messing up with already existing notetags.

ImaginaryVillain said:
Mostly it just seems like we could use $gameMap.mapId(); as the map in question, and never bother to let the user mess with it. To me it just seems really unlikely/unusual that someone is going to want to turn a map off on a different map. But as is always the case, I'll leave it to whoever builds it to decide how they want it done. :LZSwink:

And now for the Ultra Mini Community Lighting variant. This little variant is built for speed, it comes in at a scrappy 596 lines of code. And really just supports 3 things... On/Off, Tint and Light event note tags. So what's the trade off for less options? It's insanely faster than the main script. Like 60fps at 1920x1080 fast (that's my game's resolution which I test at), I also get as many as 80 lights on a map..... On top of the gross amount of particles I use. So chances are it should work "probably okay" for the rest of you. :LZSwink:

The script uses no plugin commands, as a result the second version is 100% compatible with MZ. The script also defaults off so you will need to execute the umc.Lighting.on(true) script to turn it on (it's in the help file).

The first is the MV version, the second is the MZ version. Let me know how it goes. :LZSexcite:

Nice initiative, I like how clean the code is compared with the original.
Aesica

#159 Aug 28, 2020, 07:15 PM Source

Alexandre said:
Just to be sure we are speaking about the same things, this checklist is about the 1.026 MV version, or its MZ counterpart?
I'm talking about the MZ version, which is built off v 1.026. @ImaginaryVillain posted the version I've been adapting the plugin commands for. Given how different the plugin command system in MZ is (args = ["hello", "world"] vs args = {"name":"hello", "someOtherParam":"world"}) they were all 100% not working when I started on it. All of the note tag based stuff, however, seems fine.

Alexandre said:
Why not, more useful features is rarely a bad thing.
I personally have a big preference for the current id system who is more flexible and isn't affected by events' ids changes, although I will easily admit there is room for improvements, notably about how light ids are named inside the notetags (name your id d1, and it will be interpreted as a light direction for example), but I didn't found yet a way to do it without messing up with already existing notetags.
Oh wait, so the current ID system actually does work? I've never gotten it to, so chances are I was doing it wrong. If it does work, then yeah there's no reason for me to change it into what I was going to. As for naming the ID something like D1 and having it cause problems, thankfully that's absolutely impossible in MZ's system. If I can get the ID system to work, you'll be able to name it whatever you want. D2, B15, on, whatever. :)
ImaginaryVillain

#160 Aug 29, 2020, 03:52 AM Source

Glad to see the ID system works, it will be interesting to see how the changes I made for 1.26 pan out. As it was stated it's a "ghetto fix". I didn't extensively test it. Then again I don't think a lot of updates get extensively tested given how much the plugin can do.

@Alexandre Thanks, I've been beating up the code since 1.17 to get that. Also, no anonymous function... It's a thing of beauty! :LZSexcite: