RMMV Community Lighting MV & MZ

[Featherbrain]

Hm.. That does make sense, except, yeah, it's not holding up in effect. Because the sweet spot for me is definitely removing the offset altogether and leaving that line as:

let ly1 = $gameMap.events()[event_stacknumber[i]].screenY();

I've tried both 18 and 12. They both predictably increased the offset upward, causing it to be misaligned. This is with the offset of 12 for example:

You can see in Aesica's original example, the offsets are only slightly off what they should be at -24, whereas mine is quite significantly off.

Meanwhile, Moon_Haven seemed to have no idea what we're even talking about.

There's definitely something weird going on.

ETA: I'm using 1104 x 624 resolution, just as a point of reference. I also have a 2x zoom in the current scene, but I disabled the zoom and it doesn't seem to move or affect the lighting.

 

[ImaginaryVillain]

@Aesica Fair enough, I admit I hadn't noticed any real problems for myself. In fact until recently nobody's really said anything about it. But as is always the case, if the plugin can be improved please do.

I know the original reason for changing how coordinates were calculated was because originally the light didn't follow events on autonomous movement. That was apparently a problem all the way back in Terrax Lighting, he even made note of it in the comments.

It wouldn't be that hard to put a setting in for people to tweak. I could always add it later if you don't want to.

@Featherbrain
I won't speculate on whatever your project is doing. However if you wish to move it down, you can also just add to the Y coordinate as well. Or if removing it works best for you, then it sounds like that's a good plan.

 

[Aesica]

It wouldn't be that hard to put a setting in for people to tweak. I could always add it later if you don't want to.

I'm a bit iffy about that, because a "jiggle it until it works right for your project" setting is really just a bandaid solution. It's kick-back-and-chill time now, but tomorrow I'll dig around further and hopefully find out what's going on with it.

 

[Aesica]

Okay, so it's...actually working just fine. Turns out the weird offset has to do with whether or not the event in question is also offset: Thing1.png vs !Thing1.png


The only screwy part is when the event image is set to "None" it offsets it as though it were displaying a normal character (offset slightly) rather than a background object/door (no offset)

Under normal circumstances, it's fine at -24, or as a plugin paramter for odd cases would be ideal after all.

@Featherbrain is your project doing anything weird with event heights and y offsets?

 

[Featherbrain]

Almost certainly. I use a few different plugins to achieve hit boxes/collision for larger events (one for stationary events, another for moving events). None of the plugins are active or (intentionally) doing anything with these light events, but I wouldn't be surprised if there was a strange interaction somewhere.

I can help you troubleshoot if you want to dig deeper, but you definitely don't have to investigate further into my specific case. Even a plugin parameter would be extremely accommodating if no one else needs it. I'm pretty content with hard-coding it for my specific case (at least until I find out it's broken somewhere else, but I'll cross that bridge when I come to it).

 

[Featherbrain]

Just FYI, I think I figured out the mystery in my particular implementation. The info about the ! graphics helped me figure it out. With a "!" filename, the sweet spot for me becomes - 6 offset. And that made it all click--I'm using TileD with 24px real tile size, but I also have half-tile movement (it's a cheap/lazy man's pixel-ish movement), so sometimes the tile size is actually calculated as 12px. So, finally, in the context that "!" images show how it's "supposed" to be, it makes sense to me why this "half tile size" calculation is what it is for me.

Now that it finally makes some sense why this is happening, I do think there should be a plugin parameter for tile size. I assume the plugin could be written to take that parameter and initialize it as a variable a single time rather than recalculating it each time within that function, but I'd have to look at what's going on (and probably learn some new things in javascript) to look into that.

The other thing is, yeah, blank events with no image would still need to be corrected to behave the same way as "!" images... then I think this particular problem might be solved. Otherwise, I imagine the simple and immediate workaround would be to make a blank "!" image and use that image instead of "(none)", although I haven't actually tried this to confirm.

(Sorry, not sure if I'm breaking rules by "double posting" in this forum or not..)

 

[ImaginaryVillain]

The whole ! on character and event images is a actually a "feature" of MV/MZ, naming a file with that shifts the image down 6 pixels, and makes it immune to the bushes effect. Unless there is some particular reason you want that (they say it's for treasure boxes or buildings), you could just not name files that way, or simply name all files that way.

As for a plugin parameter, sure it's not that hard to make a plugin parameter and variable setup. Though just calling a variable 60 times a second per event/player with a light is more resources than most people realize. Little stuff like that adds up to worse performance, which is why I took the calculation out initially. Almost nobody changes the tile size, usually it's just the movement size. Typically we don't change the main plugin to deal with corner cases and just advise you make a minor edit for your own game.

That being said if there turns out to be enough of a call for odd tile sizes, I'd be open making the changes. It's just so unusual that it hasn't even come up once until now.

 

[Aesica]

Referencing variables is actually trivial speedwise, so that's not the issue imo. The main reason I'd be hesitant to add a plugin param for that is that, frankly, I'd rather find out why "Y" needs it while "X" doesn't, then fix it there. I'm actually kind of against the Screensize X and Screensize Y plugin params too since they're also bandaids of sorts. The width/height of the project can be accessed via Graphics.width or Graphics.height in both MV and MZ, after all.

 

[Featherbrain]

I get that my tile size issue is something of an edge case, but it also seems like there's another issue unrelated to my particular settings, with the alignment of the lights when no picture is used on the event. It's particularly evident when using the "wall" feature to create a hard edge on the light--in fact, it may only be a real issue with "wall" lights, where a hard edge is expected. That hard edge actually *should* be on the edge of the event, aligned to the grid, not in the middle of the event. That way it actually aligns to walls.

That's why I think the light source in such image-less events should also be shifted the 6 pixels in the same way that MV automatically does for ! images (which to my understanding is actually intended to be used for events meant to align directly to the grid).

Another way of conceptualizing it... the whole idea with this part of the code is about centering the light source on the event, right? Well, again, should the light source even be centered when it's a "wall" event? I was using the "wall" light sources to align directly to the grid. So I would expect the edge of the light should actually be the edge of the event (the lower edge if "south" wall, the upper edge if "north" wall, etc).

I don't know, maybe I'm wrong. But I feel like something's a bit off here, and it's not just my settings or tile sizes involved.

 

[ImaginaryVillain]

The reason to keep it consistent is so that people know how it will behave and can work around it. We already have a means of shifting it down the 6 pixels by simply making a !blank.png as the event image. But if we automatically shift it down, what if the person wants it centered and not those 6 pixels down? Then we would no longer have an easy way of fixing that.

Referencing variables is actually trivial speedwise, so that's not the issue imo. The main reason I'd be hesitant to add a plugin param for that is that, frankly, I'd rather find out why "Y" needs it while "X" doesn't, then fix it there. I'm actually kind of against the Screensize X and Screensize Y plugin params too since they're also bandaids of sorts. The width/height of the project can be accessed via Graphics.width or Graphics.height in both MV and MZ, after all.

True a single variable reference isn't much. And for most plugins they are called so infrequently that you could add a 100 variables it wouldn't make a difference. The scope of this plugin is really so much more though, that variable will be referenced 60 times a second, and 3,600 times a minute... For each light source. So the player plus just 4 lightsources is 18,000 references to that variable a minute.

Even then, yes one non-global variable won't matter much. But each new one added places that extra burden on the plugin. The numbers are quite exponential, and that's really the issue here. Which if Javascript wasn't a single core language (without using Workers), it would probably matter less. But due to it's inability to split up instructions between multiple cores, we really only have access to a maximum resource of whatever one core of a user's processor is.

That aside, that's a actually not a bad idea with the whole Graphics.width/Graphics.height thing. I didn't even think about it. It does seem a silly thing to provide those settings, especially when plugin parameters are significantly worse on performance than object references. Going to push that change to the UMC plugin for testing.

 

[Aesica]

The only tricky part about using Graphics.width/height is that, if you want to take the easiest route (assigning those values to maxX and maxY) they'll be undefined until all the post-load stuff happens. Probably why it was done this way in the first place.

With MZ, on the other hand, there's $dataSystem.advanced.screenWidth/screenHeight which is a lot easier to work with.

 

[ImaginaryVillain]

Yeah it's a lot harder in the main plugin due to the whole anonymous function setup. UMC doesn't use an anonymous function though so it was just a straight swap. Also since it's now only 308 total lines (including the help section), it's quite easy to edit without issue.

As for MZ I've barely looked into it, though that does seem interesting. I admit I'm a bit loathe to change the UMC MZ version since I can't test it. But it's good to know that's what they changed the screen references to.

Also this version of UMC is now on the GitHub as well with the screen changes.

 

[AfroditeOhki]

I just came back here to realize that Nekohime had added light offsets to MZ version... Aaaaany chance anyone might be so kind as to add that to MV version? Pwetty pwease with a chewwy on top?

 

[Aesica]

Honestly I'm not sure if it even works right in the MZ version. I haven't gotten it to work properly, anyway. If anyone has gotten light offsets to work, what parameters did you use?

That said, while working on my game project, I noticed player light brightness wasn't actually working properly, so I fixed it. The fix isn't posted yet because i wanted to see if light offsets were working properly, first.

 

[Aesica]

All right, fixed a few thangs!

MV version: Updated to v2.4
MZ version: Updated to v3.5

- Fixed a bug where the player light source ignored the brightness parameter
- Restored the light offset functionality that somehow went missing. While I'm not sure how it was supposed to work originally (I couldn't find the code that actually added light offsets properly anywhere) here's how it works now:

<cl: light 250 #fff x0.5 y1>

Creates a light source that's half a tile to the right and 1 tile down

<cl: light 250 #fff y-0.5>

Creates a light source that's half a tile up

The fixed versions are on my github and should be on @ImaginaryVillain 's branch once he sees this.

 

[ImaginaryVillain]

@Aesica I didn't see a pull request. Is there some other method of updating the code I don't know about? Besides the obvious just download the files and upload them myself, which I'm pretty certain Github wouldn't give you proper credit if I did.

 

[Aesica]

@Aesica I didn't see a pull request. Is there some other method of updating the code I don't know about?

Yeah, you have to tap into the alternate reality where I actually made the pull request. Yeah oops. I'll have that up in a few minutes.

 

[ImaginaryVillain]

Haha fair. Github's such a weird disorganized mess, I really thought I was just missing something.

edit: Merged.

 

[Moon_Haven]

All right, fixed a few thangs!

MV version: Updated to v2.4
MZ version: Updated to v3.5

- Fixed a bug where the player light source ignored the brightness parameter
- Restored the light offset functionality that somehow went missing. While I'm not sure how it was supposed to work originally (I couldn't find the code that actually added light offsets properly anywhere) here's how it works now:

<cl: light 250 #fff x0.5 y1>

Creates a light source that's half a tile to the right and 1 tile down

<cl: light 250 #fff y-0.5>

Creates a light source that's half a tile up

The fixed versions are on my github and should be on @ImaginaryVillain 's branch once he sees this.

Does this upgrade mean that we won't have to create a secondary event for lighting up tall candle holders, or off-center lights, properly?

Edit: The answer is yes.
Holy crap this is awesome!


(Sorry for the mess, the village trader is a bit of a hoarder)

 

[Aesica]

Does this upgrade mean that we won't have to create a secondary event for lighting up tall candle holders, or off-center lights, properly?

Edit: The answer is yes.
Holy crap this is awesome!

View attachment 170618
(Sorry for the mess, the village trader is a bit of a hoarder)

Yup! I've got about a couple dozen tall events to clean up now as well.

Edit: Also, I love that map. It's cluttered, but in a way that adds character. Nicely done!