itch.io

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

This plugin does not require a side view. (In fact, it's easier to animate without, but it's easier to give an idea of what's going on with one.) In fact, one of the "preview" pictures shows an MV battle that isn't in side view.

The first is definitely not a trivial ask. I don't know how feasible it is, but it would take a huge rewrite at the very least. And it's very reasonable to assume that such a system would allow actors 1 + 2 and 1 + 3 as separate "teams", but that would be an even harder case, at least if actor 1 can call the dualtech (actor 1's skill menu would have to list the skill twice, and the skill menu kinda doesn't allow for that. Interestingly, that's actually a supported scenario in the current plugin so long as actor 1 can't call the dualtech, since one person not in the tech - either actor 2 or 3 in this case - can still call it themselves and be treated as part of the tech.)

The second probably isn't feasible for a few reasons, most notably the damage calc. If there are C's and D's and so forth in a non-dualtech damage algorithm, the algorithm will always fail and return a default value of 0. So any such tech would be forced to only use A (meaning the direct user of the skill) for actor stats, or be a stat-ignoring status move, or it wouldn't work in the solo case. (Any workarounds for that one fall into the "no one-size-fits-all solution" category or would require extra work on the part of game developers.) There are other issues, but that's probably the biggest one. It seems far and away more practical to just create a solo version of the skill separately.

And done. Like I said, wasn't hard. As I say in the Devlog, once you update, please open the Permanent Skill Prefix parameter and press "OK" once, even if an exclamation point is fine, or the system might have trouble with the new parameter.

That's the plan.

I was mulling this one over for the last day, as I'm not sure how many people would use this feature. Eh, I can easily do it, but I think the best way would be a developer-definable symbol in front of the skill. Let's say it's an exclamation point. For example: if the skill has actor 1 use Slice and actor 2 use Dice, and you want the dualtech to only work if the skills have been permanently learned, you'd write <Dual:1,!Slice,2,!Dice>. (And you can change that symbol to something else in case you're actually using exclamation points at the beginning of skill names.) Thoughts?

The thing I found was the solution. It was actually simpler than expected. Just a bit hard to find because of the obfuscation.

Actually, I found something that might help. It's worth a shot, anyway.

Eeeeehhhh... VisuStella obfuscates their plugins so you can't see the inner workings, and the problem is one of rewriting a function that they have almost certainly overridden already without breaking their functionality.  I know that VisuStella is popular for MZ, but I'd be flying blind on this one. Things were so much easier with Yanfly, and he actually accommodated the text width return value...

Regarding the extra 10 MP cost, this plugin isn't really designed that way. It could be faked, though, by making three copies of the tripletech, each with itself as a component for one character with an extra 10 MP cost, and making sure each character learns the correct variant. Obnoxious? Sure, but writing that as a direct option wouldn't be trivial, and I haven't seen anyone else request such a feature.

Yup!  What you describe ought to work just fine. Heck, you don't even need to do multiple preloads if all are the same music file; each time you play, you can just use the same preload but define different loop parameters in the PlayBGM command.

In the example video, that's the trick I use in the Cymore part of the video, though there it's not in battle. When you first enter the little graveyard area on the east side, it plays a short loop of the song's intro that will last until you leave. Once you head west into the main town, the loop parameters change and the full track is allowed to play.

EDIT: Okay, looking back at the example video, it's not that clear that I did that. I had another example video that made it more clear: