Oh... I guess I forgot to remove the message in the intro about it. I ended up removing it from the github as nobody really had any interest, and it was just the version I was using for my project. So it meant I could better tailor it for my own ends. Of course then I ended up messing with another engine and it became a moot point. So I haven't really revisited it.
Thanks a lot! I think there's an error in the documentation (should be $gameVariables.SetTint instead of $gameVariables.tint), but this is exactly what I was looking for!
I guess you are asking about the 'mini' version?
Hi guys, I apologise if this is a stupid question as I am new to all of this and I have only used basic plugins so far (like image and menu switching ones) so I am making a mystery game and I want the player to have a torch at times, can I add this command to an equip able item so the effect only happens when equipped? or does it have to be linked to an event? as I've noticed I cant have events conditions controlled by equipment, only items. basically, I don't know what I'm doing with any of it
Yes! 100% and my brain just can't seem to get it to work, or figure out what I need the plugin settings to be, for the command to work on the accessory
Making an common event run when equipping/unequipping a weapon or a piece of armor is impossible in the rpgmaker engine without using plugins.
Thank you
HiToday 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
Change Notes:
1.0 @ImaginaryVillain
1.01 @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.
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
1.016 @ImaginaryVillain
- 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 "<cl: light 250 #ffffff>" 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 < 0 or > 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.
- 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
1.018 @Eliaquim
- 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. 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
Removed the "tiletype" argument here, on line 383.
1.019 @Alexandre
1. Added support for Battle lighting.
2. As a plugin parameter, you can choose to put the battle light mask between the battlers and the battleback or above the battlers.
3. This version includes Eliaquim's work with the better for loops.
4. The kill switch bug I mentioned before is corrected.
5. Multiple parameters in the plugin manager now have proper formatting.
1.0195 @Aesica
1. Daynight tinting now works properly in battles. So if it's night time on the map, the battleback will be tinted to match (assuming battle tinting is turned on, of course
2. Shortened the battle tint plugin parameter IDs (they were being clipped due to their length) and so they match the format of the other plugin parameters (minor nitpick, sorry about that!)
1.0197 @Aesica
1. All Community.Lighting functions are now inside the main anonymous function, and all references to Community.Lighting within it have been changed to $$ (which is a reference to the Community.Lighting object).
2. Help syntax format has been updated to be more uniform: Values in [brackets] are optional, and this is now actually indicated toward the top of the help.
1.02 @Aesica
1. Fixed issue with tile lighting not working properly.
1.021 @Alexandre
1. Removed bug with light ID.
1.022 @Alexandre
1. Conditional Light killswitches now set to on/off based on if the Lightsource is decativated/activated.
2. Bug fixed with Day Night setting.
1.023 @Alexandre
1. Killswitch synchronization added an option.
1.024 @ImaginaryVillain
1. Fixed the compatibility issue with plugin order, and still works with Mog Character Particles.
1.025 @Alexandre
1. Alternate Light Directions added, demo updated.
See changes after this on GitHub.
Known Bugs:
- Flickering with large maps and Ultra Mode 7
So have fun, test it out, edit it, etc. Let's see where this experiment goes.
Script and Demo available on GitHub!
Click Here to View/Download from GitHub!
MV Version Last Updated September 13th 2020
MZ Version Last Updated September 13th 2020
Ultra Mini Community Lighting:
This is a side project of mine, it's a very stripped down super fast version of Community Lighting that I use for my game. (Which you can see by clicking the link in my signature). This version only turns on/off (defaults to off), allows for the "Light" tag, player lighting, and the tint command. That's it.
However the upside is it's insanely faster than the base script. So if that sort of thing interests you, it's available on the GitHub as umc_Lighting.js or umc_Lighting_mz.js. Instructions to operate it are in the plugin. I would also like to note that I don't own MZ, so while the MZ version works... It is not extensively tested.
Also just as with the normal Community Lighting plugin, you are free to edit or add to this plugin. Just understand the goal of this plugin is not to be feature rich, but instead to be as fast as possible. So if you're looking to add to it, please keep that in mind. Thanks and let me know how it goes!
Edit: Now in it's own Github. Click Here!
Hi
I really love the work you have done on the Community lighting
My project is using a combination of plugins, but is mostly built up from MOG Hunter's Chrono Engine. I have three asks, if possible:
1. My characters are 64x96px, so I was super happy to see I could offset the flashlight in Y, but... is it also possible to add X offset? So that the light does not burst from under feet/chest/head, but a "meter" in front of the character?
2. I am using diagonal movement and was googling like crazy for any solution that would actually calculate the flashlight diagonally. Unfortunately, the only thing I managed to find was combining GALV's diagonal movement (which I am not using) with Terrax's Lightning system. It does not "fly" with my MOG Hunter's diagonal player controller, unfortunately (it was a stretch, I know, I am no programmer). This script was supposedly done by MPR (attached - it's MPR's not mine!). Not sure if its possible to implement such feature to Community lighting, ideally so that it works regardless of the systems used?
3. Tried Shora Lighting too. I can imagine coding dynamic shadows is no trifle, but I am really curious about the fluent movement of the flashlight when the player is turning around. Is that also a complex thing to build...?
I'm new here so apologies if my ask is weird or inappropriate... thank you in advance for any response, if possible.
It's not quite what I'm saying. Yes, you can change an animation's blend between normal/additive/multiply/screen, and it will affect the animation's brightness... but it still doesn't actually generate light per se. If I cast fire in a dark room, it would still be dark, its just that the fire itself would be lighter.
Oh! My bad. I just built a room really quickly just as a depiction of the difference in what we were talking about. In other words- I'm not using that image to say "How do I make the fire in this room light up?". I'm using that image to say "The fire doesn't light up the area just because I changed its blend".
