Base a weapon's Critical Hit Chance Stat off of a variable?

[FirestormNeos]

So I have a weapon that includes a handful of skills that increase a variable; as this variable increases, I want the weapon's critical hit chance to be determined by this variable. How do I do this?

 

[gstv87]

class Game_Battler < Game_BattlerBase
def item_cri(user, item)
    if item.physical?
      return <calculation>
    end
    if item.magical?
      return <calculation>
  end
end

you can use that snippet, replacing <calculation> for whatever check you need.
to access your variable, call for $game_variables[varId].

say, you want to check for X% based on variable:

return $game_variables[000] / 100.0

if variable X is 20, it'll return 0.2, which then goes to the randomizer call to that block, from the item check, from the battle scene.
that block only has to return the threshold value.
if you want to modify the way that threshold is handled, then it's a larger modification, but it can still be done.

 

[Heirukichi]

@gstv87 That solution affects every single skill regardless of the weapon being equipped or not. On top of it, for compatibility purposes, it is better to alias the method rather than overwriting it.

#----------------------------------------------------------------------------
# ** Game_Battler class
#----------------------------------------------------------------------------
class Game_Battler < Game_BattlerBase
  #--------------------------------------------------------------------------
  # * Custom Critical Chance Formula
  #--------------------------------------------------------------------------
  def custom_item_crit(user, item)
    your_formula_goes_here
  end # Custom Critical Chance Formula
  #--------------------------------------------------------------------------
  # * Aliased method: Item Critical Chance
  #--------------------------------------------------------------------------
  alias hrk_item_cri_old item_cri
  def item_cri(user, item)
    if user.actor?
      return custom_item_crit(user, item) if user.equips.include?($data_weapons[WEAPON_ID])
    end
    hrk_item_cri_old(user, item)
  end # Item Critical Chance
end # end of Game_Battler class

This only applies the formula if the user is an actor and if the user is wielding the said weapon. Of course, "WEAPON_ID" and "your_formula_goes_here" have to be changed to be respectively the real weapon id and the real formula you want to use to calculate critical chance.

EDIT

Spoiler: How the code looks like in the Game_Actor class (not recommended)

#----------------------------------------------------------------------------
# ** Game_Actor class
#----------------------------------------------------------------------------
class Game_Actor < Game_Battler
  #--------------------------------------------------------------------------
  # * Custom Critical Hit Chance
  #--------------------------------------------------------------------------
  def custom_item_cri(user, item)
    your_crit_formula_goes_here # Change this with a real formula
  end # Custom Critical Hit Chance
  #--------------------------------------------------------------------------
  # * Aliased method: Item Critical Chance
  #--------------------------------------------------------------------------
  alias hrk_item_cri_old item_cri
  def item_cri(user, item)
    weapon = $data_weapons[WEAPON_ID]
    user.equips.include?(weapon) ? custom_item_cri(user, item) : hrk_item_cri_old(user, item)
  end # Item Critical Chance
end #end of Game_Actor class

Regardless of the option you pick, doing it this way allows you to use something like this in your formula:

$game_variables[N] * X + hrk_item_cri_old(user, item)
# OR
$game_variables[N] * X * hrk_item_cri_old(user, item)
# Or any combination that also includes the old method in it

 

[gstv87]

aliasing the method would run the original and then the aliased, which wouldn't be what they need if they have a custom critical calculation.

better to rewrite it as a child of actor rather than battler, and call the weapon checks from there.

class Game_Actor < Game_Battler
def item_cri(user, item)
   ...
end
end

that way it'll take over automatically when the origin of the use is an actor

 

[Heirukichi]

@gstv87 that's why there is a return in the if statement. However, since it checks if the user is an actor, overwriting it in the actor class also works, although an alias is still recommended.

I want the weapon's critical hit chance to be determined by this variable.

The OP wants a different formula ONLY when the said weapon is equipped. That's why you must run the normal critical hit chance method when that is not the case. The alias is recommended regardless of the class you write the method in, simply because you might need the old one in the custom formula. Of course, if you write it in the child class (Game_Actor) you can use the super keyword instead of aliasing the method, but I do not recommend it, for a bunch of reasons.

Just in case, I added a spoiler with the code to write the method in the Game_Actor class to my previous post. This way the OP can pick the most suitable option. Even so, @FirestormNeos I recommend you to read this explanation before deciding which option is the most suitable for your game, although you might want to skip technical details. Just try to understand the difference between the two solutions.

Spoiler: Comparison between alias and super

Alias
I do not know how many are familiar with the ruby C API, but the alias keyword simply associates a new symbol to the old method. A symbol is a pointer to a constant string, associating a new symbol to a pointer simply means creating a new string and using the new pointer instead of the old one. The complexity of copying a pointer is O(1), and there is no need to perform this operation every time the method is called, because the method is simply going to be called with the new symbol. On top of it, an aliased method can be called anywhere, making the old method accessible from other methods as well using the new symbol.

Spoiler: How the alias keyword is defined

/*
 * rb_define_alias prototype. The function then calls rb_alias, nothing else.
 */
void rb_define_alias(VALUE klass, const char *name1, const char *name2)

As you can see, it simply receives two pointers to constant strings (VALUE is the variable type for every object in ruby, which is used to determine the instance the alias is applied to).

The function then calls rb_alias passing the same arguments it received. The said function simply finds the original method associated with that symbol (string pointer) and erases the association to that method. After erasing that, it associates a new method to that symbol. All that is done using a symbol table, so its complexity is still O(1).

@gstv87 If you want to learn more (although it requires a certain degree of C knowledge) you can download the ruby source code, it is open source, so everybody can access that.

Super
The super keyword acts in a completely different way: it checks recursively if the parent class has a method associated to the symbol used (method names are symbols, aka constant strings) and returns that symbol. This means that it has to check the parent class every time it is called, which means that every time the method where the keyword is used is called, it has to perform that recursive scan, meaning that its complexity in the worst case scenario is O(N), with N being the number of parent classes. While an aliased method can be called anywhere, the super keyword can only call the method withing a method with the same name, making calling the old method from other methods impossible.

In this case it is not going to change much from a complexity standpoint, as the method is directly defined in the parent class. However, the fact that you cannot call the parent class method directly when you use the super keyword still remains.

The differences in versatility and complexity, however, are just two of the reasons why I deem the alias keyword superior in this case. The other reason - probably more obvious than the previous ones - is to improve code readability. If a method is defined in the parent class and then overwritten through inheritance, you have to manage two different versions of the same method (one in the parent class, and one in the child class). Should any compatibility issue arise with another script, having a method aliased in many different child classes might spell trouble.

This might not prove to be a good enough reason to change how the original method works in the parent class (Game_Battler), but combined with the fact that doing it in the child class brings absolutely no advantage in terms of complexity, it should definitely shift the preference toward the alias solution.

That said, even if writing it like this allows you to skip the user.actor? check, that one has a complexity of O(1), and removing it is really pointless, especially if doing that means that you are splitting the item_cri method among different child classes. The "actor?" method is part of the child class no matter what, using it is perfectly fine. In this situation, having two copies of the same method can be avoided, making the code easier to read and maintain. It is a bad practice, especially considering that it can only have a negative impact on performance (I already explained how using the super keyword every time is worse than aliasing it only once).

- - - - - - - - - - - - -​

Conclusions
After taking into account the difference between the two keywords (alias and super), and what writing this method in the child class implies, I can affirm that, of course, writing the said method in the child class (Game_Actor) is a possible solution and will work, but I would rather write it in the parent class (as in my previous post) because it is more efficient.

 

[gstv87]

That's why you must run the normal critical hit chance method when that is not the case.

there's four cases to pick from here:
-not actor, without weapon. (regular enemy)
-not actor, with weapon (physically impossible, as enemies can't fit weapons)
-actor, without weapon.
-actor, with weapon.

the only instance where the validation is correct, is in actor with weapon.... and since that falls within the "actor only" side of the comparison, then you hook it to the actor class and not the battler class.
doing so would straight up bypass the check for enemies, which will still run the default check.

this is inheritance we're talking about, not overwriting.
redefining a new function for the actor class causes *it* to run instead of the parent's function, which runs when there's no specific function for the child class.... of which Battler has two: Actor, and Enemy.

that method of simplifying choices is not even programming, is basic logic.

 

[Heirukichi]

1. there's four cases to pick from here:
   -not actor, without weapon. (regular enemy)
   -not actor, with weapon (physically impossible, as enemies can't fit weapons)
   -actor, without weapon.
   -actor, with weapon.

   First of all, these are not 4, are 3. Since one is physically impossible, there is no need to consider it. Checking if the user is an actor before checking if the weapon is equipped simply reduces this to 3 possibilities: the user is not an actor, the user has the weapon, the user does not have the weapon.
   
   

2. this is inheritance we're talking about, not overwriting.

   Second, if you inherit a method, you use it as it is in the parent class. If you write a new one with the same name in the child class, you are overwriting it, it doesn't matter how you phrase it. Redefining a method in the child class is a form of overwriting, the only difference is that you have a special keyword that allows you to run the method for the parent class within the method itself, but the method in the child class already runs instead of that in the parent class, and thus you are defining a symbol for that method in the child class that has higher priority over the one from the parent class.
   
   

3. redefining a new function for the actor class causes *it* to run instead of the parent's function

   I am fully aware of this, however, it looks like the same does not apply to you. In your own example, you mentioned a situation where you have to rely on the old method (3rd option of your list). If you redefine the parent method in the child class, you have to call the parent method using the super keyword.
   
   
4. Given what I said in the previous point, I already explained the difference between the two keywords (alias and super), providing unquestionable proof of why aliasing the method can only bring benefits, and I think that indulging on that too much would only bring this discussion off-topic. If you are interested, read what I wrote and try to understand it.
   
   

5. that method of simplifying choices is not even programming, is basic logic.

   I already explained why you are not simplifying a single thing by doing that. Once again, I do not particularly fancy writing things I already mentioned, but for this I can make an exception, since it is quite short: adding this line
   

   user.actor?

   instead of having to split the same method between two classes is NOT complicating things, it is simplifying them, because it makes maintaining the code much easier. The long and detailed explanation is in my previous post.

Based on your assumptions right now it looks obvious that you did not put much care when reading it, the answer to almost every argument you brought up was already contained in my previous message.

Spoiler: Avoid digressions

Nobody forced me to write a detailed explanation of the internal structure of ruby and nobody is going to pay me for that. I did that to give you, the OP and everybody else reading this topic a better understanding on how things work in ruby. I even took my time to include a solution similar to the one you provided to my previous post because I consider it a viable alternative (I didn't recommend it, but that does not mean I do not consider it a possibility), to show the OP that there is not just a single solution.

If you want to learn more about ruby internal structure, usage of alias and super in this kind of situations, you are welcome to read my previous post carefully and ask me any question about it, I will be glad to answer all of them (possibly in private so that we avoid diverging too much from the original topic). If you want to discuss about the best way to do this, by providing solid proof supporting what you are saying, I will be delighted to read your arguments and take that chance to learn (and extend that chance to future readers).

Belittling what other people write before completely understanding what the contents of their message, on the other hand, is not how an open-minded discussion between adults should be, even less if we consider that this forum also has a fair amount of juvenile users, since we could set a very bad example for them.

That being the case, I think that everything we had to say about how to approach this problem has already been said. Discussing it any further would not be very useful. The OP already has all the required information to handle this problem. Feel free to mention me (or quote my post) if you have anything important regarding this matter, but I am not going to argue again on which of the two solutions is the best, because everything has already been said.

 

[gstv87]

Since one is physically impossible, there is no need to consider it.

but you must, because even if it's physically impossible for it to be picked, it relies on one of the set variables for being included: it exists as not-actor (!actor), and "actor" belongs to the scope of the problem.

this is the logic basis I mention: https://en.wikipedia.org/wiki/Karnaugh_map
you consider every value that can be potentially considered, then group by adjacency, and then remove those values that don't affect the outcome.

here, you already know one of the values is not going to affect the outcome.... but you must include it because one of it's root characteristics is binary, and one of the binary results is considered in the problem.

If you redefine the parent method in the child class, you have to call the parent method using the super keyword.

not unless you want to run a different process and return a different result, which seems to be the case.
item_cri() only returns a margin of operation for the random calculation.
*for the calculation that calls it* it is of no consequence whatever operation returns that value, as long as it is what the calculation expects.

in fact, it's done already in Ace's stock code:

class Scene_Base
 def transition_speed
  return 10
 end
end

class Scene_Title < Scene_Base
 def transition_speed
  return 20
 end
end

no super, just plain simple override.

I already mentioned, but for this I can make an exception, since it is quite short: adding this line

user.actor?

Game_Actor inherently implies user.actor? => true.
Game_Actor automatically takes priority over Game_Battler at the time of executing item_cri(), even when item_cri() is declared in Game_Battler.
the only instance where you'd check for user.actor? is if you had to apply a similar operation for both actors and enemies but writing two separate functions would be overkill.
so, instead, you take both functions, simplify it in one check, and hook that check to the parent object of Actor and Enemy.
but here, Enemy is out of the scope of the solution (than not the *problem*), so when writing the solution you write it for Actor.

 

[Heirukichi]

this is the logic basis I mention: https://en.wikipedia.org/wiki/Karnaugh_map

Now, THIS is an interesting point, worth explaining. The Karnaugh map is used to simplify boolean expressions. I am going to answer you with a simple question: if you already know that a variable is not part of the problem, does including it in the expression simplify it? As every other simplification, you do not resort to it if it does not simplify things.

Spoiler: A little example

We all know that (we do, do we not?)

sin(x) ^ 2 + cos(x) ^ 2 = 1

To simplify any formula you can always shorten (sin(x))^2 + (cos(x))^2 using 1 instead. However, is it worth doing it to simplify the following formula?

(cos(x) ^ 2 + sin(x) ^ 2) / sin(x) ^ 2 - 1 / tg(x) = 1

If you simplify it, you reduce the number of characters, but what could be easily solved, becomes this:

(1 - cos(x) ^ 2) / (sin(x) ^ 2) = 1
# which then becomes
1 - cos(x) ^ 2 = sin(x) ^ 2
# and then
1 - cos(x) ^ 2 - sin(x) ^ 2 = 0
# which is always true

On the other hand, not simplifying it, turns out to be like this:

(cos(x) ^ 2 + sin(x) ^ 2 - cos(x) ^ 2) / sin(x) ^ 2 = 1
# which is obviously the same as
(sin(x) ^ 2) / (sin(x) ^ 2) = 1
# which is obviously always true

Was the simplification worth the effort? It was not, it only increased the number of steps required to reach the solution.

The example in the spoiler is the very same thing that applies here. If you already know that, regardless of the other variables involved, a statement if false when a certain variable is false, is it worth including that variable when you try to simplify it? The answer is obvious, if it requires more steps, it is not worth. Well, you still obtain the same result in the end, but if you achieve the same result with more steps, you are not simplifying things, are you not?

If a function is not defined on a certain interval, considering values that are part of that interval is just a waste of time, not a way to simplify the solution.

no super, just plain simple override.

I agree, but, unfortunately, this does not apply here (reason below).

not unless you want to run a different process and return a different result, which seems to be the case.

I think you are completely missing the point. If the actor does not wield the said weapon, a different result is not what you seek. The OP is not asking for a different result for every single actor, the request is for a different result when the said weapon is wielded. An if/else statement to check if that weapon is equipped is absolutely mandatory. And what happens when the result of the statement "if weapon X is wielded" is false? Simple: you return the usual value. This means that you have to use that old value in that situation, regardless of where you place the method itself. That being the case, the super keyword is mandatory if you write the method in the child class.

Spoiler: Example

class Game_Actor < Game_Battler
  def item_cri(user, item)
    user.equips.include?($data_weapons[weapon_ID]) ? new_formula : super(user, item)
  end
end

The main point here is that while I already simplified things by removing an unnecessary variable, you are still not considering one of the important ones. The very same fact that you are not considering that an actor might not wield the said weapon is what is causing all this, which may be partially due to the fact that you did not take time to write the whole method in your post, otherwise you would have probably noticed your mistake. The reason why I think that way is that this part is missing in each post you made above this.

Now, assuming that the super keyword is mandatory (I think we can agree on this), the reason why using the parent class is better than using the child class is in my post above. The same applies to why using user.actor? is not a way to complicate things and does not affect efficiency.

That said, whether the misunderstanding was caused by the fact that you did not read my post carefully or by the fact that you did not read the OP post carefully, you should really start reading things more carefully as not to cause other misunderstandings. Unfortunately, in computer science a small misunderstanding might mean writing code that is completely wrong.

As a matter of fact, this was the very first thing I pointed out in your reply:

@gstv87 That solution affects every single skill regardless of the weapon being equipped or not.

 

[FirestormNeos]

So where would I place these two codes that you two suggested into my game? Can I just copy-paste one of them into a Materials tab, or does the one I pick need to go into a specific spot?

 

[Heirukichi]

You can copy/paste it in your Materials tab, but it is important that you change the parts that have to be changed (like the weapon ID and the final formula).

 

[FirestormNeos]

You can copy/paste it in your Materials tab, but it is important that you change the parts that have to be changed (like the weapon ID and the final formula).

So if I wrote this...

#----------------------------------------------------------------------------
# ** Game_Battler class
#----------------------------------------------------------------------------
class Game_Battler < Game_BattlerBase
  #--------------------------------------------------------------------------
  # * Custom Critical Chance Formula
  #--------------------------------------------------------------------------
  def custom_item_crit(user, item)
    $game_variables[0081]
  end # Custom Critical Chance Formula
  #--------------------------------------------------------------------------
  # * Aliased method: Item Critical Chance
  #--------------------------------------------------------------------------
  alias hrk_item_cri_old item_cri
  def item_cri(user, item)
    if user.actor?
      return custom_item_crit(user, item) if user.equips.include?($data_weapons[43..44])
    end
    hrk_item_cri_old(user, item)
  end # Item Critical Chance
end # end of Game_Battler class

In an otherwise blank materials page labeled "Fencer_Crit_Chance", I wouldn't have to mess with anything else? Could [43, 44] also work for the weapon ID part?

 

[Heirukichi]

What you wrote there is not going to work. First of all, when using variables in a code, you have to get rid of any leading zero. It is

$game_variables[81]

and not

$game_variables[0081]

That said, there are two things you should be aware of.

1) You mentioned a single weapon in your first post so that code has been written taking that into account. It is not meant to work with multiple weapons.
2) I am not sure if you already know this, but mentioning it is not gonna bring any harm anyway. A percentage value (I am going to use 45% in my example) means 45/100 and not 45. If you use the whole variable value in the formula, be sure to give it a meaningful value. Any value greater than 1 means that you always land a critical hit, and that is probably not what you want when writing 45 there. Be sure to turn it into a float value (0.45 in this case) before using it in the formula, or write the formula so that it returns a float value.

If you want to use multiple weapons, it is better to configure them in a separate module.

Spoiler: Code inside

#----------------------------------------------------------------------------
# ** HRK_SPCT module
#----------------------------------------------------------------------------
module HRK_SPCT
  #--------------------------------------------------------------------------
  # Weapons that use a special critical chance formula.
  #--------------------------------------------------------------------------
  WEAPONS = [43, 44] # add more as long as you separate them with a comma
end # end of HRK_SPCT module
#----------------------------------------------------------------------------
# ** Game_Battler class
#----------------------------------------------------------------------------
class Game_Battler < Game_BattlerBase
  #--------------------------------------------------------------------------
  # * Need Special Crit
  #--------------------------------------------------------------------------
  def need_special_crit(user)
   user.equips.each do |e|
     HRK_SPCT::WEAPONS.each do |i|
       return true if (e == $data_weapons[i])
     end
   end
   false
  end # Need Special Crit
  #--------------------------------------------------------------------------
  # * Custom Critical Chance Formula
  #--------------------------------------------------------------------------
  def custom_item_crit(user, item)
   $game_variables[81] * 0.01
  end # Custom Critical Chance Formula
  #--------------------------------------------------------------------------
  # * Aliased method: Item Critical Chance
  #--------------------------------------------------------------------------
  alias hrk_item_cri_old item_cri
  def item_cri(user, item)
   if user.actor?
    return custom_item_crit(user, item) if need_special_crit(user)
   end
   hrk_item_cri_old(user, item)
  end # Item Critical Chance
end # end of Game_Battler class

You can configure the weapons that use that special critical chance adding them to the WEAPONS array. This way you can use more than one weapon. Typos aside, it should work fine.

 

[Engr. Adiktuzmiko]

Using user.equips actually calls the method (named equips) which processes the IDs inside the @equips array and returns them as a new array which contains the item objects instead of the IDs.

So by doing user.equips.any? you are actually running the .any? method in the new array populated by the item objects. This would mean that your check wont work because it would be checking item objects versus IDs.

Also why check the whole equip array instead of just weapons? In your current code, assuming it works, if he has equipped an armor with that same ID, it will also cause the special crit to run. It would be better to keep the check to the weapons array, or if every equip does need to be checked, you need to check against an array specific to the type of that equip (if its armor or weapon).

 

[Heirukichi]

This would mean that your check wont work because it would be checking item objects versus IDs.

Thank you for pointing this out. You are 100% right. As a matter of fact, in the previous version I indeed used $data_weapons[weapon_id], but in the version with multiple weapons I completely forgot about that. I will promptly fix that.

Also why check the whole equip array instead of just weapons?

The main reason for this is that you cannot know how the system works in the game where this code is used. In my game, for example, you can equip three weapons instead of one (or two if dual wielding). Of course, the code can be further optimized by checking if the selected slot contains a weapon and skipping the check if the result of the check is false.

As soon as I can access the engine (this will take several hours) and check the name of the weapon class (it should be RPG::Weapon, but I am not 100% sure and I do not want to provide false information) I can modify the code and optimize it even more. Should anyone be able to confirm the name of the said class, I can optimize it even before then.

 

[FirestormNeos]

#----------------------------------------------------------------------------
# ** HRK_SPCT module
#----------------------------------------------------------------------------
module HRK_SPCT
  #--------------------------------------------------------------------------
  # Weapons that use a special critical chance formula.
  #--------------------------------------------------------------------------
  WEAPONS = [43, 44] # add more as long as you separate them with a comma
end # end of HRK_SPCT module
#----------------------------------------------------------------------------
# ** Game_Battler class
#----------------------------------------------------------------------------
class Game_Battler < Game_BattlerBase
  #--------------------------------------------------------------------------
  # * Need Special Crit
  #--------------------------------------------------------------------------
  def need_special_crit(user)
    user.equips.each do |e|
      HRK_SPCT::WEAPONS.each do |i|
        return true if (e == $data_weapons[i])
      end
    end
    false
  end # Need Special Crit
  #--------------------------------------------------------------------------
  # * Custom Critical Chance Formula
  #--------------------------------------------------------------------------
  def custom_item_crit(user, item)
   $game_variables[81] * 0.01
  end # Custom Critical Chance Formula
  #--------------------------------------------------------------------------
  # * Aliased method: Item Critical Chance
  #--------------------------------------------------------------------------
  alias hrk_item_cri_old item_cri
  def item_cri(user, item)
   if user.actor?
     return custom_item_crit(user, item) if need_special_crit(user)
   end
   hrk_item_cri_old(user, item)
  end # Item Critical Chance
end # end of Game_Battler class

I think I got this to work. Thank you.