Equipment Skills (Trees?)

[Roguedeus]

Simple Explanation (In a paragraph):
Every item has a durability, assigned stats (that do not scale with level by default), and the possibility of one or more usable skills. When a skill is used from an item, that item loses durability. If the item reaches '0' durability, it turns into an alternative item and is unequipped.

Big Picture (Possibilities):
What I am going for is a system where any equipable item, can also come with a class-like tree of skills. The specific way the skill is used can be indistinguishable from using normal skills, but as fancy as we can manage.

Currently the Instanced Items script has been provided with an Item Leveling script, and a Durability script, so I am looking to combine them, with unlockable skills at specific levels.

Preferably, I would also like the system to be mostly randomizable in some way. Such as obtaining a skill +/- 1 level from its assigned default, or not even being there (chance of application, per init of new instance)...

Also, a KEY point of the mechanic would be to reduce the items durability X points when a specific skill is used. And for that to also be randomizable, if possible, but not necessary.

Hime suggested the possibility of selecting the equipment (in battle scene?) and then selecting the skill used. I think that may be a bit more complex than is necessary, but then if its doable, it would be really cool too.

For me the primary challenge is in finding a way to link the skills use, to the equipment that provided the skill, as to reduce the items durability.

The assignment of skills by default, or by level, can be hard coded, note tags, and/or possibly randomized somehow. Just as long as at least 1 skill (Hopefully more, as if a character class where assigned to the equipment) is obtainable via equipping the item.

[HimeWorks]

I'm looking at selchar's durability script and it sounds like you could do it with that, provided the script is improved.
Here is my solution: http://forums.rpgmakerweb.com/index.php?/topic/22011-weapon-durability/#entry212071

It assumes that whenever the skill is used, the weapon's durability will be reduced.
It assumes that the skill can only be used when that weapon is equipped.

The assumption may fail for characters with multiple weapons (or, in general, multiple equips), but I have not thought far enough to determine whether that is the case or not.

[Roguedeus]

Holy crap I like this syntax!

    @note =~ /<durability[-_ ]?cost:\s*(.*)\s*>/i ? @durability_cost = $1.to_i : @durability_cost = 1 if @durability_cost.nil?

=~ is so slick.

[Roguedeus]

Ok, I am just eyeballing the code to get an idea of what I might have to do here, and the gist of it seems to be that right now, each weapon used is processed for durability each time damage is calculated.

So.

Ooops, First, first, I'll have to expand the durability mechanic to apply itself to ALL equipment types.

First, I'll have to find a way to reference the equipment the skill is assigned to, and process ONLY that item for durability.

Second, I'll have to find a way to assign the skill to the actor via equipping the equipment.

Third, I'll have to condition the assigning skill to only apply if the item is >= specified level.
(Actually 3 is technically optional.)

(Expanded)

• It would be nice to figure out if I can assign a 'Class' to an item, and then reference the classes skill listing to then condition skills.
• It would be nice to randomize the level requirements, if noted.
• It would be nice to also randomize the durability cost, if noted.

[HimeWorks]

(1) is necessary under the following cases

• you have multiple equips that provide the same skill. For example, your weapon and your ring provides Skill A, and when you use Skill A, you need to determine how that will affect durability.
• you are equipping multiple instances of an item. For example, you equip two hand axes. They provide the same skill, so should both of them lose durability?

For (2), consider using the "add skill" feature, except do a little extra processing to associate any of those added skills with the equip.

For (3), I would say Feature Conditions http://himeworks.wordpress.com/2013/07/16/feature-conditions/, but then I haven't figured out how to apply it to individual features.

Randomization can be done by using a formula to specify durability.

Assigning a class to an item, you would pretty much just load an RPG::Class object. The specific object to load could be hard-coded, or just ask users to note-tag the class ID.

[Roguedeus]

Question: If I alias an existing method with a new method name (but no overwrite of the old method), every time the new method name is called, the old method is called instead, correct?

And all references to the old method still work correctly? Yes?

Example:

class RPG::Skill
  alias weapon_durability_cost durability_cost
end

This will simply run weapon_durability_cost any time durability_cost is used. Right?

Also, why would you symbolize this? alias :weapon_durability_cost :durability_cost I have seen many people do that.

[Roguedeus]

Another thing... Just to be sure I'm not making a mistake.

In Selchar's Item Durability Script, this method is defined as an alias, with no reference to why. I assume this must be one of his personal scripts? or does it have another purpose that I need to worry about?

#===============================================================================
# Instance Manager: setup_instance
#===============================================================================
module InstanceManager
  class << self
    alias :instance_weapon_durability_setup :setup_weapon_instance
  end

  def self.setup_weapon_instance(obj)
    if obj.use_durability
      obj.make_max_durability
      obj.update_durability_name
    end
    instance_weapon_durability_setup(obj)
  end
end

[HimeWorks]

Alias accepts strings or symbols. Symbols are supposedly faster than strings to use, so I just use symbols. Plus it's faster to type and better-looking in the editor.

No, aliasing simply provides another reference to the method. You need to explicitly call it if you want to call the other stuff.

def test
   p 'test1'
end

alias :old_test :test
def test
  p 'test2'
end

If you overwrite the definition, then calling test would simply print out "test2". However, if you copy the method as it is currently defined into another name, then you can call the old stuff. That might not be how it works internally, but that's how I imagine it.

setup_weapon_instance is defined in Instance Items script.

[Roguedeus]

It must be a newer version of it... Hold on.

Yeah, figures. I should have checked. I am still using the old 'testing' version of it you shared a while ago.

Found it:

  #-----------------------------------------------------------------------------
  # Apply any weapon-specific logic. This is meant to be aliased.
  #-----------------------------------------------------------------------------
  def self.setup_weapon_instance(obj)
  end

No wonder my search failed to find it... :p

[Roguedeus]

Should I link the use_item Battler method with a new RPG::Skill accessor to access the skill origin?

attr_accessor : skill_owner

This way the correct equip will get hit with durability changes. I figure that duplicate skills will be checked as a condition for equipping the item. If the skill the item provides is already provided by another means, the equipment can't be equipped? Or maybe a priority check, where the higher level item overwrites any duplicate skills?

I am looking at the way Fomar0153 implemented Equipment Skills, to see how I might do it on the cheap, and avoid note tags for now... But I am open to suggestions.

I know you mentioned using the Feature Manager for level based stuff. I will have to study the script to familiarize myself with it.

[HimeWorks]

How you do it really depends on how your system will work.
If you choose an equip first, then you would bind the equip to the skill, and you have no issues with duplicate equips or equips that add the same skill.

You don't need to keep track of who the skill user is because that is available when you actually execute the action.

Feature Conditions is not related to Feature Manager. Feature Conditions simply determines whether a feature should be applied or not, using a formula.

[Roguedeus]

The owner I am referring to is the equipment that owns the skill. I don't see another way to know which individual actors equipment is the target of the durability loss, when the skill is used, if every single piece of equipment has durability.

If a pair of gloves is granting an ATK buff skill, I only want the gloves to lose durability. Are you saying that's already possible? Because the way I read the code, it simply subtracts the cost from every weapon equipped.

[HimeWorks]

How would you determine which equip actually owns the skill, and which one should be losing durability?

[Roguedeus]

By assigning it to the skill when the equipment is put on. Hence the question above.

When the actor puts on the equipment, the skill will be tagged with the equipment just put on, as its skill_owner and until the skill is replaced via a higher level duplicate (applies a new owner), or its owner is unequipped (unlearning the skill), it will keep referring to that equipment every time its used.

[HimeWorks]

Then...I wouldn't put it in use_item but instead somewhere closer to change_equip

And instead of binding the equip to RPG::Skill (which means you're going to modify the database objects which are read-only), you would bind the skill to the instance equip (again, if you bind it to RPG::Equip, you're probably going to run into strange issues. Possibly).

Then, when you execute a skill, you would go through all of your equips and determine which equip has this skill, and decrease durability from that equip.

[Roguedeus]

use_item would be used to check the current owner, not assign it. :)

I always intended to use change_equip as the assignment method.
That's what Fomar0153 does with his script. But only in learning the skill.

Maybe I should have been more explicit with my initial question. My mistake.

[HimeWorks]

If "check" also includes "reduce durability" then that would make sense. Using a skill, but not landing a hit, is still using the skill...usually.

One could argue that your blade never actually hit the enemy, so it wouldn't "reduce" its durability.

[Roguedeus]

I implied that understanding. I got a little ahead of myself and asked the question without sufficient context.

[Roguedeus]

I'll post a link to the solution when its done... So far I just have to set-up the learn/unlearn Skill and new accessor for Skills owner... I am prone to mistakes so I am baby stepping through it.

[HimeWorks]

Programming is usually done incrementally step-by-step, one method at a time. This is why people leave stub methods here and there with hardcoded values so they don't need to worry about it until they actually feel like working on it and are sure everything they wrote already works correctly. Much easier to debug when you know everything behind you is correct.

[Roguedeus]

Ok, small issue...

The skill_owner accessor is owned by the database object of the skill, as the skill is not instanced like the items... So assigning the owner will apply that owner to ALL actors with that skill...

Hehehehe... /sigh

[Roguedeus]

Solution?

Maybe if I grab the @equips index of the equipped, and the skill_id, and assign it to the actor, I can check it every time a skill is used, and if the skill_id matches, it will change the durability of the @equips index item.

But what if the equip_index changes? Or if the game is loaded? Hmmm.

[Roguedeus]

Actor accessors are serialized, so that shouldn't be a problem right? My main concern would be the @Equips index changing due to dynamic equipment slots.

Or not... The instanced item is unique. All I'd need to do is save a reference to the Instance, and the skill_id right? Hmmm.

[HimeWorks]

Yes, you just need a reference to the object. If you're using change_equip then you already have a reference to the exact equip.

The idea behind my Instance Items design is that it is completely transparent to the scripters: change_equip doesn't care whether you are working with a weapon from the database, or an instance weapon. I think it's a wonderful design.

Do not do silly things like assume objects have some sort of fixed index. That's what the default project assumes, and we can see that it was not a good idea. eg: it assumes your first equip slot holds a weapon.

[Roguedeus]

I know its getting late and you wont be available to bounce off, so I am trying to get as much done as possible...

[Roguedeus]

bool
array.each do |x|
   x == y ? bool = true : next
   break
end

if bool #Do Something...

This will only break the initial loop, if bool == true?

[Selchar]

Hello, just made an account to let you know that my Weapon Durability script has been updated. Hopefully the changes made will make some things easier for you, and do let me know if there are any problems.

[Roguedeus]

Current version 1.02?

[Selchar]

Forgot to change the version number, should be 1.03, it has still been updated tho if you see the notetag skill durability mod x: y in the instructions.

[Roguedeus]

Got it. Thanks. :)

[HimeWorks]

No, it breaks when x == y
It is a consequence that bool will be set to true, but that's not why the loop breaks.

[Roguedeus]

edit: Ignore this nonsense... it was a stupid mistake on my part dealing with class levels.

I may have found a bug...
It seems to be because the skills that have MP required are being forgotten and re-learned... If the actor doesn't have any other MP using skills, the actors MP is seen as moot by the default scripts, and its wiped out in that split second between unlearning and learning.

Now to figure out how to prevent it.

[HimeWorks]

the actors MP is seen as moot by the default scripts, and its wiped out in that split second between unlearning and learning.

What?

[Roguedeus]

edit: Ignore this nonsense... it was a stupid mistake on my part dealing with class levels.

I may have found a bug...
Ok... I was wrong. :p

I forgot to re-apply the learn skill note tag, after making an MP using skill permanent. It appeared that having n MP using skill was somehow preventing the MP from being erased.

Now I see it happens anyway.

So, it must be something my equipment skills script is doing. As removing the learn skill note tag is stopping it from happening.

[Roguedeus]

Perhaps I should stop voicing my initial guesses so often, as they are a bit silly sometimes. :p
Its a bad habit. When I troubleshoot something I've never seen, I tend to let my mind throw possible causes and effects around randomly, and eliminate them one by one. I think its my way of trying to consider as many possibilities as I can.

Sometimes it helps, while others it just makes me look stupid. I should keep it to myself until I have something at least halfway baked. ;)

[Roguedeus]

Whoops... Big bug.

It's possible to forget a class skill if its the same skill as the equipment grants. I need to remember to re-learn class skills after unequipping something.

FIXED.

  #----------------------------------------------------------------------------
  # 
  #----------------------------------------------------------------------------
  alias :change_equip_rd_es :change_equip
  def change_equip(slot_id, equip)
    forget_equip_skills(equips[slot_id])
    change_equip_rd_es(slot_id, equip)
    self.init_skills
    update_equip_skills
  end

[HimeWorks]

If you're using yanfly's battle engine that happens.

[Roguedeus]

Yeah. The reason it was happening was cosmetic and actual, depending on which piece of equipment I put on. It was because I forgot I was testing adding/removing levels with equipment, and for testing purposes I gave a class some MP only at level one.... So when I changed one equip I was gaining and losing the only MP skill the character had. But when I changed the other equip I was gaining a level, and losing the MP all together.

It was a cluster of mistakes. :p

[Roguedeus]

Another strange bug...

Swapping equipment in battle can cause some odd skill availability. Seems to be related to Yanfly's Battle Engine as well... The scene may not be updating the skill list effectively.

Note:
I've gone ahead and made the TP and MP display all the time by default, with YEA Battle Engine and the Equipment Skills script. Seeing as swapping equipment to change skills, during battle, is sorta expected and it confuses the shit out of Yanfly's Battle Scene, when actors go from having MP and TP skills to not, and back again, all within the same round of battle.

So far it hasn't been as easy figuring out a clean and effective way to make the skill list update... Still looking.

[Roguedeus]

Apparently its not the skill list window. Nor is it the battle scene... The skills are literally being removed from the actors skills list.

[HimeWorks]

That's not supposed to happen? That's what it means to forget a skill.

[Roguedeus]

It happens when they are supposed to be getting learned.

When equipment is put on, skills are learned. When equipment is taken off, skills are forgotten. But right now, when you equip one, skills are learned. And when you equip the second, suddenly skills are ALL gone.

I can't think of anything I've done to the script to suddenly cause this. It wasn't happening before. Or maybe it was another one of my forgetting to undo something I did to test, and assumed it was working because I saw the result I wanted, but in reality it was because of the temporary test change I made, and now that its back to normal, the results aren't what I wanted...

Strange that Selchar didn't notice the problem. Maybe he just hasn't tried equipping more than one skill granting equipment.

[Roguedeus]

Yeah... I figured.

Its this.

  #----------------------------------------------------------------------------
  # 
  #----------------------------------------------------------------------------
  alias :change_equip_rd_es :change_equip
  def change_equip(slot_id, equip)
    forget_equip_skills(equips[slot_id])
    change_equip_rd_es(slot_id, equip)
    self.init_skills <---- RIGHT HERE!!!
  end

go figure.

[Roguedeus]

This is the functional correction.

  alias :change_equip_rd_es :change_equip
  def change_equip(slot_id, equip)
    forget_equip_skills(equips[slot_id]) #<--- Forget the skills given by the lost equip.
    change_equip_rd_es(slot_id, equip)

    self.init_skills    #<--- This makes sure class skills aren't lost from forgetting.
    update_equip_skills #<--- This makes sure all current equip skills are retained after class init.
  end

[HimeWorks]

I wouldn't call init_skills anywhere after the actor has been initialized. I consider that improper because an initialization call should be called...during initialization!

Rather, I would prevent the actor from forgetting class skills in the first place.

[Roguedeus]

Is that because it re-creates the actors @skills array?

Also, multi-classing and sub-classing can make that kind of difficult. It may simply be easier to call it, as a one stop shop to insure class skills don't get lost.

Then again, looking at the code, it wont matter. Better to listen to you. :)

Ok, I'll look into fixing the oversights tomorrow.

[HimeWorks]

Pretty much.

[Roguedeus]

This look adequate to you?

  #----------------------------------------------------------------------------
  # new:
  #----------------------------------------------------------------------------
  def forget_nonclass_skill(skill)
    if !is_class_skill?(skill)
      forget_skill(skill.id) 
      puts("Forget > Skill(#{skill.id})")
    end
  end

  #----------------------------------------------------------------------------
  # new:
  #----------------------------------------------------------------------------
  def is_class_skill?(skill)
    self.class.learnings.each do |learning|
      #only remember class skills that are already learned.
      return true if (learning.level <= @level) && (learning == skill)
    end 
    return false
  end

[Roguedeus]

Success!!

This is with ONE equip granted skill.

This is with duplicate equip granted skills. (Sharing the load)
Note: It reset to 20, as the new equipment has higher durability than the prev. one. Thus if equips remain the same the old equip will break before the new equip, so the new equips durability is used to calc. uses remaining.

[Roguedeus]

Is there an ascii value to character method for RMVXA? I am trying to find the infinity character... It wont recognize the ascii code using 236.chr

[HimeWorks]

You need a font that supports it.

You can't compare learning with skill because they are two different objects.

[Roguedeus]

Damnit... :p It would be that simple, yet not that simple.
Guess I'll settle for 'x' for now.

[Roguedeus]

Thanks for pointing that out!

I'll see if this works.

  #----------------------------------------------------------------------------
  # new:
  #----------------------------------------------------------------------------
  def is_class_skill?(skill)
    self.class.learnings.each do |learning|
      #only remember class skills that are already learned.
      return true if (learning.level <= @level) && (learning.skill_id == skill.id)
    end 
    return false
  end

[Roguedeus]

It seems I have forgotten one significant part of my mechanic puzzle...

In the next week or two, I am going to have to iron out how to randomize different aspects of instance items. Such as current/maximum durability, possible/successful skills, +/- durability costs, parameter bonus ranges, and maybe even feature assignments...

I do not expect this will be a simple matter. :)

[HimeWorks]

I thought about randomization but could not figure out a good way for users to provide input.
For the param ranges, I was thinking of something like

<random atk: 10 30>

Which would indicate that the atk value for any instances will be anywhere between 10 and 30
However, this does not provide any control over the probability, so there are equal chances that you will get any of them.

[Roguedeus]

Yeah. My immediate impulse was to have simple defaults that can be altered, temp or perma, via script call.

Your above example could be an array [equip_type, item_id,10,10,10,15,15,20,20,25,25,30] repetition being the odds and omission of values removes their possibility. Or perhaps I could use float values as a multiple. 10.4 would become [10,10,10,10] so the above array would end up being [10.3,15.2,20.2,25.2,30] though it may be easier to just use arrays in arrays... [ [10,3],[15,2],[20,2],[25,2],[30] ]

Or whatever. I am not good at math or I'd try to figure out a formula that used an exponent to factor increasing odds the higher the value. But then there might be times where I want a bell curve rather than a hockey stick.

I waste to much time thinking about this stuff.

[HimeWorks]

Explicitly specifying the "possible" stats is a good way to do it. Might be impractical when you want +100 to occur 1% of the time, and +20 the rest of the time though.

Another problem that would arise is the size of the input.
For example, I might explicitly use probabilities like this

<random atk>
  10: 50%
  15: 20%
  16: 20%
  20: 10%
</random atk>

Now...we can end up with potentially 1000 line note-tags.

It is important to think about how you're going to use it, before you spend any time implementing it.

[Roguedeus]

I would think those that want to be super specific can simply hard code those extreme settings in a script module.

I cant speak for others, but I know that I wouldn't want any potentially game breaking randomness to even be possible. So any possibility that I want limited to anything rarer than 5% should be highly controlled and not 'expected' to be handled by note tags. Instead, I would simply control the availability of that specific possibility via in game mechanics, and enemy loot scripts.

Or advanced script calls that allow for boutique instance items.

[Roguedeus]

I am finding myself second guessing much of what I was doing with these durability and equip-skill mechanics...

The basic flow of the game just doesn't lend itself to a wide spread durability mechanic without some significant paradigm shifts. I am not sure if all the shifts combined into a single initial project will be a smart thing... It might put off people that love the default mechanics of these sorts of RPG's while confusing those new to them.

Its really not a lot of wasted work, and I'll always have the scripts in case I end up using them...

[Roguedeus]

I added the ability of the Equip Specific Skill Durability script to detect skills added via database features now. I am wondering why I didn't just build it around that in the first place... There really is little need for a note-tag that accomplishes it.

/facepalm