- Oct 29, 2015
- Reaction score
- First Language
- Primarily Uses
Right... how dumb of me. Of course. Here you go:
Now I got it!Right... how dumb of me. Of course. Here you go:
Thank you for the great idea!Hey OcRam, thanks for another quality plugin! One suggestion: Would it be possible to adjust volume levels of BGS2 and BGS3 based on the BGS volume level selected from the Options Menu? Right now there's no way for the player to mute or lower the environmental or weather BGS layers from the menu.
Thank you for the message,Currenly, when using a dynamic event BGS, the distance not only affects the volume but also which speakers are used.
Would it be possible to add a command that ensures that the dynamic event bgs does not limit itself to one speaker but only changes in volume?
In a top-down RPG with just two speakers, it's odd, at least to my ears, when proximity is simulated through more than the volume level.
Yeah, but BG is also map-wide, right? At least the river I've got on the map can be heard from anywhere.Thank you for the message,
Have you tried bg type? <aex:bg:...what ever other params...> bg type shouldn't effect speaker panning.
Ok now I got itYeah, but BG is also map-wide, right? At least the river I've got on the map can be heard from anywhere.
I'd like to use a dynamic event BGS on, say, a campfire. As you get closer, it gets louder, except it shouldn't switch off the Speaker of the other direction and imitate surround sound.
Awesome.Ok now I got it
Yes BG type can be heard anywhere on map with same volume level.
I'll think about adding "disable panning" parameter to "aex" notation.
EDIT: Thinking time is over - I'll do it
Thank you for the great ideas (and bug report, will be fixed in next version)!I've got a second request:
Could you add greater flexibility when it comes to event-based x/y/d commands?
Right now, from how I understand it, the plugin picks the xy coordinates and then calculates the distance from there.
Could you add additional functionality that allows you to create a zone larger than a single tile for the maximum sound effect and the distance calculation? Or the ability to set an index to a sound emitter and override it via a different emitter? (Leaving BGS2&3 untouched, so they can be dedicated to weather sounds)
There's a river flowing across the map and not in a straight line.
Right now, you'd have to create multiple sound events to cover the correct areas, but doing so is problematic because every new sound event will create sound overlap due to the sounds coming from different sources. And if you use too few emitters, broad sound areas will seem off because the volume level will vary based on the distance even though the area itself is so large that no volume change should happen.
(Like a lake, for example. If you put the emitter into the middle of the lake, the sound will be lower in volume at its edges, even though it's still at the lake and should have the same volume level)
There's a couple of things I imagine would help:
1. Instead of using the base xy coordinate of the event, the calculations are done based on a range.
dr would activate a dynamic range, which then will check for additional parameters in the next entry and detect 3,3 which give the number of tiles the full volume emitter zone should be extended.
In this case, the area in a 3 tile radius around the emitter will have full volume and all distance based volume calculations & adjustments only follow after.
Something like <aex:dr:5,3,15:2:true:forced> would cover a large area of up to +-3 tiles on the x coordinate and +-15 tiles on the y coordinate.
Additionally, commands like dr+ and dr- could be used to force the emitter to draw the box only into one direction. (+, extending the emitter only from left to right and downwards, while - does the reverse, just as the xy coordinates on the map work)
2. Allowing the emitter to be based off specifically designated tiles.
dt forces the command to use as base tiles the nearest of any of the tiles specified after the last forced command. This may be tedious for large areas, but it allows one to be very precise in the emitter area.
3. Linking an emitter to an index.
di links the emitter to the index in brackets, in this case . Only one indexed emitter can only ever play sound and the nearest one is always picked.
So if two di emitters are near each other, the closest one will play its sound, the other will be silent.
Also, I think I found a bug.
The plugin command stop_bgs2 isn't working.
stop_bgs3 works as intended, but for some reason, the stop_bgs2 neither works, nor is it (in debug mode) even registered in the console.
Thank you for taking a look. One other bug to report; if the player tries to adjust the BGM volume from the Options Menu, the BGM will abruptly stop. Also, if player has BGM volume set to 0%, or lower than the default setting, the BGM will always play full volume when starting the game, regardless of what setting is selected from options.Thank you for the great idea!
I'll see what I can do.
Great, looking forward to it!Thank you for the great ideas (and bug report, will be fixed in next version)!
I'm sure some of these ideas will be seen in next version of this plugin!
Noted and thank you for the report!Thank you for taking a look. One other bug to report; if the player tries to adjust the BGM volume from the Options Menu, the BGM will abruptly stop. Also, if player has BGM volume set to 0%, or lower than the default setting, the BGM will always play full volume when starting the game, regardless of what setting is selected from options.
Noted and thank you for the report!Great, looking forward to it!
An addendum to the bug report:
The problem doesn't seem to be with stop_bgs2 itself, but something about the way the plugin command is called or the commands work.
I've switched the plugin commands inside the event for called common events that execute the plugin commands.
So instead of using "stop_bgs2" I call common event x that consists solely of the plugin command "stop_bgs2" and the same for bgs_3.
Now the role oddly is reversed. stop_bgs2 works, stop_bgs3 doesn't (but is detected in the console)
I hope that helps narrow down the problem, because it sure seems like an odd one.
I've done some more testing, created a much more detailed bug report for the issue I've mentioned...only to notice that I'm an idiot.Noted and thank you for the report!
Noted and thank you for the report!
I will now start Audio_EX v2.00 -project.
Thank you for the message,Question: Can this plugin help with fading IN BGM's as well? The engine allows us to fade out music but not the other way around unfortunately.
Hey OcRam, thank you for the update! Unfortunately the latest update introduced a new, unusual bug. Any SE played through an event command plays at a pitch and volume of 100, even if specified otherwise. SE's used in battle animations also play at pitch and volume of 100. Strangely, this didn't seem to effect system SE's.Latest version - v2.00 (released 2019/12/22)