itch.io

Greetings.

I assume (from context, correct me if I'm wrong) that you're using MZ, as you mention the VS plugins specifically. Unfortunately, my dual wield plugin doesn't split damage in MZ anymore, as a result of changes made to a certain version of the VS Battle Core plugin, namely that VS team decided to include their own version of dual wield damage splitting, and the obfuscation prevents my plugin from knowing the exact formula they use for the offhand damage calculation.

With that being said, the Weapon Attack formula plugin also cannot affect the offhand weapon swing differently than the mainhand swing, because I have no way to know how VS is calculating the damage of that offhand attack anymore, nor do I have any way to modify the formula for one hand specifically. 

So, in conclusion, you're not wrong, it is ignoring the weapon formula of the offhand attack. But it's the VS BattleCore plugin that is ignoring it, and the MZ version of the dual wield plugin can only do damage splitting properly if you downgrade your version of the VS_BattleCore plugin to a much older version, and downlaod the older version of dual wield from the devlog.

Thanks for the report, I'll get this fixed in an update shortly.

The two are probably read correctly, but will stack the effects, so an attack with that tag would be unblockable and would bypass guard, and you have no way to tell it to do one or the other, only both.

It shouldn't, but to be honest I'm not sure how VS dual wielding works.
The only way I could see it not being compatible is if you're using one of their fancy damage type things from the BattleCore plugin.

My plugin only interacts with the damage formula, so it shouldn't be incompatible with anything in the VS plugin suite, unless they did something where they overwrite the damage formula evaluation function. Generally they're pretty good at not doing that.

This plugin doesn't even actually make changes to the way the formula works, it just gives you a couple of new functions to plug into it.

~Ramza

100% this. I'm happy there are still people that this sort of thing appeals to.

Good evening.

I can't honestly recommend anyone pay full price for this plugin if that's all they need it for, and that's really all its capable of doing in its current form, unfortunately. When the VS team implemented their own dual wielding thing into their battlecore plugin, I would've taken this plugin down completely, if not for the people who'd already bought it. At that point, though I couldn't heavily discount it because that wouldn't have been fair to those people either.

I found a topic on the rpg maker forums for another plugin to add requirements to equips, an a poster in that thread has shown how it could be possible to use that plugin to limit what's in the off hand, based on the main hand.

Click here

Good luck.

~Ramza

As of the latest update, there should be no reason for an offhand attack to be happening with a shield, unless the shield is classed as a weapon in your database. Actors aren't considered dual wielding at all if they have a shield in their offhand. 

As for the extra barehanded attack, I went through a bunch of troubleshooting a couple months ago and ended up fixing some bugs with that in the latest version.

My first suggestion would be to update your plugin if you haven't done that lately.

~Ramza

Thanks for digging into this.

If I understand correctly, I can fix this issue by setting that flag to true during the creation of the window that causes the video playback to start. I did a quick test on my own, but I'm not able to reproduce the sound carrying through issue on my end at all. In my simple test I have one splash video and nothing else. Hitting a key to skip it, or pressing a mouse button seems to skip it normally with no sound continuing through to the title screen. If I do it with two videos, and skip them both, I get the same - no sound playing through the title screen. 

I added a line to set that flag as true in the window that shows the videos immediately when it is created, and that doesn't seem to stop anything from working on the splash screens, and doesn't cause an issue with audio playback, but I never saw the original issue so I don't know that it fixes it either.

Window_DummyWindow.prototype.initialize = function(rect) {
Window_Base.prototype.initialize.call(this, rect);
this._frameCount = Ramza.PTS.params.waitFrames - 12
this._waiting = false
Graphics._videoUnlocked = true
};

Basically I just added the last line to that function in the MV plugin. Try that and see if it changes anything? I suspect it might also cause an issue with video playback elsewhere in game, as the flag will start true unless I also reset it later.

Greetings.

As discussed via discord, the MZ version of this plugin doesn't do damage splitting anymore. The older version uploaded onto the devlog for that post is the last version that did damage splitting, or any visual changes to battle or menus for MZ. 

The reason for this was twofold:

• The plugin requires Visustella BattleCore to function, or it did, rather, and while I had (have?) plans to change that, I haven't had anywhere near enough time to try.
• An update at the time to their BattleCore broke compatibility with this plugin (as mentioned in the devlog at the time), when I reached out to their team for help fixing the problem, whoever it was I was working with (I don't recall now) decided that something very similar to my dual wield implementation could be put directly into battle core. Doing this broke my plugin, and basically removed any need for it to exist, and since their code is obfuscated, the menu changes this plugin made to display main or offhand atk values on the status scenes also couldn't be trusted to be correct information, so I removed that as well.

Despite the above change, I did leave this up on the store, and there's a big blurb at the top of the store page for it explaining how it does and doesn't work, and how you're free to modify it. But the gist of it is that the plugin now is only capable of locking weapons, setting up monkeygrip, titansgrip, equipping a shield in the offhand of a dualwield actor, and preventing certain wtypes from being used together.

As for your suggestion, and as discussed previously, I thought I had implemented something like this in the DW plugin already, and can confirm there is a function that does something similar, but I think after looking into it more, it just stops skills with the mainhand or offhand lock function from being usable if that weapon is not one of the weapons the skill is allowed on. Realistically it wouldn't take much to create extra functionality there to temporarily lock the weapon to main or off hand depending on the wtype required by the skill for a dualwielder, and extend that to dual wield skills as well.

As above though, while I could get this to work in MV, the MZ version of the plugin has lost this functionality completely after the VS_BattleCore update, and if I'm being honest, I sort of stopped following their updates after that, so I'm not even sure if their implementation even works anymore. The MV version also needed BattleCore to function, and so if you were to try to use something like FOSSIL to port it over to MZ, it also probably wouldn't work for you.

Good luck and Godspeed.

I'm glad to hear it, and can't wait to see what you can do with it.

No, this problem will still happen with my plugin as well.

The reason is because there are certain times where an enemy, or an AI controlled ally will run a function to check to see what the most damaging ability to use would be, and to check this, it test runs the damage formula of each skill on a target. If your damage formula has other functions inside it, these functions will end up being run during the test, even if that skill isn't the one that ends up being used. Like if, for example, in every damage formula for every skill, you have it count up a unique variable, so you can check the variable later to see how many times the skill was used. That variable will go up by one every turn if the enemy is testing the damage of the skill.

Unfortunately, all this plugin does is allow you a damage formula shortcut, but everything that the damage formula is used for will still use this formula too, so the problem is still present.

Best practice is to move any calculations, or variable changes to either a common event on the skill (which is run after the skill is used by default) or into specific note tags on from the YEP_SkillCore plugin, specifically an after eval will run after the skill is used and has landed the hit.

~Ramza

Hey there.

I'm really not sure that there's anything I can do about the sound continuing into the title screen. Some other people have reported it as well, and the truth is, this plugin is only reusing the built in function that rpgmaker has to play videos. I suspect this is an issue in the engine itself, and I don't have the know-how to fix it. 

The best suggestion I could think of was to have the final splash video just be a couple of frames of a black screen with no sound, so that if the skipping bug happens, there's no audio continuing.

I'm glad you solved the other problem on your own, I wouldn't have guessed that as the cause, although it makes sense. The two different video formats are for mobile and desktop deployment, so it should only keep one of the files on deployment depending on which platform you targeted. If both ended up in the folder, I could see how the engine could get confused.

~Ramza

You can do mostly anything you want in a custom block effect, so technically it would be possible, you just need the know-how to program it in.

Blocking can be enabled by a state already, so your barrier magic just needs to turn on blocking, add a 100% block chance to the state and set a specific effect on it's <Block Effect: name> tag. 

Then you need to define in that custom block effect what needs to happen. Block trigger off the block rate, and if yours is set to 100%, it will always trigger. So to remove a set amount of damage from an incoming attack, you'd just do what the standard block effect would do with the flat block value, and take it away from the damage result. If it fully mitigates it, it would show the 'block' text popup, and the actor wouldn't take any damage at all.

Now, you'd have to define the block amount ahead of time, and adjust it as the actor blocks incoming hits, and also remove the state when that total blocked amount reaches that M.Def amount you talked about. But that shouldn't be too difficult. The real difficulty would be if you had this effect happening on an actor who also had a shield that could block using some regular effect, since block effects don't stack, so he'd either get this barrier effect when he blocked, or he'd have 100% chance to do a regular block, taking no damage at all for the duration of the state.

Glad to hear it. I always love seeing people thinking outside of the box with my plugins. :)

Good question.

I'd never thought to try it before, but it turns out it does work.

The only problems with using a real FV battle system, is that the block animation has nothing to play on. The sound effects trigger like a normal skill animation though, so there is some audio feedback. 

Additionally, the MV version of this plugin doesn't have a 'block' damage popup, so there's no feedback that a block occurred at all except for the sounds from your block animation. This is because MV gets all popup text from a system file, while MZ draws text on the screen, so the MZ version of the plugin could show a block popup when a block occurred.

Anyways, it does work, which frankly surprised me.

~Ramza

It looks like this might be an issue with caching. I suspect because the splash screen loads as one of the first things the engine does, it tries to render the first splash screen before the images for it have been cached. 

A plugin that pre-caches specific images might resolve this, but otherwise the fix would be to apply a brief wait period on the splash scene before any splash screens are supposed to show. It might only take a few frames, so it could be nearly unnoticeable.

I'd try a precache plugin first and see if that helps at all. Patching the plugin is also an option, but I haven't had a lot of time for updates lately, so you might be stuck waiting a long time for something that could be a real simple fix.

~Ramza

Alas, that one is intended. 

The intent was that you could turn off an extra barehanded attack if your offhand was empty, mostly for two handed weapon use, honestly, but if you're using no weapons at all, in the normal engine, the actor would still make a barehanded attack, so his main hand should always be considered armed, even if he has a weapon in his offhand.

Changing that in particular would be difficult because the plugin was not designed with that in mind. Attacks always come from the main hand first, the only exception being if the offhand is locked during a skill. To change it permanently would be much more involved than the change I did to make the offhand empty attack not trigger.

~Ramza

Ah, I probably missed that contingency when I rewrote the code again. I'll have it fixed in a few minutes.

Edit: the fix is live, redownload it from the devlog or the main page again and it should say it's version 2.76a now.

Good catch.

The problem was with a function that returned whether or not an actor was currently dual wielding. For some reason, when I rewrote that function on a previous update, I completely neglected to take that plugin parameter into account, so it was always considered dual wielding, whether or not the parameter was set.

I have uploaded the fix for that just a few minutes ago.

Hey there.

Sorry that this happened to you. Itch.io can refund your payment, and you can use the refund to buy the correct version. I think that's probably the best thing to do in this situation. If I simply have you the plugin, you wouldn't have bought it, and you wouldn't be able to download updates for it in the future.

I'm not sure how long it takes them to process a refund, it might take a while, so apologies in advance.

~Ramza

What plugin are you using to get that <WeaponPower: x> tag?

Since the value of that tag is being used in damage calculations, it should be pretty easy to isolate it on a per weapon basis similar to atk. I'd just have to know what I'm looking for to devise a patch.

~Ramza

Greetings.

1. The only incompatibility I'm aware of between Dual Wield and Yanfly plugins is weapon unleash. Yanfly's weapon unleash doesn't work with default dual wielding, it only unleashes the skill of the first weapon, and that is how it works with my dual wield plugin as well.
2. Multiline formulas work in the note tags on weapons, but I don't think the code box in the plugin params supports them. Single line formulas that call other functions work great, and are probably better to use in such a case. In that case, you can pass a (subject), b (target), or any other value attached to them to the function as well.
3. Dual wield and weapon attack formulas are 100% compatible. Skills that lock to one weapon use the formula for only that weapon. Individual hits from multi hit skills (and a dual wield attack) will use the weapon formula for whatever weapon is being swung. 

I understand asking questions prior to purchase. These aren't cheap plugins (the cost of them combined can be more expensive than you can get MV for some of the time), and it's good to know exactly what you're getting before you buy them, for sure. 

Let me know if you have any other questions.

~Ramza

Hello there.

I have a couple of thoughts on why that might be happening.

First, it could be that the audio codec used in the video is not supported on the target platform. To verify this, I'd first try playing the video directly using some sort of media player. If that works, the next step would be to try to play it in a normal event in the engine.

The other option is that something set the volume of all videos in engine to be muted. The plugin doesn't have any built in video controls, so it should use the defaults. It might be possible that during a previous test play you muted the video from somewhere else in the game, and that setting is kept during the splash videos.

Audio should be supported. The webms I, ahem, legally acquired on the internet to test it with had audio, and the audio playback was fine. There have also been complaints of the audio continuing onto the title screen when skipping videos, so other users have had sound working as well.

Unfortunately there isn't much more troubleshooting I can do, as all this plugin does is launch a container for the video which is already something rpgmaker did.

~Ramza

The weapon formulas can contain anything that would normally work in the damage formula. As such, you can use a ternary operator to return one of two numbers if a specific condition is met:

a.atk *4 - b.def *2

This would be a normal damage formula.

a.isStateAffected(4) ? (a.atk *4 - b.def) : (a.atk *4 - b.def *2)

This adjusted formula would be the normal one if the actor does not have state 4 (after the ":") or an altered one if he has the state, in this case halving the enemy's effective defense value. You can also nest these operators together, allowing a check for multiple states in a row and modifying the formula accordingly:

a.isStateAffected(4) ? a.isStateAffected(5) ? (a.atk *4) : (a.atk *4 - b.def) : (a.atk *4 - b.def *2)

If he has states 4 and 5, he ignores defense completely, just 4, he halves it, and if neither, full defense.

You can turn that window off completely if you're not using it, otherwise I'd have to add a plugin parameter to removes those line breaks.

You can turn off the category window completely which will make it sort all available items/weapons/armors that can be used into the main window. I think it'll probably list everything the player has though, so if you never plan to use weapons or armors or key items as ingredients, it might not work for you. I'm not at home right now, but there already was an option to add custom categories to that window as well, from yanfly item categories plugin, so it shouldn't be too difficult for me to modify that a bit and make that configurable.

There is a run once on completion uh... code box, that lets you run a script call after the craft completes. There is a way to reset it after using it so it runs every time, but I'm not at home right at the moment to double check it for you. You could use this to turn on a switch which would trigger the common event. The main problem is that common events don't normally work from inside menus, so you'd probably need to get another plugin entirely to call an animation on the menu screen, and then call that plugin from the run once script call.

I don't think there's currently a way to disable the progress bar for just one craft category, but you could set the timer to be very short, like, one frame, and it would basically be instant. I can consider making this more configurable in an update.

I'm not entirely sure what you mean by the two black bars, is this because you have the window skins hidden and it's showing something weird that'd normally be hidden?

~Ramza

Hello there.

I have sent you a DM on discord, but it won't send because we don't currently have any servers in common. My discord handle is @capnrammo. I'm sure I posted it... somewhere on here.

Anyways, the good news is that I'm pretty sure I know what the problem here is.

Your first issue with the crash on the item scene is because the plugin parameter "Updated Scene Item" from ItemCore is true and it should be false. That parameter makes ItemCore redraw the item scene in a fancy way in MV, but in MZ this breaks the whole scene because it was never intended to be used in MZ. Because of that, the independent item patch doesn't touch any of those windows the updated scene tries to draw, so it throws that error when it tries to draw a window in the old MV way. Disable that parameter in the demo and it will stop doing that.

Near as I can tell, every other problem you're having is because of the demo project. The demo project works out of the box, without modification. If you redownload it, extract it, open it in MZ and run it, you can craft any of the recipes included without issue. The problem is that the demo project was intended only to ever be used with version 1.00 of the original plugin, which it includes already. Since that release, I split the plugin into the core and the MZ/MV versions, and the demo doesn't work with that. So if you update any of the plugin files in the demo, you need to do a bunch of troubleshooting to get it to work again.

The demo is more for seeing how it should be set up, so you can compare it with your own project as you make your own recipes. If you import the newer versions directly into your project, they will grab the default plugin parameters and should work just fine, but the demo version already has parameters setup for the plugin, so it doesn't reset to defaults, and gets a little messed up. One way to check this is that in the plugin params for the bug project you uploaded, there are no recipes listed at all.

However, even after adding one, it still can't be crafted and returns a total failure, as you said. On the other hand, all recipes in the unmodified demo project worked fine, and making the same recipes in a brand new project with the updated plugins also works fine (although setting it up takes quite a bit of work).

As for refunds, itch does allow you to refund your purchases, and I have no personal problem with refunding a plugin you can't make use of, or that doesn't work the way you wanted it to, after all, it's hard to know exactly what you're going to get when you buy something like this. But at this point, the problem is purely configuration, and it can definitely work. Many people have purchased, used, and even modified this plugin to great effect, and I'm sure you can get it to work too.

~Ramza

Hey there.

If I'm being honest, I don't know as much about windows and menus as I probably should, and a peak into the code will probably reveal that to anyone who knows what to look for.

That being said, the windows I create in this plugin are bog standard in pretty much every respect, so whatever you did to the menu to hide the background, border and blur should also work just fine in the crafting scene. If that was a plugin designed to do that to multiple menus, it should be as easy as adding my window names, scene_craft to that plugin to enable it. 

Depending on how the plugin was made, it might already do that to all scenes and windows, so maybe it would already work with my plugin, too, assuming you haven't already tried it, anyway.

If it was something more custom that you did yourself, you should be able to modify those windows in the same way you did in the main menu.

There isn't anything in this plugin that should be a problem if you were to do that, anyways.

~Ramza

Unfortunately, since the VS plugins are obfuscated, I don't know what they do to the damage formula to be able to use the damage styles.

In theory, since all my plugin does is replace some keywords with a formula, you should be able to set the formula to just return a flat number and it should work with the power damage style, but that's assuming they didn't modify the damage formula to the point where it ignores my changes.

~Ramza

Hello.

If I'm being honest, I haven't put much thought into porting it to MV since this post was made 3 years ago. I still have the same major issue, which is that plugin commands in MV are inferior from an end user perspective.

In order to make the two plugins as close as possible, I'd likely need to look into some kind of electron app that would take the inputs of a dev in a similar manner as the MZ plugin command window does, and outputs the results in one giant line for use in the plugin command event command for MV.

If I wanted to go the route of having the features be slightly different, the MV version could define the shops on initialization, so that creating them could make use of the plugin parameters in the plugin instead of plugin commands. But this would prevent Devs from defining them mid game, at the very least, and adding or removing or changing stock in a specific shop is still going to take a giant plugin command that'd be easy to butcher when you're typing it in, making it hard to use, and hard to troubleshoot if it's not working.

The best workaround I can think of is either breaking the plugin commands down into individual calls, and using regEx to parse them like note tags. But I'm not sure how that'd handle custom costs, and a whole host of other things, really.

Even as a dev who's not afraid of a little jank (trust me, look at the crafting plugin), myself, the prospect of having to type in a bunch of easily typo'd text instead of clicking from dropdowns and menus scares me a lot.

~Ramza

Okay, well that thing is unrelated to the other thing. That's actually a known issue with how dual wield attacks work in the system.

During the act of attacking, each weapon is unequipped for the attack of the other hand. That means if the only source of the dual wield trait on the actor is one of his weapons, when it is removed, he's no longer dual wielding. That causes all kinds of wonky behavior, and that's why you want the trait on either the actor, or his class, or a permanent state (from the yep passive states plugin).

Good news, I fixed the problem. The issue was from the new parameter in 2.74, equip only mode, which most people wouldn't be using. I'd messed up a check for if that parameter was enabled, which was causing the isCurrentlyDualWielding() function to return true without doing any checks to see if the actor was actually dual wielding.

The idea behind this check was that if out of battle, OR if the plugin parameter was enabled, it would only ever return the actual slotType of the actor (for which 0 is normal and 1 is dual wield type). This was to maintain compatibility with in combat plugins that also relied on knowing if the actor was dual wield type or not, like the YEP equip change in battle plugin.

But since I'd accidentally reversed this check, if the parameter was disabled, it would trigger that check, which was returning if the actor was dual wield type, and not if he was actively dual wielding, as expected. Which leads to your problem, where a two handed weapon was considered dual wielding. It likely also had the same problem with actors using a shield in their offhand, although I didn't test for that.

I have uploaded v2.75 which corrected this bug. Everything should work fine now. Thanks for the report, and sorry it took me a while to find the culprit, as I said, I didn't have my test environment running on my new windows install, so I was honestly trying to avoid doing that as much as I could by asking many questions from you about your specific use case.

~Ramza

Okay, that is weird. 

So where the battle system is picking up that the actor is currently dual wielding, even when he isn't,  one of two things is happening:

• The weapon isn't actually twohanded
  • Maybe something broke the notetag, or the function that turns the weapon twohanded?
• The function that checks if the actor is currently dual wielding isn't properly detecting the actor as wielding a two handed weapon.

To test for the first thing, in battle, from the console, we can use almost the same script as before:

$gameParty.members()[1].equips()[0]._isTwoHanded

This will return true if the weapon in the main hand of the actor is tagged as two handed. 

If the script returns false:

• The <twohanded> note tag on the weapon is not present, or is otherwise not being parsed, maybe it's inside of another tag by mistake, or has been typo'd
• The note tag is being parsed, but it's being removed by something else, this would be the weirdest compatibility problem I'd have encountered, as something would need to be specifically removing that value from every item after my plugin loaded, which would almost be malicious.
• The note tag exists, but you're using an older save file from before this plugin was installed to test, meaning the items in your savegame's database are from before this note tag was present to be parsed.

If the script returns true:

• Something might be removing your weapon temporarily during the attack sequence. This could be a state, or an action sequence. If at some point during the skill use you don't have a weapon, the system considers dual wielding barehands as dual wielding, so it would call your actor dual wielding.
  • If that was the case though, it wouldn't consider you as currently dual wielding via the previous script call except for in the middle of the attack sequence, meaning it should show false on that above script check during the idle part of battle.
• There is a problem with the logic in my function that determines if someone is dual wielding, that isn't taking into account a two handed weapon. That's be a major bug, and it'd be weird if no one had noticed it until now, but could be possible.

For transparency sake, I haven't tried to recreate this problem yet, as I had recently fully reinstalled windows and haven't set up my test environment yet. If the second option above is true, I should be able to easily reproduce the problem, though.

Anyways, put the above script into the console and see what it gives out, I'll get my test environment going here and start seeing if I can reproduce the problem.

~Ramza

Unfortunately, weapon unleash isn't exactly compatible with the dual wield plugin, so I wonder if the problem is coming from that?

Can you try, for experimentation sake, using the twohanded weapon without weapon unleash to see the 'normal attack' skill that it would usually use and see if it also hits twice? I'm not entirely sure how weapon unleash codes its skill usage, but dual wield only 'detects' a skill as dual wielding automatically if it's the first skill in the skill list, or if it's tagged specifically as a <dual wield> skill, but the only effect this would have would be to have sequential attacks switch weapons (and damage) within that skill.

Moreover, the problem seems to be that the game is deciding that your actor is dual wielding, when he's not, which is triggering the extra attack even when he isn't.

During battle, can you open the console (f12) and put in the following script?

$gameParty.members()[0].isCurrentlyDualWielding()

Replace the 0 with the index of the party slot where the guy with the two handed weapon is. If he's the lead, he'll be index 0, if he's the second in line it's index 1, etc.

For someone who's actually actively got two weapons equipped, this should return true, but for someone using a twohander, it should be false. It should also return false if you have the barehanded attack parameter disabled, and he's got a one handed weapon and nothing in his off hand, or if he's got a shield in his offhand.

If that's coming back true, we probably know where the problem is, it's that the engine is detecting the user as dual wielding when he's not, and I can go from there to figure out why.

If it isn't detecting him as dual wielding via that script, then something is adding an extra attack to your skill, and that could be the skill unleash incompatibility I was talking about earlier. The dual wield plugin does make some 'secret' changes to the action sequence of the attack skill, and to any skills tagged with the skill tags.

It could also be something simple, like a trait adding an extra attack to the actor, which would also make the regular attack skill hit twice.

~Ramza

So the weapon is not using the standard attack skill, but some other skill?

Is that via the Yanfly Weapon unleash plugin? What are the note tags you're using on the skill that it is using? Is it tagged as a dual wield skill? Does it have a unique action sequence?

~Ramza

Hello there.

When the actor is using a twohanded weapon, do they have something in their offhand, like a shield, or is that slot  completely empty?

Is the two handed weapon tagged as <twohanded>?

Are you using the Monkey Grip extension, and is the actor monkeygripping?

I did fix a bug like this in a previous version but it may not have been the exact situation you have going on right now.

~Ramza

Certainly. The scene is called Scene_SkillShop

~Ramza

I think it's getting confused by what you're giving it. 

You're specifying that it needs three of item ID 2 and one of item ID 6, but you're also telling it that it needs 3 of category 'Runes' and 1 of category 'Runes'. The category option overrides the individual ingredient option, so it doesn't matter what ID you set there.

Category ingredients are for being more vague in your recipes, so this likely isn't what you want at all, given you have given names to the runes you used. Get rid of the category and see if it works that way. Right now, the recipe is set to need 3x 'runes' and 1x 'runes', meaning it is looking for 3 items in the runes category and one item in the runes category, not the green or grey rune specifically.

What I think has happened is that your rune items don't have a category on them, because you didn't use that note tag. The recipe, because it has categories set, is ignoring the item ID part, and is only looking for runes, which these likely aren't. You'll want to remove the category from the recipe.

Alternatively, you could add the <craftCat: Runes> note tag to those runes, and the recipe would probably also work, but it would work with any items in any order, like 3 grey runes and a green, or 3 red runes and a green, or any other combination of 3 and one runes items.

I'm also not sure, but the DQ mode might require you to set the ingredients one by one instead of putting a quantity. So you'd set the recipe as green x1 green x1 green x1 and grey x1, instead of green x3 and grey x1. You  probably want to change that back to normal mode, because that's not what most people want.

~Ramza

Hello there.

You cannot add the same ingredient to the recipe list multiple times from the crafting interface. Instead, pressing right on that ingredient in the list increases the quantity of that ingredient being added. Pressing left on it will decrease the quantity by one. If the quantity is already one, pressing left will remove it from the list instead. I, uh, never came up with a way to do this using a mouse input, so you have to use either a keyboard or a controller input to change the quantities.

If you want the player to have to put in three separate instances of the same ingredient, you need to set it to DQ mode in the plugin parameters, so it allows you to use the same ingredient multiple times.

That last bit does sound like a bug, as the videos don't play on the title scene at all, so there should be no menu or anything for the player to interact with.

The incompatibility with the CustomLogo plugin is likely the same thing that broke it in MZ a while back:

This plugin aliases the call to change scenes in rpg maker, which happens any time you swap from any scene to another scene. Menus, battles, map transitions, shops, etc. It specifically just calls the original function (so it works normally) unless the following is true about the call:

• The scene you're in is Scene_Boot (which is the very first scene that loads when the game opens)
• The scene that is called is Scene_Title

In that case, it intercepts that call and sends the scene manager to Scene_PretitleSplash (or something like that, I don't have the code right in front of me), which shows the splash screens in the given order, and then sends the player to Scene_Title after. If you have some other plugin (or the newer Core files for MZ), Scene_Boot doesn't point into Scene_Title, so this plugin never triggers. In MZ it pointed to a different scene called Scene_Splash, which I presume was created for a similar reason, but doesn't seem to be used at all except to then send the player to the title scene.

In any case, the incompatibility can be fixed by modifying my alias, by adding whatever the CustomLogo scene is called to the check, it will intercept it as it would the boot scene and work.

But also, this splash plugin can be used to show a static image as a splash screen too, so you might not even need that logo plugin if you're using this one.

I'm not really sure how it could be playing videos on the real title scene though, unless it's not waiting for the video to be finished before continuing on to the next scene. That would be a pretty major bug. I'll see what I can do about it.

~Ramza