MV - Community Lighting MV & MZ

Definitely a fan of the second version, since to me the original just looks like it washes out the action. Obviously having the option to pick is great. :LZSexcite:

As for the MZ thing, if people want to make a version that's for MZ please do. I'll add it to the first post, along with the MV ones. :LZSexcite: Personally I'm not really interested in MZ since it's not going to be as capable as MV for quite awhile. So I won't directly be working on it, as I'm not switching until I could realistically port my game over. But I won't stand in the way of others doing so. :LZSwink:

Here is version 1.19:

Main change list:
-As a plugin parameter, you can choose to put the battle light mask between the battlers and the battleback or above the battlers.
-This version includes Eliaquim's work with the better for loops.
-The kill switch bug I mentioned before is corrected.
-Multiple parameters in the plugin manager now have proper formatting.

Known issue: if the battle light is placed between the battlers and the battleback, adding extra battleback sprites with any plugin like YEP_ImprovedBattlebacks, the added battleback will put itself above the light mask, masking it. (I will be looking for it tomorrow)

Yeah that's much better, although I just realized it's not actually working with any day/night tinting, just the last-used tint. I guess I thought it was working before because I tested it during night, but during day, it's still dark (presumably the minimal light is kicking in here, not the actual night tint) and after going into my red tinted room and back, the background is red even in broad daylight.

I think it should be a pretty easy fix though. If nobody else is working on anything for this plugin right now, I'll add a small fix to make it work.

Edit:

Okay made a few quick changes/tweaks:

• 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
• 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!)

Version below: 1.0195

Oops, you are right, I forgot to add daylight to the equation,
and I didn't realize it since I used the same values for the tint and the daylight.
Nice catch.

I haven't really tested many of these new versions (the last I did a minor test on was Eliaquim's)... Though I'm getting what I've affectionately dubbed as "crappy blending circles". Basically lights that just don't blend with anything else. They don't happen every map though they do happen frequently and when they do... The game drops to 5-11fps till I exit the map. These are simply spawned in events, blank except for a notetag. It's the same test I've been running, and it wasn't present in our earlier versions. :kaoswt:

edit:
I see, somehow this new version manages to interact with my world creator in a weird way... Impressive since the world creator extends no portion of MV, and has no global variables. A bit of reordering commands fixes the issue. So I withdraw the bug report.

edit 2: Updated the first post with the new version, the change logs, and added Eliaquim and Alexandre to the contributors list.

First of all, awesome plugin. It really upgrades the whole atmosphere.

Now, in my game the time is defined in 2 times, simply morning and night. So what i wanted was to have 2 sets of lightning, morning and night. To avoid any clashes with other plugins, i placed this one at the very end of my plugin list.

I started by testing out the night effects (the most important of the two) so i simply thought i'd set the variables for hours,minutes,seconds, the switch for night, and then alter the time hours to the morning hours via the plugin command "Daynight hour [10]". Note that it automatically started as night. Then i received an error:

ReferenceError: saveTime is not defined

I have no idea if i did something wrong, could someone explain?

PS: Tested:
Daynight hour [h] [m]
Daynight add [h] [m]
All give me the same error.

The cycle runs fine though, it's just that i can't turn it to night/day whenever i want it to

PS2: Looking at the code i *think* with my limited knowledge, that the problem lies in the fact that the saveTime function is declared in the first block of functions, but the plugin command calls it from outside it. I might be terribly wrong though, but i'll test correcting this and update my post.

UPDATE: I cut the end of the first block ("})(Community.Lighting);") and pasted it at the end of the plugin, and now the error is gone, but it still doesn't do what it's supposed to. I added a console log in the saveTime function console.log(hh) to see what it does with the hours, and it seems to reset them (or rather, it sets them to NaN and then they reset.) I'm still looking into it, i'll post again if i have an update.

UPDATE2: Ok, so i got it to work as so: I cut the "})(Community.Lighting);" and pasted it after the last call of saveTime function (in my IDE it's in line 2598). Then the helpfile states that the plugin command is "Daynight hour [h]" but it's "Daynight hour h" without the brackets. So basically, if you want it to be morning you just call "Daynight hour 10" instead of "Daynight hour [10]".

Good catch, and yeah you're right. Originally, it was all a huge mess just out in the open before we all tried to organize it a little better. The Community.Lighting.* functions should probably all be moved into the main anonymous function with the other, similar functions. I'll update it later today.

Thanks, i'm glad it helped. While you're on it, take a look at the help file also. Like i say in my UPDATE2 above, it states that the plugin command is "Daynight hour [h]" but the actual command must not have the brackets, otherwise it just resets the time (it sets it to NaN and it resets). I simply put "Daynight hour 10" to set it to hour 10.

I'm assuming that the brackets in "[h]" were put there to emphasize that that's the user's value, but it's not explained anywhere.

Also, something else i didn't see (but it might be there - it's intuitive actually) was that if you don't want the time to pass but control it manually through commands, you can simply put Daynight [0] in the map's tag (which, by the way, does need brackets xD).

EDIT: Pausing time passing is actually included in the help file, i had missed that.

That help section was originally just my personal notes on what the original terrax plugin did and how its syntax worked. I just sort of copy-pasted it into this one (since it's still better than the word stew in the original. Because of that, I'm seeing that they gradually shift from "values in brackets are optional values" to "values in brackets are user-defined values." Either way, the brackets are never meant to be included in the actual commands.

Thanks again for the heads up, I'll clean them up before posting the fix mentioned above.

Edit: And yeah, the Community.Lighting functions should've probably been placed inside the anonymous function, but weren't for some reason.

Edit2: Okay try this version. 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). 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.

Current version: 1.0197

Seems like this version is working fine! :)

Excellent! I've updated the first post to the latest version.

Hello,

I think it is great that you make this plugin available to the community.

But I have some problems with it.

Assigning a light or fire to an event works
e.g. <cl: Fire 200 #FF9900 B50> in note

But if I want to turn on a light with a switch it does not work.
e.g. <cl: Light 250 #FF9900 B25 1> in note
No Light is on
If I remove the ID 1 then the light is on.

RegionLight does not work either.
I have set a regiontile with the number 150 on the map.
Plugin command: TileRegion 150 ON #FF9000 200
teste also with plugin command <cl: TileRegion 150 ON #FF9000 200>
But nothing happens.

The same applies to TileFire, TileGlow, RegionFire, RegionGlow and TileLight.

On my test map only the Community Lighting plugin is installed.

Am I getting something wrong?

I hope you can help me.

Sorry for my bad english is not my first language.

Hey, does anyone have an image of how this looks with the UltraMode7 plugin?

I experimented with lighting earlier in the year but had to abandon it due to really wanting to use Mode7 for this particular scene; the solutions I tried wouldn't play nice with it.

If you put an '1' on a light, it means you have to use the command 'Light on 1' to activate it.
It doesn't mean it is linked to switch 1. Did I understood well your problem?

EDIT: No you are right, there is definitively a problem with the IDs.

Since the ID system has never really worked, I'm thinking it might be easier to just pull a sheet over it it as a feature of the plugin. You already sort of can switch lights off by id by using the kill switch feature (what I use in my game) by referencing the event by id and setting its self switch (D in my case) to on.

Anyway here's a version that has tile lighting working properly. I hope. It seems to work fine in all of my tile light maps anyway:

Version is 1.02

I got why the light switch are broken; it is linked to an old functionality who is no longer documented in Community,
but was in the original (but quite hidden):



In th old days, using 'Light on' also activated the D self-switch of the related events.
If your killswitch was D, the light didn't show up in consequence.



By making this modification, I manage to assure that if there is a killswitch,
it will be triggered when the light is on... So it will be off.




In any case, do we want to keep this old functionality?
If yes, I think the switch being turned on should be a plugin parameter (with none being an option),
and there should be an additional check to make sure it is not the same as the killswitch.

EDIT: here is a version without this functionality who removes the light id bug.
I will make a version with this old functionality working as intended if we decide to keep it.

Pretty certain we're trying for the most feature rich version of Community Lighting as the main one. That being said... I pretty much never test any of the more exotic features, and didn't even realize the plugin had them till I started editing stuff. :LZSwink:

So if we want to cut them, I wouldn't really notice. Truth be told I made a very different variant of 1.17 that's now 1,038 lines of code, and only does Light, Tint, effect on event and effect on X/Y (neither of which I've ever used so no clue why I kept them). Entirely designed for speed, (since my game is already demanding enough)... It's roughly 10-12 FPS faster. The anonymous function is now only 32 lines. And I solved it's overwrite problem so that no longer overwrites Spriteset_Map.prototype.createLowerLayer but still works with Mog Character Particles (which I don't even use).

That being said, it's a variant... A very different variant. No clue if we want to do variant versions of the main plugin or not. I might push some of the more interesting improvements to the main version. Though I admit it's been changed a lot since I last checked out the code and I haven't had the time to look at it and compare it against mine.

Anyway, thoughts? Do we want to support variants of the plugin? Or just focus on having the one main version? Mostly it just decides if I post it here or not, I'm definitely going to keep developing my variant either way since I need it for my game. :LZScheeze:

I can't speak for the others, but I see nothing wrong with variants. I recall awhile back somebody was interested in making a typescript version, and while I doubt we want that as the main version, there's nothing stopping them from doing so as a variant due to how the original was licensed.

So knock yourself out, just be sure to make it clear that your variant is very much a "lite" version, what's different about it, etc. But you knew that much I'm sure.

That said, any other optimizations are more than welcome in the main version. Aaaaaanything to improve the speed and performance, really.

Edit: On the subject of variants, with MZ around the corner, I do plan on making sure a MZ-friendly variant will be available for obvious reasons, so there's that too.

At this point I don't mind variants too much either, as long as bugfixes and cleanups get applied to each variant.

The current version itself is already functional enough (atleast for my needs).