itch.io

Well, that solution is better than what you had. It could be better though. Recommendations:

1. Maybe I was unclear about the LoadBGM command? The LoadBGM command can happen at any time just so long as it's before PlayBGM by at least a few seconds. It does not need to be in the same event. You should use it significantly before you need it, not use it and throw a forced wait in within a single event. If memory isn't a concern, you could LoadBGM at the beginning of the game; it'll still be there when you need it. Granted, that forced wait is the only real reason it's working now (you were throttling the system without it), but...

2. You should be using Autorun for the "Play" event. In this case, the Wait would just bog down the game. Now, Autorun blocks the game flow until it's done, but PlayBGM is a very quick action in the grand scheme of things; you just need a way to tell it that it's done. There are two good ways to do this: 

2a. Use the "Erase Event" command to disable the event entirely until the next time the map is loaded (good if you want to run the event every time you load the map); or...

2b. Set a switch (preferably a Self Switch), make a second page for the event, and make the Condition of the page the switch that you set. Leave the second page blank with an Action Button trigger (good if you only want the event to run once ever). 

As for the randomness, you could absolutely do that. Set a variable to a random value between 1 and 3, and then use a Branch command. Like so:

A demo feels extreme for this. All you need to do is call the LoadBGM command before you need the music - at least a few seconds before! It can be when you enter the previous room or something, that's fine! It can run in the background while something else is going on! Just don't call the PlayBGM command until you've let it load. And... don't use Parallel or Auto events for this. There is a "Common Event..." command, which will run everything in a common event just once. 

In fact, do you really even need a common event for this?

Just to test, I loaded this in a Parallel common event just to see what would happen. No music played at all, and the game crashed after about half a minute. Yeah, I can't say I'm surprised. What surprises me most was that you said it played from the beginning - at all!

When I changed it to a "None" common event, no more crashing, but yeah, desynching. Like I said, you must give the track time to load. If I space out the loading and playing, I get no desynch issues.

All status effects that prevent a character from using the prerequisite skills really ought to block dualtechs already, even with statuses that don't stop them from moving like Silence, but especially with ones that stop them from moving. Is there a bug in this feature?

EDIT: Works fine for me in MV. I'd like to think I wouldn't have overlooked that!

Without testing, my first thought is: don't run this in Parallel. Parallel events must be used with caution, even outside scripts. In a Parallel event, it's re-running the two commands back-to-back constantly.

Furthermore, the load command takes a couple of seconds, so running Play immediately after it (even if not in Parallel) will likely cause desynching weirdness in variable mix play. You should generally load the music before you need it, by at least a few seconds. In another event, if need be.

"Auto" events block the normal game flow from running, so you need to turn off whatever switch activates it at the end of the event. However, I don't think either one is what you're looking for here. It sounds like what you really want to do is just have a "None" trigger common event, and call it with the "Common Event..." command.

If you're still having problems after all of this, let me know.

Dunno what to say. I definitely hear cross-fading when I run it on my computer. Are you using any other plugins that mess with audio? (And you're setting the fade time to something noticeable, right? A fade time of 0 will result in no cross-fading.)

Need more info, because it works fine for me.

Just to be sure, you're using settings like these, right? (The "20" is just for effect; it takes a really long time to switch, so it's probably not a good idea.)

I do most of my development in MV using Yanfly plugins (which I believe are related to VisuStella plugins) but, if an action sequence involves characters 2 and 4, I use explicit references to actors 2 and 4 in the action sequence. I don't use a common event, and I'm not sure such a thing would work well for varying actors.

It's a feature I've considered, but at this point in time, this plugin cannot do that (short of the cross-fading effect, and I know that's not what you mean.)

At present, only BGM. It's kind of a niche scenario, I'd think.

I do have a plugin that does things with BGS (Focused Sound Effects Pro), but not cross-fading, and it looks like I never updated FSEP for MZ. (Man, why did I never do that? I'm too busy today, but maybe I should in the near future.)

1. Basic functionality should be battle-system-agnostic, and I can make an update if it doesn't work (provided I have access to the plugin, at least). However, turn linking (IOWs, having a dualtech consume the turn of all involved actors) is a more complicated matter. I don't know how Visustella's ATB differs from the built-in ATB, but if it is significantly different, then turn linking may not work; heck, for the built-in ATB, it only currently works with one setting. (I have not used Visustella's plugins outside some testing scenarios; my own main game project is MV, not MZ.)

2. No.

2a. A dualtech is its own skill that has to be used manually. Have you played Chrono Trigger? The functionality of dualtechs via this plugin is similar to how it works in Chrono Trigger. In the case of the first tag, it will require actor 1 to be able to use Slash and actor 2 to be able to use Ice, and the component skills determine skill cost handling, but you use the dualtech by directly using the dualtech.

2b.  Do not assign the "Dual" tag to the same skill twice. You might be better off creating two copies of the dualtech instead - one copy for actors 1 and 2, and another for actors 1 and 3.

Safe as far as I know, but I don't typically use them for testing. This plugin does have a specific option for non-OGG files with unusual sample rates, due to a previous request, but as far as I know even base RPG Maker can handle them just fine if they're OGGs.

EDIT: Oh, right, that was YOUR request!

If you're not using Yanfly's battle plugins in MV, or the correct ATB mode in MZ, then linked turns will not work, and the user of the dualtech is the only one whose turn will be used by the dualtech. The standard battle system simply has too many reasons why it's not compatible with linked-turn dualtechs.

The component skill is only used for determining skill cost and accessibility. When you use the dualtech, the component skill will not be used directly at all. The dualtech can also have dramatically different effects from any component skills.

Ohhhhhhh.

Linked turns aren't currently compatible with Wait mode. Sorry about that.

No repro; I saw the bars for both characters empty with a linked dualtech. Granted, I'm not using some of the plugins you have active; let me try those and see what happens. EDIT: Nope, works fine for me.

(The newest version of MZ does not address your issue, since I couldn't actually reproduce your issue at all. It just addresses something I discovered while trying to look into it.)

Lastest version for MZ is 1.2, not 1.0.2. Was that just a typo?

Not sure from here. I'll investigate.

That's exactly what this plugin was originally designed for! Use the "variable" playback option to get that effect. You can use optional fade-in effects when you do it, or just have it instantly switch.

Span: Battle means the event will trigger once per battle, which seems like what you're most likely going for. Span: Turn means it will trigger every single turn. If the boss's HP can rise above the limit and go back to the original battle theme, then perhaps "Turn" is what you want, but I would recommend "Battle" in the general case. ("Moment" should certainly not be used for this, at least not without some tweaks.)

Screenshot uses MZ so it's more obvious what's happening, but it would work the same in MV.

...Okay.

I didn't even get a notification about this topic until you posted your solution, but you do appear to have figured it out, so... I'll just put out that bug fix, I guess. And yes, this plugin is meant to override the regular music commands when you've got a preloaded track, specifically so that you can override things like battle music. I use MV more, so I guess an MZ bug would have flown under my own radar, so sorry about that.

I wonder why I even capitalized it in the first place. My MV plugin has it as playLoadedBgm in all cases. *shrug*

EDIT: Though, looking at it, I found another bug in MZ. Might be a similar bug in MV? I'll look into it.

Huh, I guess either ATB got an update or most of my users haven't used ATB, if there are issues like these. (Truth is, my own project uses CTB.)

One way for a dualtech to have a "unique cost", as you put it, is to have a dualtech be its own "component" for at least one of the actors involved. (Exactly one, if you're using Party Limit Gauge, because it's a shared pool.)

(There are other solutions, but they would require edits to the plugin itself, and they would not be quick fixes.)

I can guess what happened. Maybe not exactly WHY it happened, but what the immediate cause is. Try the update.

I'm not sure why it wouldn't be able to use the Party Limit Gauge - I've heard of others using it - so long as the plugins are in the correct order: everything that modifies skill cost should be above this plugin. But then, I also haven't really tested with it much. (There would be a valid reason why it would not be compatible with multiple party members spending Party Limit in the same dualtech - I have warnings against that very thing! - but one party member spending it should work fine. Also, do remember: the dualtech costs the skill cost of the component techs, not the dualtech itself!)

Hm, I hadn't considered this one for animations, though that is a valid case for it. It may be complicated - battles and the overworld are completely separate concepts, and animations can be called through both - but the voice acting plugin can do similar things to this plugin. There's also the fact that I don't know if animations can accept plugin calls. I have a lot on my plate right now, but it's something to mull over.

Hm, on a SINGLE enemy? I can guess why that might happen with multitarget attacks. (And it wouldn't be an easy fix - if it was, I would have fixed it already.) Or did I misunderstand?

Did the new version (3.2.2) not work?

Sorry for the long response. Life happens, y'know.

I'm afraid I didn't quite have enough info to repro this, but I had a hunch what was causing it between looking at Yanfly's code and my own. As such, I have a possible fix, but I can't 100% guarantee this one. (Actually, if I'm right, the error isn't far off from what caused the last one.)

I had refactored some code a while back. It might have been to fix another bug, it might have been something else. I don't remember. The whole thing took place inside an "end-of-action" function. In the old code, if it's at the end of a scripted event, it kicks out of the end-of-action function early, before doing some extra "cancel the dualtech if that's what got used" code (since, if the skill was turn-linked, everyone had to go on standby until the skill was used). With the refactored code, the "cancel the dualtech" still got run even then, but there wasn't actually an active action at that point, due to how something up the chain handles scripted events. And, as stated before, this meant it was trying to use a "null", which resulted in badness.

All I had to do was just throw in a check for the null. (I didn't want to go back to the old code order in case that really was to get rid of a bug.)

Well, that was simple. The bypass mentioned above was the solution - I just wanted to be sure by reproducing the issue first so I could tell if it had been fixed. Let me know if you have more trouble.

Those aren't console logs; they're actual code from the plugins. Knowing how you set up the dualtech (is a dualtech involved??) would help too.

UPDATE 1: I don't know what's causing the bug yet, but I do think I could probably bypass the issue even without reproducing it. I'd like to be sure, though, so I'm looking up the Moghunter plugin you're using.

UPDATE 2: I got it to repro. I've been testing with Jay's Journey. Weirdly, it did not repro with Dualtechs 3.0, only 3.2, which is why I hadn't seen it in Jay's Journey (where I forgot to update my own plugin.) So what changed? I'll figure it out. Whatever the case, Moghunter's plugins are irrelevant.

Interesting. My main project uses YEP's CTB and I haven't encountered this, though I am probably not using the latest version.

Just looking at what the error is, it's looking at a "null" (in other words, no data) and trying to treat it as a skill/item. So somewhere along the way, it's getting an invalid skill. But I don't have enough info to pin down where from this alone, I'm afraid.

Perhaps show me exactly what you're doing when this bug occurs? It would make it easier to track down.

Doubtful. I sorta I overlooked this one when I updated my plugins for MZ.

Aha. I wouldn't have guessed that was it. Well, whatever. The Permanent Skill Prefix wasn't a particularly difficult change (I actually accidentally enforced it in the very first version of the plugin ever, so I already knew what to look for when I made that update), and what I wrote above was pretty much written off-the-cuff and wasn't tested.

I'm surprised they didn't update meetsSkillConditions themselves. Would have been a godsend for compatibility.

I honestly don't know if anything simple I write would be compatible with that plugin due to that, but try adding this in a patch after their plugin:

var skillConditionPatch = skillConditionPatch || {};
skillConditionPatch.meetsSkillConditions = Game_BattlerBase.prototype.meetsSkillConditions;
Game_BattlerBase.prototype.meetsSkillConditions = function(skill) {
   if (this.isActor() && !this.eqsSkillEquipped(skill)) {
      return false;
   }
   return skillConditionPatch.meetsSkillConditions.call(this, skill);
};

And I make no promises; this is untested. If that doesn't work... well, all due respect? I'm not rewriting my plugin just to deal with a plugin that wasn't really made with general compatibility in mind that may have been abandoned over seven years ago.

EDIT: Another possibility would be to patch eqsSkillEquipped.

All right, success! I have a properly-looping OPUS file! The loopstart and looplength values given above do, in fact, work, with a tweaked plugin. Just trying to decide on the best way to package that for consumer use. I could do what I do for the tempo ratio and calculate fractions or let you input the sample rate for tracks that don't have one... or just let you do the math yourself and input decimal values.

A solution like this could repair the "Starting point" issue too.

EDIT: I'm leaning toward the sample rate option. Just have it ignored when the file actually has a proper sample rate.

Okay, interesting results, and I don't know how meaningful they'll be to you:

When the OPUS file is loaded, it has a sample rate of zero, and an automatic loopstart of 0 and looplength of... the track's length in seconds, as a double (that is, number with a decimal place). This happens to be the length of the original OGG file in samples divided by its sample rate. This may be salvageable, but it means you'd have to give the loop properties in terms of timestamps instead of sample numbers, which may be less precise.

So Starboard Authority has a length of 7,631,360 samples and sample rate of 44100 Hz. Its loop data is set to loopstart: 265,970 and looplength: 6,881,514.

The OPUS file gets a natural "looplength" of 173.04672916666667, which is its (very precise) length in seconds. So what happens if I skip over the sample rate math and set the loopstart to 265970/44100 = 6.031065759637188 and 6881514/44100 = 156.0434013605442?

...

Failed to set the 'loopEnd' property on 'AudioBufferSourceNode': The provided double value is non-finite.

Well, that's disappointing. What the heck is "loopEnd"?

EDIT: Oh. That's stupid. It tried to add the two numbers... as strings, which of course doesn't work. Why the pfargtl did it do that?!

All this said: The variable mix stuff - the meatiest part of the plugin, and the whole reason I made the plugin in the first place - still work as intended. I haven't yet tested every feature, but the loops seem like the biggest thing likely to break that did, in fact, break.

EDIT: Nope, one more thing is broken: the "Play from" (or "Starting point") attribute hangs the game.

Figured it out. The calculated sample rate of the OPUS files I'm testing with is ZERO. There's some math in my plugin that divides by the sample rate at one point, and division by zero = bad result.

If there's some equivalent of the sample rate in the metadata, or if I could fake it somehow, this could be patched.

Okay, I attempted to convert the Jay's Journey tracks "Starboard Authority" and "Starboard Authority (Alt)" into OPUS files. They play just fine so long as I don't mess with the loopstart and looplength attributes (which, true to what you said in that topic, do not work properly). If I do alter those attributes, then upon playback I'm greeted with:

Failed to set the 'loopstart' property on 'AudioBufferSourceNode': the provided double value is non-finite.

So either there's a previously-undetected bug in my plugin, or there's an issue with OPUS files.

(Actually, I did discover an undetected bug in my plugin. I'll, uh, just go and release a new version for that. But it's not one related to looping or OPUS files.)