Wrong Ox ability trigger data

[WolfDWyc]

The Ox ability trigger is currently set as AfterAttack and it should actually be Faint:

        "trigger": "AfterAttack",
        "triggeredBy": {
          "kind": "FriendAhead",
          "n": 1
        },

[bencoveney]

Good spot!

Thanks for your contributions of all the incorrect data values. I manually populated them all initially so its great to have another set of eyes on them catching the mistakes.

[bencoveney]

Fixed, thanks!

[WolfDWyc]

Good spot!

Thanks for your contributions of all the incorrect data values. I manually populated them all initially so its great to have another set of eyes on them catching the mistakes.

Yeah, no problem - sorry if this isn't a good place to say this because it doesn't relate to the issue, but I've been using the API and it's mostly really good, thank you so much for making it, but I wanted to ask:

There are a bunch of things I reported that I noticed while implementing, but there are some things I wouldn't consider bugs still might be good to change. Some pet abilities (from what I noticed: sheep, deer, rooster and rat) where you can't actually infer all of the ability's effect just from the fields present.

Do you think that's something worth changing? I'm not sure if inferring abilities is a target you put for the shape, but if you do want to change it, I'd be happy to work on it with you and try to help figuring out the best shape for it.

[bencoveney]

I would be more than happy to look at any suggestions/feedback you have.

Some context for what I've been trying to do:

• My end goal is to be able to generate good descriptions for all the different pets and abiliities, including the gotchas that trip up new players (I don't know if you've ever thought "wtf does that do, i'm 1hp and don't want to risk taking that and guessing what it does).
• I spent a while manually getting that data copied out of that game, and now it makes sense for it to be publicly accessible (through the API file) so hopefully nobody else has to go through that pain again 😄
• As I am going through each of the pets and getting reasonable descriptions generated on the pet pages (I've only got tier 1 to a good state so far). Now that I'm doing this, I get an opportunity to go back through and refine how the data in the API file is shaped.

I wouldn't want to give the impression that what is in the api.json file is super well planned, or can't be changed, because I'm changing it all the time. So if you have feedback, I'd love to hear it, and its probably a good time to make those changes!

For reference, if you search the repository for "TODO" you'll see there's already a bit of a back-catalogue of places I've already found that could do with being improved.

[WolfDWyc]

That's awesome! Glad to see you're aware of most of the changes that should be added, like in the rooster. I also checked out the generated ability descriptions and they're very cool - they make it a lot easier to understand.

Here are some other changes that should be discussed, focusing on pet summons:

Summon location

• When spawning a pet on your own team using a standard trigger (Cricket, Bee, etc.), the default "implied" behavior is that it will spawn in-place of the pet that triggered the event. However, for the fly and the rat, that location would be wrong.
• One possible solution is to add an attribute/field called "location" that will either be FrontOfTeam, BackOfTeam, or InPlace
• A different solution could be to simply let it be. You could say it's fair to assume that when the triggeredBy.kind attribute is Self it would spawn in place and when it's anything else would spawn at the front of the team (for the fly), and that it's also fair to assume that because the enemy team is usually displayed inverted, if the team attribute is Enemy it would spawn at the back of the team (for the rat).

Status effects

• When the deer faints, it summons a bus with the chili status effect, this is currently not mentioned in the api. it IS mentioned in the API - my bad!
• One possible solution to this is to add the status attribute on the bus itself, like in the scorpion. This may be an issue for a reason I specified in the Scorpion's section.
• Another solution, which seems more future-proof, but less logical given the current pets, could be adding a withStatus optional attribute to the SummonPet ability effect, similar to the current withHealth and withAttack

Summon count

• When the sheep faints, it spawns 2 rams - this is currently not mentioned in the api.
• One possible solution to this is to add a count attribute to the SummonPet ability effect.
• Another solution is to change the sheep effect to AllOf, with 2 effects in the effects attribute, each being a SummonPet effect that summons 1 ram.

Scorpion

Poison status effect

• The scorpion has 2 issues, the first one being that the poison status effect has undefined behavior. A way to solve this is to change it from DealDamage to ReduceHealth like the skunk with a percentage of 100.
• This wouldn't mention the fact melon armor/coconut shield blocks this status but not a skunk's attack. This functionality in the game is very inconsistent in my opinion, and I think the only way to solve it is to add a boolean ignoreShields attribute to the ReduceHealth ability effect.

Summoning

• The second problem isn't exactly a problem, but more of an unexpected behavior for new players you should make sure to cover in your descriptions: When a pet has a status attribute on it (currently only for the Scorpion, but maybe also for the bus and other pets in the future), it can be assumed that when it's spawned from an extra life it will still have that status effect, but this is not the case.
• You could also argue this is an actual problem, but one with the extra life status, and should be specified there, but I beg to differ. I haven't seen this happen, but I think that if a whale would spit out a scorpion that, when swallowed, didn't have the poison status effect, it wouldn't have it on the new one either. If this is the case - then the rule is that only if the triggering pet had the status effect, then the summoned pet will have it - which isn't an issue, but an unexpected behavior. If it isn't the case - then this should simply be documented in the extra-life effect as overrideStatus: true (or not documented at all).

Note

I've noticed that for all status-effects that change damage, their effect is set to a wrong ModifyDamage, which should only be set for the weak status, and all others should be replaced to DealDamage

Thank you again for being so active and willing to take feedback and improve the project!