RMMV Community Lighting MV & MZ

[Featherbrain]

I'm just throwing this thought into the void--I don't even have the plugin in front of me at the moment to verify my memory--but I believe there is a "minimum tint" threshold functionality within the plugin that attempts to adjust tints that are set at too dark a color to a lighter color. (I want to say it was anything below #2e2e2e or something like that.) That tells me the plugin may not "like" darker tints in general. Have you tested what happens if you put in a lighter tint color than #000000?

 

[Moon_Haven]

I'm just throwing this thought into the void--I don't even have the plugin in front of me at the moment to verify my memory--but I believe there is a "minimum tint" threshold functionality within the plugin that attempts to adjust tints that are set at too dark a color to a lighter color. (I want to say it was anything below #2e2e2e or something like that.) That tells me the plugin may not "like" darker tints in general. Have you tested what happens if you put in a lighter tint color than #000000?

That's worth a try! Give a a sec...

Edit: I tried changing the tint and the light layer mask to #999999 but unfortunately the black bar is still present. I'm baffled.

Preview

 

[Aesica]

I'm just throwing this thought into the void--I don't even have the plugin in front of me at the moment to verify my memory--but I believe there is a "minimum tint" threshold functionality within the plugin that attempts to adjust tints that are set at too dark a color to a lighter color. (I want to say it was anything below #2e2e2e or something like that.) That tells me the plugin may not "like" darker tints in general. Have you tested what happens if you put in a lighter tint color than #000000?

Both minimum tint and light mask layer are just for battles so that, say, a #000 room doesn't give you a black screen for combat.

That's worth a try! Give a a sec...

Edit: I tried changing the tint and the light layer mask to #999999 but unfortunately the black bar is still present. I'm baffled.

Preview

Hmm, I'm running out of things here and no matter what I try, I can't reproduce the effect. If possible, upload a minimal-assets sample project where this happens?

 

[Moon_Haven]

Took me all day, but I found the culprit!

It happens when using the Daylight speed tag in a map notetag. for instance: <cl: Daynight 30>

I'm trying to see if I can use a plugin command as a workaround.

 

[Aesica]

Good catch! Seems using the daynight map tag in general causes that, because now I can reproduce it on my end. At least now I have a starting point to fixing it. The weird and buggy way this plugin does things never ceases to amaze!

 

[Aesica]

Fix for daynight map tag + padding is up on my github, and should be on the main one too once @ImaginaryVillain sees this.

Latest versions should be, as of this post:
- MV: 2.3
- MZ: 3.4

 

[Featherbrain]

This shaking issue suddenly became less of a hypothetical for me when I saw it was related to the daynight tag. Lo and behold, I saw it too when I tested a map where daynight governs the tint fade.

Just tested the new version. No bars! Thanks!


BTW, something I noticed that's missing from the help notes: for "flashlight" effects attached to events via note tag, "walking" must be unchecked/off in the event page. I was confused why my flashlights were only appearing as small round lights until I looked under the hood and noticed there's a check for whether the event is "walking" or not that prevents the flashlight notetag from being parsed correctly if a stationary direction is set with the notetag.

Also, the flashlight note tag command seems to only accept color hex codes WITHOUT the '#' in front of them. (Other commands in the plugin, including the regular "light" notetag, seem to allow, or perhaps even require, the '#'.)

Wonky stuff probably not worth changing, but perhaps worth documenting.

 

[Featherbrain]

Scratch that. I may have spoken too soon. After upgrading from my previous version to the shake-fix version, the lights I put in earlier today with event notetags are now all offset upward by what looks like 1 tile (24 px in my case).

The version I was using before is apparently pretty old (1.026) so I'm not sure if this was introduced with this particular change or not. These are shots with only swapping the current version with the old one, no other changes.

 

[Moon_Haven]

Okay, that's going to sound like a newb question, but until iVillain updates the github, where do I download the update that Aesica just uploaded?

 

[Featherbrain]

Okay, that's going to sound like a newb question, but until iVillain updates the github, where do I download the update that Aesica just uploaded?

Aesica posted a link to their own github elsewhere in the thread: https://github.com/Aesica/community_lights

 

[Moon_Haven]

Scratch that. I may have spoken too soon. After upgrading from my previous version to the shake-fix version, the lights I put in earlier today with event notetags are now all offset upward by what looks like 1 tile (24 px in my case).

The version I was using before is apparently pretty old (1.026) so I'm not sure if this was introduced with this particular change or not. These are shots with only swapping the current version with the old one, no other changes.

Hmm? Lights seem to work fine here... firepit is a light, so are the gems. They're all properly centered.

 

[Featherbrain]

Yeah, I just tested V 2.2, the light misalignment is present for me in that version too. So this was not introduced by the most recent changes for the shaking thing, it's something else going on.

The older version seemed fine, so I'm pretty curious to look and see where the breakdown occurred, that would be the easiest way to figure out what did it. I don't know Github... is there a way to access versions older than 2.2?

ETA: Nevermind, I found the "commits" area, looks like previous versions (and change notations, nifty!). I have some research to do.

 

[ImaginaryVillain]

The GitHub's been updated with the latest version.

 

[Featherbrain]

Looks like the last version where the lights align correctly in the expected manner for me is the 1.03 posted by Aesica (and the master merge version by ImaginaryVillain) on Oct 25. Whatever presumably major changes went on in the jump to 2.0 changed the behavior of these lights for me.

If no one else is having issues, it might just be me. There's a lot going on in my engine at this point that's not exactly the default RM... I use TileD for mapping, for instance, and have 24 px tiles.
It's also possible that this is actually the expected behavior and I just need to place my events or set up the lights differently. I can probably work with that.

 

[Aesica]

No, it's not normal behavior and it happens to me too in my standard-issue 48x48 test project. Looking into it, but it's really annoying. The absolutely most irritating thing about this is that I only changed x values.

 

[Featherbrain]

In that case I'll let you check into it first and see what you can find, you probably know this thing better than me. My guess based on the back testing I just did and the fact that there are changes to the area that parses the flashlight notetag around lines 875 - 950 lines in v 2.0, I'd start there. Funny thing is I was just looking at this section earlier when I couldn't get the flashlights to turn on...

 

[Featherbrain]

I lied, I kept poking at it, and I think I found it.

It's this, line 1228 in the current version:

                                            let lx1 = $gameMap.events()[event_stacknumber[i]].screenX();
                                            let ly1 = $gameMap.events()[event_stacknumber[i]].screenY() - 24;

I'm not sure what purpose the " - 24" block originally served in the Jenga tower, but it seems to be offsetting the display up by 24 px arbitrarily, and removing the " - 24" seems to have fixed the issue. Will keep testing to confirm.

 

[Aesica]

Unfortunately, removing the - 24 breaks basically every light source by shfitiing them down by quite a bit. Changing the - 24 to - 18 seems to fix it though, at least with standard resolution/settings. Try it out on your version.

Edit: First/broken one: -0. Fixed one: -18

I'd like to play around with this a bit first before I commit it because it feels like a super-hackish fix, and those kinds of things usually cause other problems later.

Edit2: Added a better version of the gif where my character's actually standing in the same place for both frames.

 

[ImaginaryVillain]

I lied, I kept poking at it, and I think I found it.

It's this, line 1228 in the current version:

                                            let lx1 = $gameMap.events()[event_stacknumber[i]].screenX();
                                            let ly1 = $gameMap.events()[event_stacknumber[i]].screenY() - 24;

I'm not sure what purpose the " - 24" block originally served in the Jenga tower, but it seems to be offsetting the display up by 24 px arbitrarily, and removing the " - 24" seems to have fixed the issue. Will keep testing to confirm.

This isn't actually an arbitrary number at all. The -24 represents half of the default tile size of 48. The reason for this number is otherwise it will place the light centered around the bottom of the tile instead of it's center. Originally the plugin had it as just divided $gameMap.tileHeight() by 2. Technically more useful if someone changes the tile size, since almost nobody does I just switched it to 24 to save on the processing time.

I recall version 2 pretty well, mostly because it was that laughable version where everybody had updated the plugin but nobody changed it's version number for I don't know how many iterations. So when I redid the light calculations to use the screenX/screenY instead of the mess that was there before, I made it version 2.

So anyway to fix your 24 pixel tile problem, please put ($gameMap.tileHeight()/2) in place of the 24. I see no real reason to do this for the main plugin because it will calculate 24 every frame for every single lightsource. Which is pretty huge workload for something that won't affect 99.999999% of users. It's also worth noting you could just put the 12 in place of the 24 for your particular situation. But for anybody else using any conceivable tile size, the ($gameMap.tileHeight()/2) will work.

 

[Aesica]

So anyway to fix your 24 pixel tile problem, please put ($gameMap.tileHeight()/2) in place of the 24. I see no real reason to do this for the main plugin because it will calculate 24 every frame for every single lightsource. Which is pretty huge workload for something that won't affect 99.999999% of users. It's also worth noting you could just put the 12 in place of the 24 for your particular situation. But for anybody else using any conceivable tile size, the ($gameMap.tileHeight()/2) will work.

See that's the ****ed up thing. My test project (shown above) is the default 48x48 and -24 causes weird offsetting for me as well. When I set it to -18 (now we're getting into arbitrary ****ery here) everything sits where it should be.

That said, when optimizing performance is the goal, it's generally better to multiply rather than divide. So $gameMap.tileHeight() * 0.5 will get you slightly faster results than $gameMap.tileHeight() / 2.