itch.io

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.)

Hm, loop points don't work in an OPUS file's metadata? Well now I GOTTA know how my plugin interacts with them, since it can override the metadata and define different loop points.

You'd probably have to host a link to somewhere else, or I could try converting an OGG I suppose.

I have never tested. If RPG Maker can run them and there's an equivalent for an OGG file's sample count, then it may. If you'd like me to test, then do you have a good OPUS file to use?

Oh, yes, and because it's only PARTIAL support, the MZ version is, for now, listed as a "demo" for free.

Well, let's call this one "partial support for MZ". Subtitle window was fixed, but anything requiring Battle Core in the MV version is presently unsupported (I thought I had battle motions figured out, but with or without VisuStella they're still just not quite usable right now.)

My two "big" plugins got updated for MZ; I probably should at least look into the rest. Let's see what I can come up with.

Small warning, though: some of this plugin's biggest features were designed to work in tandem with Yanfly's plugins. Visustella is the closest MZ equivalent and is significantly harder to work with. So an MZ version might be feature-light, at least at first. But I should, at least, fix the subtitles. (I believe the basic functionality, except the subtitles, already works in MZ.)

Glad to hear it! I do try to make my plugins robust and easy to use!

Huh, RPG Maker usually keeps playing a track that was playing when you load a save. I'm wondering what mistake they made... Well, whatever it is, I've thoroughly tested my own plugin. Currently-playing tracks will keep playing upon loading a save, and just to make things all the more convenient for developers, any tracks you preload should automatically preload again upon loading a save too!

And if you buy my plugin and have any problems anyway, let me know what happened and I'll do my best to fix it.

You can either use icons or turn on the "Cycle Actors" option. (Or even both at the same time!)

There are multiple ways you can handle icons. The simplest for a non-coder is to use this plugin (it's free!): https://heroicjay.itch.io/actor-icons NOTE: I never updated this plugin for MZ, but setting an icon through <icon:##> should still work even there.

"Cycle Actors" is an option in the plugin settings. It makes it so that only one actor's details appear at a time, and the displayed actor will cycle every second (by default; there's also an option to make it shorter or longer.)