Matchup Database

I’ve added G. Panda as a variant of Lum, but I ended up brute forcing a few things (mainly the Attack and Throw lists, since I don’t know if there’s a way to remove values from the list instead of just adding to it). A couple things I noticed:

  • How do I remove the “Gambling Panda” title from G. Panda? He doesn’t have it on his card, so it shouldn’t be there. I could just replace it with an empty string, but there’s probably a more elegant solution.
  • The normal throws for both Lum and G. Panda don’t indicate that they can be pumped in the throw comparison list, and they don’t have any combo info either.
  • It would be hilarious if, while G. Panda is selected, Lum’s portrait could be replaced with G. Panda. No idea if that’s possible, and it’s not a problem if it can’t be done, but it would be great if it can.

Aside from that, he’s now a fully functional variant!

Cool!

  • How do I remove the “Gambling Panda” title from G. Panda? He doesn’t have it on his card, so it shouldn’t be there. I could just replace it with an empty string, but there’s probably a more elegant solution.

I’d just use title: null below the fullName: ... line.

  • The normal throws for both Lum and G. Panda don’t indicate that they can be pumped in the throw comparison list, and they don’t have any combo info either.

Sounds like a bug in our standard Lum implementation? I’ll take a look.
EDIT: Fixed it.

  • It would be hilarious if, while G. Panda is selected, Lum’s portrait could be replaced with G. Panda. No idea if that’s possible, and it’s not a problem if it can’t be done, but it would be great if it can.

I think that could actually be possible by setting the theme.headshot property on the G. Panda variant. It would likely need some additional coding, though, and would have to be the same size as the other portraits.

OK, I’ve just submitted the edit to remove the title and you’ve fixed the throw bug… Except that G. Panda’s T throw has messed up damage. I guess it doesn’t think ‘T’ is a number for some crazy reason! :wink:

Great! Thinking about it, since G. Panda will only have his portrait shown if Lum was already selected, the only portraits he needs are the red and blue bordered versions. On that note, another thing that would be nice, but is totally unnecessary if it’s too much work, is if the blue bordered portraits could have a light blue background instead of a yellow/orange background.

I guess it doesn’t think ‘T’ is a number for some crazy reason! :wink:

Ah, yes, it was missing a call to rankValue.

On that note, another thing that would be nice, but is totally unnecessary if it’s too much work, is if the blue bordered portraits could have a light blue background instead of a yellow/orange background.

Right now, the border is done dynamically, but the background change is embedded in the image. I’m happy to accept a PR with the images modified to include another background, but I don’t think I’ll ever do it myself.

1 Like

I may see if I can make a blue background at some point, but it probably won’t be for a while.

Edit: @vengefulpickle, I attempted to add EX Rook and DeGrey. It was fine until the build for EX DeGrey finished, at which point the site got stuck in infinite loading…

Yeah, looking at the web console logs, you were missing an import of the <Linker/> tag. I just added it.

1 Like

Ah, I have to assume it was missing because normal DeGrey doesn’t get any linkers. I’ll look out for that in the future!

I’ve added EX Valerie, but I’ve also noticed a bug related to EX Rook that seems… Really odd. It’s in the issues page, so please take a look when you get a minute.

1 Like

Cool! I fixed the issue that was preventing throws from showing up.

1 Like

Whew, that’s the EX versions of the base cast & Menelker done*! I’ll probably add at least some of the Shadows characters tomorrow, but that’s enough for today. While I’m thinking of it though, does anyone know whether Deathstrike Dragon from the EX expansion uses Menelker’s Destiny cards (in other words, is it meant to be used against EX characters)? I’m guessing the answer is yes, but it would be nice to get confirmation.

*Not including any combos that are either started by Destiny moves or are changed by EX abilities or Destiny moves.

Excellent! I’ll look into make it easier to update the combo strings without having to copy everything.

1 Like

Yes, DSD uses Menelker deck with destiny cards.

1 Like

I noticed some errors with Arg’s combos, so those have been fixed. @vengefulpickle, should I wait for you to figure out the combos, or just add more EX characters whenever I have time?

1 Like

I think whatever I end up w/ for the combos is going to be easy to add on on top of the existing EX definitions, so I don’t think you need to wait.

1 Like

I’ve added the EX versions of the Round 2 characters, which leaves 5 EX characters and Deathstrike Dragon. Speaking of which, is there a way to make a variant that’s mostly a copy of another variant? Since Deathstrike Dragon gets EX Menelker’s D rank, it would be nice if I didn’t have to duplicate that.

Yeah, you could do something like:

const DSD = Object.assign({}, menelker, {
    ... some stuff here ...
});

const EX = Object.assign({}, DSD, {
    ... EX overrides ...
});

menelker.variants = {
    EX: EX,
    DSD: DSD
};

Hm… Could you make that a bit clearer? I’m not sure how much goes in “some stuff here,” for starters. Is that all of the variant info, and the EX: EX and DSD: DSD part is just to move the info to the actual variants section? Also, I’m pretty sure I’d want DSD to override EX, since that’s the order I’d do things in the physical card game (add the EX cards to Menelker, then replace the EX character card with the Deathstrike Dragon character card).

Yeah, basically, whatever you put inside the second set of {} inside Object.assign is what you’re using to override the second argument to Object.assign. So, if you want to do EX first, you do Object.assign({}, menelker, { ... EX overrides ... }, and then Object.assign({}, EX, { ... DSD overrides ..}. You’ll need them to be in separate variables just so that you easily reference the EX version in the DSD version.

Does that help?

…Sort of? I feel like I’m missing some key piece of information that would let all of this fall into place. Am I literally putting in EX overrides and DSD overrides, or is that pseudo code? If it’s real, is that all that goes in the second {}, or is there more?

Sorry, yes, that’s just pseudo-code. EX overrides means yomibase/menelker.jsx at master · cpennington/yomibase · GitHub.