Featherbrain

Prehistoric Gamer
Veteran
Joined
Jan 12, 2020
Messages
132
Reaction score
255
First Language
English
Primarily Uses
RMMV
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

Veteran
Veteran
Joined
May 5, 2020
Messages
191
Reaction score
83
First Language
French
Primarily Uses
RMMV
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

undefined
Veteran
Joined
May 12, 2018
Messages
1,725
Reaction score
1,647
First Language
English
Primarily Uses
RMMV
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

Veteran
Veteran
Joined
May 5, 2020
Messages
191
Reaction score
83
First Language
French
Primarily Uses
RMMV
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.

1607030983967.png
 
Last edited:

Aesica

undefined
Veteran
Joined
May 12, 2018
Messages
1,725
Reaction score
1,647
First Language
English
Primarily Uses
RMMV
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. :D The weird and buggy way this plugin does things never ceases to amaze!
 

Featherbrain

Prehistoric Gamer
Veteran
Joined
Jan 12, 2020
Messages
132
Reaction score
255
First Language
English
Primarily Uses
RMMV
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

Prehistoric Gamer
Veteran
Joined
Jan 12, 2020
Messages
132
Reaction score
255
First Language
English
Primarily Uses
RMMV
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.

8EpF8OK.png
 

Moon_Haven

Veteran
Veteran
Joined
May 5, 2020
Messages
191
Reaction score
83
First Language
French
Primarily Uses
RMMV
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?
 

Moon_Haven

Veteran
Veteran
Joined
May 5, 2020
Messages
191
Reaction score
83
First Language
French
Primarily Uses
RMMV
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.

8EpF8OK.png


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

1607038938509.png
 

Featherbrain

Prehistoric Gamer
Veteran
Joined
Jan 12, 2020
Messages
132
Reaction score
255
First Language
English
Primarily Uses
RMMV
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

High Cultist of the Sporkle
Veteran
Joined
Jun 22, 2019
Messages
879
Reaction score
5,245
First Language
Absurdism
Primarily Uses
RMMZ
The GitHub's been updated with the latest version.
 

Featherbrain

Prehistoric Gamer
Veteran
Joined
Jan 12, 2020
Messages
132
Reaction score
255
First Language
English
Primarily Uses
RMMV
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

undefined
Veteran
Joined
May 12, 2018
Messages
1,725
Reaction score
1,647
First Language
English
Primarily Uses
RMMV
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.

d0VZgye.png
 

Featherbrain

Prehistoric Gamer
Veteran
Joined
Jan 12, 2020
Messages
132
Reaction score
255
First Language
English
Primarily Uses
RMMV
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

Prehistoric Gamer
Veteran
Joined
Jan 12, 2020
Messages
132
Reaction score
255
First Language
English
Primarily Uses
RMMV
I lied, I kept poking at it, and I think I found it.

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

Code:
                                            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

undefined
Veteran
Joined
May 12, 2018
Messages
1,725
Reaction score
1,647
First Language
English
Primarily Uses
RMMV
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
JMhWkx8.gif


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.
 
Last edited:

ImaginaryVillain

High Cultist of the Sporkle
Veteran
Joined
Jun 22, 2019
Messages
879
Reaction score
5,245
First Language
Absurdism
Primarily Uses
RMMZ
I lied, I kept poking at it, and I think I found it.

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

Code:
                                            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. :LZSwink:

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

undefined
Veteran
Joined
May 12, 2018
Messages
1,725
Reaction score
1,647
First Language
English
Primarily Uses
RMMV
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.
 

Latest Threads

Latest Posts

Latest Profile Posts

"Everything tastes like chicken until it's chicken, then it doesn't taste like chicken."
Context: chicken samosas do not taste like chicken. I thought it was veggie samosas.
Just another ordinary evening.
This pig girl is a merchant and playable character.
Currently there's no name for her yet. a suggestion is welcomed.
Merchant.jpg
Merchant-1.jpg
Want for a Nail: I'm trying to figure out what controllers work with MZ, one support thread, a plugin request thread, a dead controller, and a $48 eBay purchase, and a PS1/PS2 USB adapter later. Still stuck with keyboard controls...
RPG Maker Games Critique with Studio Blue: Dying Flame stream starts now! Will we be able to escape the mansion with only the small flame of a lighter to guide our way? Find out live!

Moving day is on May 12! A month from today! I'm finally getting my own apartment!

Forum statistics

Threads
110,345
Messages
1,052,528
Members
143,384
Latest member
ironsonic79
Top