Greying out skill type commands in battle when skill types are sealed

[Panda_Artist]

Good morning / afternoon / evening, everyone.

I am in need of your assistance once again.

Sealing the skill type will block your actors from using the skills indeed, but it still allows them to select the command and see the list despite not being able to use any of the skills.

Is there a way to make it so that the entire command is greyed out when skill types are sealed?

Any help would be appreciated.

 

[Panda_Artist]

Bump

 

[Traverse]

What you want is to make a very small, brief edit in the script editor to Window_ActorCommand, which as the name suggests, is the window that draws and displays the commands for an actor during battle.

Specifically the part that looks like this:

  #--------------------------------------------------------------------------
  # * Add Skill Command to List
  #--------------------------------------------------------------------------
  def add_skill_commands
    @actor.added_skill_types.sort.each do |stype_id|
      name = $data_system.skill_types[stype_id]
      add_command(name, :skill, true, stype_id)
    end
  end

Again, as can probably be inferred by the name, "add_skill_commands()" is the Method responsible for adding the skill commands to the list of options. It runs through the current actor's entire list of available skill types and adds them to the list of commands using "add_command()" as it does.

The third argument/parameter in "add_command()" is meant to dictate whether the command appears disabled/greyed-out on the list - if the value is "true" it will be enabled/selectable. If the value is "false" it becomes greyed out. As you can see, by default, the window sets it to always be "true". Irrespective of whether the actor is inflicted with any skill-sealing status or whatever - it just doesn't check for anything.

So you will need to replace that "true" with a check for whether the actor has the skill type sealed.

Fortunately, actors by default come with an existing Method that does this, called "skill_type_sealed?()". This is one of the checks called in Window_SkillList where individual skills get greyed out (among other checks which include whether the specific skill has been sealed or whether the actor has enough MP/TP to pay for it). This Method is not actually located in the code for the windows themselves, but in the code for actors, which is found within Game_Actor (and its superclasses Game_Battler and Game_BattlerBase) in the script editor.

So you can just use that Method to replace the hardcoded "true" to do the check (or well, the negated result of it, since "skill_type_sealed?()" will return "false" if the skill type is NOT sealed and "false" disables the command).

I don't think I need to point out the obvious caveat that this relies on you not using any other scripts that make modifications to Window_ActorCommand or huge battle system overhauls that bypass using Window_ActorCommand entirely. As otherwise those scripts could contain stuff that overwrites/bypasses everything you did and then you need to look at those and pick through them to figure out how/what they changed.

 

[Panda_Artist]

I am very sorry but I know very little coding... could you explain exactly step by step on how I can achieve this?

In this case, I just want to make sure the commands are greyed out when a character has a certain state, then it goes back to normal when the state is removed.

 

[Traverse]

That was the "step-by-step". There is only one step.

Replace the hardcoded "true" in the "add_command()" method within that section of Window_ActorCommand with a call to the method that checks for an actor having the skill type sealed. That method being Game_Actor/Game_BattlerBase's "skill_type_sealed?()".

A method call is exactly the same thing as what you do in a Script Call whenever you are typing something like "$game_party.add_actor(actor_id)". When you do a Script Call like "$game_party.add_actor(actor_id)", what you are actually doing is performing a call to Game_Party's "add_actor()" Method, with the argument/parameter data passed into it being "actor_id".

You're just replacing the "true" with that, except the method you're calling is the actor's "skill_type_sealed()". That's all you need to do.

 

[Panda_Artist]

I must be doing something wrong



I did this and the commands are still the default colour and selectable... whereas I wanted them to be greyed out and buzzered when the skill type associated with them are sealed. This didn't work...

 

[Roninator2]

Well if what Traverse said works then all you're missing is the ?
skill_type_sealed?()

 

[Panda_Artist]

I'm sorry to say but it still didn't work. It must be because I'm using another script that handles the skilltypes.

 

[Roninator2]

Try

add_command(name, :skill, skill_type_sealed?(stype_id) , stype_id)

It looks like that method wants an argument.

 

[Traverse]

I must be doing something wrong

Yes, you called the method wrong.

Firstly, it is called "skill_type_sealed?()" not "skill_type_sealed()". Next, as Roninator said, it requires an argument to be passed into the parentheses. But there's also another thing.

As I mentioned, the method does not belong to Window_ActorCommand class - it belongs to Game_Actor (or, well, its superclass Game_BattlerBase, but Game_Actor inherits all the code in it anyway).

So going back to the example of calling methods during a Script Call, whenever you type code to do a Script Call, the class that tries to execute the Script Call is actually Game_Interpreter. So whenever you call a method like " add_actor()" in a Script Call it actually tries to look for it in Game_Interpreter and since "add_actor()" does not exist in Game_Interpreter, just typing something like "add_actor(1)" alone will throw an error. "add_actor()" belongs to Game_Party and needs to be called from Game_Party or an instance thereof.

This is why the proper Script Call is "$game_party.add_actor(whatever actor ID)" and not just "add_actor()". $game_party is the name of the variable that contains the Game_Party instance (variables preceded with "$" can be accessed from any class, while variables preceded with "@" can only be accessed in the class they were declared in - if there's no symbol at all in front of it, it can only be used in the individual method they were declared). So this Script Call is telling Game_Interpreter to run Game_Party's add_actor() method.

Similarly, "skill_type_sealed()" belongs to Game_Actor. You need to call it from the actor object, in the same way that this line of code is calling from the actor:

@actor.added_skill_types.sort.each do |stype_id|
    ...
    ...
end

What this line of code means is:
1. Call the method "added_skill_types()" from the Game_Actor class contained in the "@actor" variable. This returns a list of the actor's available skill type IDs.
2. Call the "sort()" method from the result generated by the previous method call. The list of IDs is called an Array, and "sort()" is a method belonging to the Array class. This sorts the IDs from smallest to largest.*
3. Call "each" from this sorted array ("each" is another method belonging to the Array class). What this does is run through the sorted Array - for each ID in the array, temporarily assign the current ID being processed to a variable called "stype_ID" and then run all the code inside the "each do" block, doing it over and over as many times as there are items in the array.

Knowing this will be enough to tell you which variable you should call "skill_type_sealed?()" from and what variable to put in as the argument.

And before you say it, yes, this kind of method calls within method calls within method calls can make your head spin but that's what a programming in a language like Ruby tends to typically be like.

*If you're wondering what the point of sorting the list is - it makes it so the commands for the skill types appear in the window in the same order as they are listed in the Terms tab in your Database. Without sorting, they would instead appear in the order that they were added onto the Features list of the actor and their character class (all actor Features will get listed first, then all class Features). I.E without sorting, if you gave Eric the "Magic" skill type under his actor's Features list and then "Special", the "Magic" command would show up first on the window before "Special". With sorting, "Special" appears first in the window because it has a lower ID in the Terms tab (#1 while Magic is #2), even if Magic has been added higher up on his Features list, earlier than Special.

 

[Panda_Artist]

Ah I know why it's not working, it's clashing with Yanfly Commands, Skill Command Exceptions and Selchar's Limit Break which I'm using...

 

[Traverse]

Yanfly Commands

Ah, yes. This one would definitely cause a clash.

That script makes extensive modifications to Window_ActorCommand, it even completely overwrites the window's default "add_skill_commands()" method. If you want to use it, you would need to edit the Yanfly Commands script itself and modify the modifications Yanfly made to Window_ActorCommand.

It's the same modification as you would have made to the default Window_ActorCommand (replace the hardcoded "true"). You're just doing it in the different place:

  #--------------------------------------------------------------------------
  # new method: add_skill_type_command
  #--------------------------------------------------------------------------
  def add_skill_type_command(stype_id)
    return unless @actor.added_skill_types.include?(stype_id)
    return if @stype_list.include?(stype_id)
    @stype_list.push(stype_id)
    name = $data_system.skill_types[stype_id]
    add_command(name, :skill, true, stype_id) # <-- Does this line look familiar??
  end

 

[Panda_Artist]

I wonder what I'm doing wrong. Maybe it's because of Selchar's skill command exceptions.

Another Solution for what I WANT TO ACHIEVE is to have an addon for Yanfly Battle commands that allows me to change battle commands for actors / classes via a script call...

I changed a line in skill command exceptions to look the same and it still gives me the same error...

 

[Traverse]

Again, you are calling the method incorrectly.

The way you are calling it, you are trying to call Window_ActorCommand's "skill_type_sealed?()" method. As the error message tells you, Window_ActorCommand has no "skill_type_sealed?()" method.

It is Game_Actor that has "skill_type_sealed?()". You must call it from a Game_Actor object.

And the actor whose skill types are being drawn in Window_ActorCommand is stored in the variable "@actor". So you must call it from "@actor".

Furthermore, the "skill_type_sealed?()" returns "true" if the skill type is sealed and "false" if it is NOT sealed, so you must use the opposite of the result - otherwise you will have unsealed skill types greyed out and sealed ones selectable.

You can invert the result by putting a "!" (the "not" operator) at the start of the method call.

 

[Panda_Artist]

I'm sorry but I am having a hard time understanding, so I simply replace
skill_type_sealed?() with skill_type_sealed!()?

or wait so should I put !skill_type_sealed?() ?? you did mention start of the method call

 

[Traverse]

At the start ("!skill_type_sealed?()") is correct .

But you need to call it from @actor.

Like, "@actor.skill_type_sealed()".

The "@actor" variable contains the Game_Actor object corresponding to the actor whose commands are being listed in the window. The "skill_type_sealed()" method belongs to the actor and you need to call it from the actor whose sealed skill types you're trying to check - because otherwise how would the game know which actor exactly you're checking the sealed skill types of?

 

[Panda_Artist]

It... worked!!! I also did the same for skill command exceptions!

Thank you so much for this! If I have any problems I will let you know!!