Resource Innate Abilities (Yet Another "All Abilities Mutation" mod) 1.5.3

[komeiji514]

Yeah I should probably re-check a lot of the original code since it is from v20, specially the one that calls for other plugins. I'll give them a look, hopefully I could fix Guard Dog and Opportunist in them lol.

Thanks for the report.

I am using the latest Gen9 pack and after testing Guard Dog and Opportunist can work as intended as both Ability and Innates.

 

[Penelope]

Ok lets go by steps:

I didn't realized that Transform/Imposter use a different method to change the user rather than utilizing pbUpdate, so the innates arent re modified for them. I have already fixed the issue by modifying pbTransform to include a call for the target's current innate list and it will be included in the next update, so thanks a lot for that report!

As for the id problem yeah, it seems to be an issue with AAM's original code not handling those cases properly. I could suggest for an inmediat solution to your problem to simply give those pokemon with no abilities the "No ability" ability that is already included in the plugin. It thecnically is an ability with an ID and code so it stops all forms of crashes, it just does absolutely nothing more.
Ngl I didn't really consider cases with no specific abilities in a plugin that centers on giving MORE abilities lol. But I'll look for a solution.

As for Stance Change, not only that one, but Zen Mode, Shields Down, Ice Face and Disguise (And I think Illusion) don't work as innates either. This is because the way they are coded in base essentials. The plugin modifies the "hasActiveAbility?" method to include the list of the pokemon's current ability and innates.
The codes for those abilities ONLY look for if the pokemon's current ability it's equal to them.
To fix it I would have to alias a lot of the base code which is something I don't really want to do because I want to keep the plugin as not invasive to the base script as possible, but at this point I think I'll have to.

You could just exchange those codes for hasActiveAbility?(:STANCECHANGE) for example and it works. I don't really understand why the originals dont use that method but it has to be a reason, so I'll try to call them directly from the innate list instead of using the hasActiveAbility one for any possible problems.

1.you could remove nil from the array
2.those abilities that dont use hasactiveability? is unsuppressable, they dont need to be active.(neutralizing gas, gastro acid etc.)
You dont need to overwrite those methods, these methods are too long.
You just need to modify the == method.

Good luck

 

[Sonicover]

I am using the latest Gen9 pack and after testing Guard Dog and Opportunist can work as intended as both Ability and Innates.

H o w ?

I'll have to try it in a fresh copy of essentials but I can't for the life of me figure how to activate them in my own game

 

[Sonicover]

1.you could remove nil from the array
2.those abilities that dont use hasactiveability? is unsuppressable, they dont need to be active.(neutralizing gas, gastro acid etc.)
You dont need to overwrite those methods, these methods are too long.
You just need to modify the == method.

Good luck

Don't they have their own section of unsupressable abilities also? But I guess also a direct check its easier to do, so I'll try to aliase them for if the innate array includes them as well

 

[komeiji514]

H o w ?

I'll have to try it in a fresh copy of essentials but I can't for the life of me figure how to activate them in my own game

The Guard Dog can be fixed by changing user.ability == :INTIMIDATE. But Opportunist DOES works without change as far as I have tested. Idk whether they work for other users.

 

[Bguy7]

Ok lets go by steps:

I didn't realized that Transform/Imposter use a different method to change the user rather than utilizing pbUpdate, so the innates arent re modified for them. I have already fixed the issue by modifying pbTransform to include a call for the target's current innate list and it will be included in the next update, so thanks a lot for that report!

As for the id problem yeah, it seems to be an issue with AAM's original code not handling those cases properly. I could suggest for an inmediat solution to your problem to simply give those pokemon with no abilities the "No ability" ability that is already included in the plugin. It thecnically is an ability with an ID and code so it stops all forms of crashes, it just does absolutely nothing more.
Ngl I didn't really consider cases with no specific abilities in a plugin that centers on giving MORE abilities lol. But I'll look for a solution.

As for Stance Change, not only that one, but Zen Mode, Shields Down, Ice Face and Disguise (And I think Illusion) don't work as innates either. This is because the way they are coded in base essentials. The plugin modifies the "hasActiveAbility?" method to include the list of the pokemon's current ability and innates.
The codes for those abilities ONLY look for if the pokemon's current ability it's equal to them.
To fix it I would have to alias a lot of the base code which is something I don't really want to do because I want to keep the plugin as not invasive to the base script as possible, but at this point I think I'll have to.

You could just exchange those codes for hasActiveAbility?(:STANCECHANGE) for example and it works. I don't really understand why the originals dont use that method but it has to be a reason, so I'll try to call them directly from the innate list instead of using the hasActiveAbility one for any possible problems.

I'd rather not do use the "No Ability" ability, just because then it would show up on the ability page of the Pokémon description, and that feels strange to me, but if that's the solution, then that's the solution. I understand that it's a very niche problem that probably no one else but me is having, so I'll deal with it.

I'll look into making the changes for Stance Change and the like. If I had to guess, the reason for the difference is that abilities like Stance Change, Shields Down, and the others will always work and cannot be negated or suppressed, as they are considered innate aspects of the Pokémon (ironic that they don't work as innate abilities). The purpose of hasActiveAbility? is to check if the ability is currently active or not, while self.ability only cares if the Pokémon has the ability in the first place, and not if the opponent has used Gastro Acid or something similar. This would make sense, as you can compare those abilities you listed to Hunger Switch, a similar form changing ability, but it uses hasActiveAbility instead of self.ability, and it is allowed to be negated.

If that is the only reason for the difference, then it might be a redundant difference, as abilities like Stance Change are listed under unstoppableAbility? which will stop things like Gastro Acid from working in the first place, so it will always be an active ability anyways. My guess is that it's just an extra backup that was done because they could, not because they needed to. With that in mind, I think it should be fine to change self.ability to hasActiveAbility?, so I will be making those changes.

As always, thanks for your attentiveness.