UncannyBoots

Pretty sure the thing you are missing is making sure the light sprite and player sprite are using the same viewport. Each viewport basically takes all the sprites that use it and draws them together as a group with it's own z value so a sprite or whatever can only be drawn between others if they are in the same viewport.

That said: If you ask me having lights drawn under "Above Character" tiles or events actually look pretty terrible. Most light scripts I know draw a layer of darkness with 'holes' so drawing them bellow 'above character' stuff will make all the above character stuff be fully lit and the radius of lights will more then likely make the tops of trees stand out and get cut off.

You make a good point about lights clipping through trees, I didn't think much about that but yeah I don't see any good workaround to that sadly.

Still, is there a script out there that makes a character event sprite overlay on top of the character (similar to Hime's Picture Anchor script)? That would still be better for me so that I can ditch lighting scripts altogether and just use the Add blending mode for lights. Right now that's what I'm doing for static lights, but for my character I'm still using Zeus' Lighting Script, and when it turns on, CPU usage takes a noticeable spike upwards which I'd like to avoid.

What do you mean by 'makes a character event sprite overlay on top of the character' exactly? You mean overlaying one character sprite on another? You know all you really need to do to 'anchor' a sprite to another is to copy it's x/y location right?

Sidenote: Lighting scripts are always gonna be sorta slow like that because it has to do extra tricks with subtraction blending to get nice dark areas. You can't really get nice dark areas with additive blending and overly bright areas can look weird.

Pretty sure no one here is a lawyer, a real lawyer probably wouldn't give free legal advice to a stranger anyway, and  even if I did the answer would probably be a long winded version  of "it's complicated".

Here is my likely ignorant rule of thumb though: It's always gonna be a gamble.

How so? Well let's imagine a game. So you want to use this music... You got to make a bet! If you win you keep your money and get to use the music, if you lose you lose all the money. But there is a trick! Not only is it a bet, it's a blind bet. You have no idea how much you bet unless you lose.

Okay let's look at your hand. Oh so you own 2k3, okay add some points. Oooh, but you aren't actually using the music in 2k3, that may cost you some points. Oh but you aren't actually using the music it's self, okay add some points... but it is a remix so take some away. Uh oh, you are using the original midi? My my that might cost you some points! And so on.

Now to your opponent. They only get to play if they pay attention. If they don't notice you use the song at all you might win by default! But not so fast! They can play any time they want so it might be years before they make a move and you won't know!

So you have your hand and your opponent has theirs. What kind of hand could they have? Now if they play they may or may not have a better hand then you, but that's not the end of the game! Oh no no no. If your opponent plays they can use money counter bet by hiring a good team of lawyers. Now you have an opportunity to counter counter bet, but I bet you have far less money then they do don't you?

Now I donno about you, but that all kinda sounds sus to me. I think I rather not play that game and just use free stuff or make my own when I can. :3

Hmmm...

If you're thinking about it, just go for it. At this point, no one is really going to care.

It's probably impossible to get a seamless loop due to frame rate fluctuations, though you could probably get closer if you edited the sound to be exactly the right length in frames. Either way, you might need to add a fade out/fade in and just let it overlap a bit. Or another option might be having shorter motor/revving sounds that are designed to play intermittently rather then loop.

I know you don't like the FMOD script but I'm not wrong when I say it does indeed allow for multiple BGS (audio channels), right? If that's the case then I guess I'll look into getting it to work because that's the only good solution here, it seems.

...The only problem is, I literally can't find any clear cut documentation for how to play another audio channel. The documentation that comes with the script focuses only on getting DSP effects to work, which I have no interest in.

This is the only thing that seems related to specifying a channel that I can find:

pos = APU::CURRENT_CHANNEL_VARIABLE
v = $game_variables[pos]

And I have no clue on how to make use of that

It's not so much that I dislike the script and more that I have run into problems trying to use it. I think it has trouble working on some computers for some reason. Anyway APU::CURRENT_CHANNEL_VARIABLE should be set to a number near the start of the script shouldn't it? I think you just need to set that variable before you play a sound and it will play on that channel... I think?

I think it is a mixture of both.

I believe that there are some plugin makers that are porting some of their RGSS scripts to MZ...

That's really cool, are they scripts that didn't really have an MV port?

@Tsukihime mentioned in one of her status posts that she'd be having to port her Tag Manager script to MV from VX Ace for a grid battle feature she's developing for MZ. I'm certain that there are other examples of MZ plugins that are being ported in from XP/VX/VX Ace...