- Oct 27, 2015
- Reaction score
- First Language
- Primarily Uses
I did it ... but I do not understand this code where I have to put it .... I put it between the plugin ... but I did not even turn ......
That makes sense. Unfortunately, my project is going to be eventually reliant on the skill cost features that are (and I imagine will be)in the Yanfly skill core, and the display conflict is a little too much to roll with right now. That being said, this is a great plug in and if anyone isn't running the skill core the actor icon snippet works perfectly. Awesome work!Anyway, so my text width dilemma. I suppose the simple solution would write two versions: one for Yanfly's Skill Core and one for the default, and just say it's not compatible with any other skill cost displays at present? I'd prefer something more generic, but for right now it's the best solution I have. Ugh, but even that one seems a bit invasive to the Yanfly code to do right. I just wish I had a simple way of calling the width of text that's already been placed...
EDIT: So here's the thing. I now have a version that works, but it duplicates a good chunk of Yanfly's code (though also fixing what I believe to be a bug in said code), just because I don't have any better solutions. I think that's probably a bit of a gray area at best where legality is concerned, and as such I am so far not pasting it here.
I guess you could just run a check to see if both actors can pay their bills in succession, and then allow the skill to be used. This is a good point because some resources may be shared and you have to check if it's enough after multiple deductions. (or just the initial one since this is a dual tech)Honestly, if there's any problem with cost outside display, it's costs that aren't tied to one character. Like, if two people use a Potion for their part of the skill, so it normally costs two Potions... and you only have one Potion. That one might be tricky. But, at present, it's also an obscure scenario.
I said that the problem starts there because that's pretty much where things get tricky. With multiple resources, you can't use the single cost if it's a hybrid cost [MP/TP] and one of the actors lacks a type. So it means that you have to use separate costs associated with each of the characters respectively. And using dummy skills is a bit messy so if that can be avoided it'd be better overall.You mention "the problem starts" if you have a game where resources are different than MP and TP, but I use that to defend my choice to have them linked to other skills. No messy bothering to read multiple different skill types for plugins I can't know about. Just say "Game_SkillWindow.showSkillCost!" and be done with it. Here's the best part: who said the other skills had to actually appear on the menus? You can define dummy skills that appear under the "None" skill type (or just a skill type your characters don't have, if you want states to be able to block them) and have no effect whatsoever and use them as the components!
Thank you for answering...You must place my plugin after all plugins that modify cost for skills. That is, the Ammunition Plugin must go first on the plugin list. I know the Ammunition Plugin's page says "This plug-in should normally be placed under all plug-ins that you are using if possible". Ignore that; mine must go below it.
Also, any global costs (like items in your global inventory) that are used by both members of the dualtech currently risk a scenario where you'll be able to use the skill despite not actually having enough resources for both characters. This seems like the opposite of your problem. however.
If this isn't enough information for your problem, I'll have to look at it later. There could be an actual incompatibility between my plugin and the ammunition plugin; I don't know, but I can't look at it right now.