itch.io

There is currently no way to do that exactly.

The modifier plugin parameters for dual wielding, offhand, and two handing a weapon can all be eval'd. By default, they're just a float number (0.75 for example), but you can use code in this box to make the number different based on a condition being met using a ternary operator: 

(user.isStateAffected(21) ? 0.90 : 0.75

Something like the above would make the offhand do 90% normal damage if the user is affected by state 21, or 75% or not. These can be nested as well, allowing for different levels of offhand mastery, or ambidexterity, or whatever

(user.isStateAffected(21) ? 0.90 : (user.isStateAffected(26)) ? 0.80 : 0.75

I'm not entirely sure that's the exact code you'd use to do that, I didn't get a chance to test it, but I had set it up once a long time ago, in an old project, and it was designed for that use case. It's not exactly what you're looking for, but it can work for what you need.

The hit and crit bonuses are weapon specific. Any source of hit rate or crit rate that isn't on a weapon is given to both hands, and any that is on a weapon is only given to that one weapon. There is no way to change this currently.

~Ramza

There isn't currently an easy way to do that. I don't do enough work with sprites to know how to define and draw one like that, unfortunately. I used battle animations for that reason.

However, since every block effect is custom defined, you can modify the definition in the plugin parameters to do anything you want it to. So if you (or someone else) can figure out how to draw an icon at a specific battler's position on the battle scene, based on the iconId of the icon of the shield currently equipped, you can put that into the block effect and have it happen. I don't really have the slightest clue how easy or hard that would be, though, but it's a good place to start, or have someone else start for you.

~Ramza

This plugin injects its calculation into the damage formula, so it should be fully compatible with any other plugins that change how damage is calculated, as long as they still use the damage formula box in the database to deal any sort of damage.

Hello there.

Most plugins rely on the .js file having its original name in order to read the plugin parameters. Mine are also like this, so it would've failed loading very early in the load process, likely without throwing any crash errors, and simply would've acted as if the plugin wasn't installed at all. That means the error you were getting from the Visu plugin was correct, that function is not a function - because the plugin which defined it as a function was not loaded :)

For what it's worth, there is a way to make plugin parameters work when renaming the .js file, but it needs to be written in a specific way to allow that, and as it was simply the easier thing to do, I chose not to do that, like most people.

~Ramza

Sorry, I haven't gotten a chance to look into it yet. It is in the pipeline, but it's a busy time of year right now.

Greetings.

This error is happening because both of our plugins are using the constant 'params'. You can edit both of our plugins to use var instead of const and it should stop that from happening. If you swap the order the plugins are loaded in, you'll find his plugin probably throws the same error too.

In my plugin this line is line 627, I'm not sure about his.

~Ramza

My discord account name is on my main page? profile? whatever it is, and you don't have to be my friend, or share any servers in common with me to send me a dm.

I'm not sure when, or how much time I can devote to helping you out, though, since I'm at work right now. But send me what you have and we can work something out.

~Ramza

I believe that is because when the character doesn't have anything in their offhand, the menu considers them only wielding one weapon, so it doesn't show the possible change of the atk value of the offhand weapon.

Unfortunately, I don't have a good way to fix this, as the VS plugins are all obfuscated, and I don't have a way to hook into and change their menu scenes. It's frankly surprising that there was any change at all on that one.

Does it evaluate the proper way on the equip scene?

~Ramza

Hello there.

I've never tested it with that plugin before. It doesn't do much to modify equip slots, only making it so the second weapon slot can also hold shields, so I don't think there'd be any issues. You might have to change around the load order and see if it works better one way or the other, though.

Of course, if there is any compatibility problems, you can always post about them and I can take a look to try to fix them, too.

~Ramza

Hi there.

It should show the category, there are options in the plugin params to control what it draws when it finds a category ingredient. At least one of the options has it scroll through a list of ingredients of that category, so the issue might be one of the ingredients it's finding being bugged or something.

I think what's likely happening here is that it's set to show the category name with an icon, but the icons weren't set up in the plugin parameters, so the window can't draw the icon because the length of the list is undefined.

That error could also be caused if you're using an old save, as well. Since the icon list might be tied to the save file or something. There's always something screwy going on when you use an older save file.

~Ramza

Thank you for saying. Let me know if you have any issues :)

Hello there.

Sorry that you're experiencing this issue. In order for me to track down what might be causing it, I need to ask some questions:

1. Are you using MV or MZ?
2. If you are using MV, are you also using YEP_ItemCore?
   
   1. If you're using MZ instead, are you also using YEP_ItemCore via FOSSIL, or from the Independent Items patch I'd made for use with my crafting system plugin?
3. If you are using ItemCore, are the food items giving the buff an independent item? You set this by setting an item quantity limit in the plugin parameters of ItemCore. 

I ask these questions about independent items specifically because they change the item ID of the item, and it might cause issues with this plugin detecting which item had been used (due to an oversight of mine, most likely). Clearly it knows the item being used is a favorite food, as it plays the sound effect, but it's not applying the effect to the actor, so something is going wrong.

~Ramza

Yikes. You've made so many aesthetic changes to it that if I'd seen this anywhere else I'd never have been able to tell it was my plugin at all.

I absolutely love it! :)

Thanks for saying so. When I first launched it, I wasn't even sure if people would want to use it over the yanfly synthesis one. This was the first plugin I'd made entirely for other people to use, and not for my own use as well. It feels good to get reaffirmation once in a while.

For now, I'd suggest making the ingredients independent items. I'll work on trying to fix it, but progress on that is going to be a little slow as I don't have a lot of time, and I've been using what little time I do have to work on a couple of extensions for this plugin.

So, ideally the traits were only ever supposed to work on independent ingredients/result items. When I first made the system that was the plan, but an oversight caused them to work with non independent ingredients as well. What was originally supposed to happen was that in order for an item to be on the 'additive traits' list in game successfully, it had to be put there by the dev in the plugin params, and also be an independent item.

Somehow, I'd mucked that second part up, and for a long time, you were able to have ingredients that weren't independent, but did have additive traits on them. When the other user I was talking about earlier reported a very similar issue, I realized it was possible in the first place to have additive traits on non-independent ingredients, but rather than fix the problem by disabling those traits on non-independent items, I "fixed" the problem he reported. 

As it turns out, my fix likely only worked for ingredients in the first slot. During the function that combines all of the traits on all of the ingredients, the traits of the result item were being added to an ingredient, which would never have caused a problem if the ingredients were independent items. The item that would inherit all of those traits would normally be removed from the inventory after. However, if the ingredient was non-independent, all instances of that item would inherit the traits. The instances already in the player inventory, the instances in the shops, the instances in treasure boxes. If you then make the same recipe again, that ingredient has way more traits than intended, and adds them all back onto itself a second time, causing the bonus to increase again.

Worth noting, is that those traits aren't saved on the item, so if you saved the game and then reloaded a save and crafted the same recipe again, it would be normal again.

The fix I applied to solve the problem originally must've only been for the first ingredient, or the first slot, or both maybe. I'd have to look more closely at what I did originally, to solve this problem for you, or find a better way to more permanently solve it.

-Ramza

Hmm.

I recall someone having a similar issue to this a long time ago that I'd thought I'd fixed. It revolved around the fact that his ingredient items weren't independent items (from the YEP_ItemCore), and a weird interaction with the way my plugin was adding traits together. It's possible the fix I implemented didn't take the second (or third or fourth) ingredients into account when doing whatever it was I made it do to fix the problem.

One question, though, are you using the YEP_ItemCore plugin to make your ingredients independent items? The problem I mentioned above was actually because the user wasn't using the ItemCore at all, and while that is okay, the additive traits were never intended to work in projects that didn't have that.

It isn't currently, but it can be.

You might be the first person I'm aware of who uses that parameter, so be sure to let me know if you run into any weird issues with it as well :)

Actors need something on them that enables block.

<Enables Block> needs to be on an actor, equipment, state, etc to enable to actor to block. Enemies don't have this requirement because they wouldn't normally have a block chance.

Hello there.

The second option from the top in the plugin parameters for the recipelist plugin should be the 'Bind to Main Menu' parameter. If you set it to false, it won't show up in the menu at all. Or... it shouldn't, anyway. There isn't a way to adjust where in the menu list it binds, without using another plugin which changes the main menu commands. There are instructions for how to bind it to the main menu using the YEP_MainMenuCore and the VisuStella Main Menu Core plugins in the help documentation.

If you're a little more JS savvy, the function starting at line 630 is where it draws the menu command. You can roughly move it around the menu command list by loading it before or after different functions that load the menu commands. It loads after addOriginalCommands(), so there will be plugins that load commands before it, or after it, if they alias different functions.

~Ramza

Good day.

There isn't currently a way to do this, as gold cannot be used as an ingredient. It would be possible to add a cost to the crafting run once function, and then re-enable the function for the recipe to have a recurring cost, but there'd be no way to indicate to the player that there was a cost, or that it was paid, and there'd be no way to stop the craft from succeeding if the player didn't have enough gold.

On the other hand, an extension to add gold costs (and actually show them in the crafting confirm window) is on my roadmap for this. I can't say when you could expect it to happen, but it's being worked on.

~Ramza

Hi there.

I'm not sure I understand exactly what the issue is here.

You can disable the menu binds entirely by changing the plugin parameter in the plugin settings, 'Show in Menu' set it to false, and there will be no menu access to the plugin. The command that would show if this parameter is enabled is a catch all 'Crafting' command, which opens to a menu to select a category to craft in. It will only show categories that you have made recipes for already, and if there's only one category available, it skips past this window to go straight into whatever that was (cooking in your case).

If you only want to call a crafting scene from the map, set the 'Show in Menu' parameter to false, and ensure that you don't have any categories listed in the 'Category Menu Commands' parameter. There is no need to edit the plugin file itself for this.

If you want some categories to be accessible from the menu, and others to not, you can bind them individually using the 'Category Menu Commands' parameter, so you could bind cooking to the menu, and allow access to blacksmithing or alchemy only through an event on the map scene.

To call crafting from an event, use the plugin command, and set the category to the one you want to call. If you want it to call the category select menu instead, leave that parameter blank in the plugin command.

Let me know if you have any other issues.

~Ramza

I might be able to get the scroll wheel to work for that, but I don't think I can get the MZ mouse quantities thing to work there.

I'll see what I can do.

Sorry, I haven't been ignoring this question, I've just been very busy lately.

There isn't currently a way to select the result item from the preview window. The window itself is non-interactable, so there's no chance for the player to cursor over it.

There are three ways I could try to tackle this request, and I'm not sure which, if any, is better.

The first way would be to have the help window switch between the description of the ingredient (or the craft button) you currently have selected, and the result item's help text, if it exists, after a set amount of time.

The second way would be to have a hotkey that the player could push to switch the help windows text to the description of the result item, and back, probably shift or control.

The third way would be to have an extra 'item' in the bottom of the ingredient window, on the left side, next to the craft button, that when selected, shows the help description of the result item.

There are obvious flaws in all of the above though. The first case is probably the least messy, but there isn't a good way to indicate what item the help text is for, if the window is just automatically swapping around every five seconds or whatever.

The second case might work fine, but there's no real way to inform the player that they could do that (outside of that button help window that visustella has in MZ), so they could go the entire game without knowing about it at all, or by accidentally pressing it and never seeing the help description of an ingredient again!

The third case causes a visual disruption to the ingredient list window. The craft button is smaller than the items in the list, so there's room for it on the left side, but I'm not sure what you could name it where it wouldn't stand out as something obviously put there as an afterthought.

There are many uses of the function (some) used in this plugin, so without more information it'll be impossible for me to fully track down the cause.

Cuase the error again and open the console (f12), click the console tab, and then paste the error message it shows in there. It should give a line number, which is a good place to start.

There's a good chance this problem is happening because you're loading the plugin into a project and then loading a savefile in that project that was created before this plugin was imported. Parts of the plugin rely on some values being stored on the actors, values which are saved to them on database load, but if your savegames database was created before this plugin was installed, those values don't exist, and attempting to read them causes a crash.

~Ramza

Alright, so the issue is actually that there is no provision in the plugin for animated enemies to request a motion at all, so they never do. I believe this was a compatibility concern, as attempting to call a motion on an ordinary battler would cause a crash. I'll have to look into how to enable this for animated enemies, that might take me a bit, but I'm on it.

If you haven't modified it, the Thorns VSBattleCore effect doesn't have a special battler motion associated with it, so it should use the guard motion. I tested myself in my test project (and found a bug associated with states, btw) and it does show the guard motion with the default battlers.

The picture of your golem battler is larger than a normal one, is it a dragonbones battler or something similar? The process for requesting a motion for one of those might use a different function than I use for a default battler. You might also need to add more wait time for the motion to have time to trigger? Does it work with any normal battlers for you?

It doesn't have anything special built in for doing that, but battler.weapons()[1] should give you the offhand weapon, if there is one. If there isn't one, though it would probably cause a crash. battler.equips()[1] would also give the item in the offhand slot, or the weapon, so you could use that and then do a second check for the items etypeId to see if it's a weapon or not.

The sample project has a couple of examples of this working. The default block effect causes the guard motion when the shield animation pops up.

The Parry one uses the attack motion, and specifically calls for it using the motionRequested variable in the codebox.

//makes a melee swing 
motionRequested = "attack" 
value = Ramza.SB.make_damage_value.call(this, target, critical) 
value = this.applyBlockDamageModifier(target, value)

Make sure that the motion request is in quotes as above, so the system knows it's a string.

~Ramza

All recipes have a failure item, and a soft failure will give the failure item out. It's one of the parameters on the recipe when you make them in the plugin.

There's also an option to hand out the failure item as if it were the successful craft .

(Congrats! You made <Burnt Toast>)

Edit:

The failure item stuff is at the end of the ingredients object, where you'd put in the four ingredients.

Good day.

I haven't done much work with the VS menu plugin other than find the settings that allow you to bind the command using their plugin. I was unaware that they had any menu styles that had subcommands, and I'm not really sure how this would be adding itself to their subcommand windows unless they were doing something freaky with the main command window to split it into subcommands. In that case, there might be a way to remove this from the subcommands, but it'd have to be from inside their parameters, most likely.

Interestingly enough, when looking into this, I realize that the way the menu bind for the VS (and YEP) menu is set up, is not ideal, since if you have the 'bind to menu' plugin parameter on, it will add itself the the menu command list. And that plugin parameter is exactly what my help documentation tells the user to use for 'showing' the command on the menu you binded it to, meaning it'll be bound via their plugin, but also try to bind itself at the same time, probably resulting in this weirdness.

Okay, I have this one fixed in a slightly more elegant way. 

As it turns out, the check I was using to see if the help window was on the top or bottom of the screen was checking if the Y value of the help window was > 50, which it turns out, with the button frame from VS turned on, is actually at 52, which caused the result item and recipe list window to draw expecting the help window was at the bottom of the screen.

The update is live now, feel free to download it, if you like. I appreciate your input and patience on this, I am one guy, after all, and the giant scope of this plugin, combined with testing it for several unique use cases makes squashing all of the bugs a little difficult.

They probably could, but I'd like to think that all of that code is almost entirely useless without the help documentation and the plugin parameters from the paid ones. And frankly, if someone could successfully build a system from only the core plugin that worked, that guy probably could've made his own system from scratch, and it probably would've been better than mine anyway.

Yeah, Scene_Crafting in the core plugin is more or less copy-pasted from the MV version of the plugin. Originally there were separate versions of the plugin for MV and MZ, and I merged them together to create the abomination we have now, a Core plugin, which mostly provides the framework for the MV and MZ plugins, and the MV and MZ plugins, which provide the plugin commands, plugin parameters, and window drawings for the scenes, since that was the major difference between the two engines.

That's also likely why your description text is in a weird place in the recipe list scene. MZ had a bunch of different ways that the scene could've been drawn (help window on top, help window on bottom, touch buttons on top, button input window on top, etc) depending on which Visustella Settings you had enabled, or whether or not you were using those plugins. I probably missed a specific set of those choices when I was ensuring the plugin worked with MZ, and prior to the CS_Core split, that plugin didn't work at all in MZ.

Okay, I found the cause of this in MZ.

For some reason, the functions for the level up common event, the immediate code box, and the function that gets the level up string text was not working. Those functions are in the Core plugin, and the MV version of the plugin has no issue calling them, but the MZ version had an issue where those functions we simply not available to the scene.

This can be corrected in your copy of the plugin by adding the following lines to the bottom:

Scene_Crafting.prototype.getLevelUpString = function(){
if (Ramza.CSParams.showLevelUpMessage){
for (i = 0; i < Ramza.CSParams.CategorySpecificLevelMessages.length; i++){
if (Ramza.CSParams.CategorySpecificLevelMessages[i].CategoryName != this._category) continue
var spec = i
}
var text = (spec != undefined) ? Ramza.CSParams.CategorySpecificLevelMessages[spec].LevelUpText : Ramza.CSParams.defaultLevelUpMessage
spec = undefined
var output = text.replace('%n', this._category)
var catLevel = eval("$gameParty._craftLevels." + this._category)
var output = output.replace('%l', catLevel)
var output = output.charAt(0).toUpperCase() + output.slice(1)
return output
}
};
Scene_Crafting.prototype.getLevelUpCommonEvent = function(){
for (i = 0; i < Ramza.CSParams.CommonEvents.length; i++){
if (Ramza.CSParams.CommonEvents[i].CategoryName.toLowerCase() != this._category) continue
return Ramza.CSParams.CommonEvents[i].CommonEventId
}
};
Scene_Crafting.prototype.getLevelUpEvalCode = function(){
for (i = 0; i < Ramza.CSParams.CommonEvents.length; i++){
if (Ramza.CSParams.CommonEvents[i].CategoryName.toLowerCase() != this._category) continue
return Ramza.CSParams.CommonEvents[i].ImmediateCode
}
};

Probably by the time you read this, I'll have also uploaded the fixed version to the main page again.

I found the issue and have it corrected in the latest version. Please give that a download and make sure everything is working as it should be.

Sorry to hear that and I wish you luck.

If you wouldn't mind posting the error so I can have a look at it to fix it?

~Ramza

Alright, I can work with that. The function that removes the items from the inventory after a successful craft works from a list of the ingredients, and the list is only populated with the ingredients that were actually consumed, so if the list was empty, instead of just moving on, it tries to read an object that doesn't exist and fails instead.

I should be able to get that sorted out fairly soon.

Hello.

I've tried to reproduce this and I can't seem to cause it to cause this error on my test project. In all cases, I tested recipes which only used 'items' as ingredients, no weapons, or armors. I tried where the first ingredient in the recipe was unconsumable, and also where the second was unconsumable. I also tried with the independent items patch and ItemCore turned on and off. In all cases, the expected items remain in the inventory, and the other items are taken as normal, with no errors thrown or crashes.

Any more insight you can provide to help me track this down more?

That actually is pretty funny, all things considered. 

I'm sure if their plugin did support it, it'd be a little bit easier to implement than using them in mine, but it's good to know the framework I made for that works so well that it works with their custom currencies without me even trying to do that :)

Interesting.

I'll look into the error in a bit and get back to you. In the mean time, what happens if you enable the plugin function to have soft failures? Does it still error if you use the same recipe? That line specifically is for when soft failure is disabled, while a similar thing happens when it's enabled, it's possible the error is only happening on that one function.

~Ramza