Show Gigantamax indicator

[zaksabeast]

CaptureSight should indicate if a Pokemon can Gigantamax by putting "Gmax" in front of a Pokemon's name on the PokemonListLayout and PokemonSummaryLayout.

If there's a better way to show gmax, I'm open to ideas. The Gmax icon can't be used for the PokemonListLayout, so that's not currently solution.

[ulucs]

Why can't the Gmax icon can't be used in PokemonListLayout? Is it a space constraint, a matter of missing sprites, or that we can't access the gmax status from there?

[zaksabeast]

Space isn't a concern for an icon since ideally the gmax icon could be located behind or around the Pokemon icon. It's definintely possible to get the gmax icon as well as the gmax status for Pokemon and dens.

However if I recall correctly, there are a few constraints with Plutonium:

• A ListItem can only have one image (this is used for the Pokemon sprite)
• Images are given with a file path string (so we can't generate a single image to set)

I was also trying to think of a way we didn't need to add extra sprites for every gmax Pokemon.

Disregarding that last note, a few solutions off the top of my head:

• Add extra sprites for any Pokemon that can gmax (this adds extra maintenance any time a new gmax is introduced - nothing major though)
• Create a custom variant of the ListItem that supports two images (this adds extra maintenance to keep up with Plutonium updates)
• Use a text based solution (this has a space concern on the ListItem)

[ulucs]

Add extra sprites for any Pokemon that can gmax (this adds extra maintenance any time a new gmax is introduced - nothing major though)

This was the solution I had in my head, basically extending the pokemon sprites to accommodate different forms (Alolan, Galar, or special Pokemon) and Gigantamax

[zaksabeast]

I've been playing with the idea of redesigning the Pokemon lists to be one screen that mimics the box view in the games. On the left would be party, the center would be the current box, and somewhere else (upper right?) could have a single slot for trade, raid, and wild.

Some benefits would be one screen to view all Pokemon, provide a potentially better UX for the data being displayed, and the Pokemon sprites could be easily rendered on top of a gmax icon.

It's still just a thought, but would open many other doors as well.

I 100% agree with having sprites for different forms. :slightly_smiling_face:

[jim16]

Hey, if I might chip in since we're talking about other info Capture Sight should show, I think it would be useful for it to follow a bit of Leanny's seed check.

The main things missing for me is to know the Ability of a pokémon at a certain frame (It's important when hunting shinies with HA. If your shiny at that frame does not have HA you might as well look for another den or another poké on that den).

And also how to see different the stats of pokés on a certain frame. (3 pokes have different stats and nature than a 5 poké for example).

Not sure if that would be too much (or some of it is already implemented and I'm using it wrong) but usually I get the raid seed and go straight to SeedChecker on my phone or notebook to see what is on that frame, just knowing it's a shiny is not always useful.

[zaksabeast]

@jim16 Thanks! Those are great ideas, and some have been requested by other people as well.

You can set filters to see the different IVs for the different flawless IV counts each star has, but nature and HA haven't been added yet.

Since those should be tracked separate from the Gigantamax indicator, would you be willing to open a new issue with those requests?

Thanks again!

[zaksabeast]

@jim16 ability filters have been added with 39ac5bf0522f1cce47c0089792a541ec629e6220.

Regarding a Gmax indicator, I wonder if it'd be enough to show the Gmax version of the sprite instead of having the Gmax symbol behind or around the sprite.

Does anyone have thoughts on this?

Edit: I just read back and @ulucs had suggested this already. :sweat_smile:

I think this would be a good solution. :slightly_smiling_face:

[ulucs]

While we are at it, I think we can add forms in the same issue and have complete sprite functionality. I have finals in 9 days, but I'd love to tackle this issue afterwards.

[zaksabeast]

I just recently added the alternate form sprites, which is what made me revisit the Gmax topic some more. :slightly_smiling_face:

And awesome, thank you - I really appreciate that :smile:

Good luck with your finals!

[jim16]

@zaksabeast Oh, thanks! Sorry, I lost track of this.

Yeah, I think we can just show the sprites. It's cleaner, uses less UI.

But thanks for all the work. I think as it is right now CaptureSight might be the only app needed for shiny hunting. Great Job!

[zaksabeast]

@jim16 No worries, and I'm glad to hear you enjoy CaptureSight :slightly_smiling_face:

Thanks for the input as well!

[ulucs]

I'm thinking of automating the sprite imports. I avoided doing this myself the last time by waiting for pkhex to update, but they don't include dynamax sprites. So with the DLC's (which will add more dynamax sprites) coming up, I think automating this would be nice step. Realistically, we have two options for implementation:

First, removing the pokemon sprites from the source code, and instead adding msikma/pokesprite as a submodule along with a script to import the sprites on build time.

Or I could make a scripts folder under the applet folder and we could run make import-sprites (which would clone pokesprite in a tmp folder and extract the sprites) whenever pokesprite updates to update our sprites, without adding it as a submodule.

The downside is, well, we'd have to introduce a new language to the source. I'd love to use bash to handle this, but we need to parse json to import the sprites. Weighing them for ease-of-use and availability (for CI/automated tests), I think some suitable candidates are

• Javascript: node is not included in either Ubuntu or Arch, but has native JSON support and async support is amazing
• Python 3: included in both Arch and Ubuntu, so this is the best candidate for integration into the build system. However, the interaction with system and running jobs in parallel is a bit janky. Also lacks functional tools that make data processing simple
• Ruby: included in Ubuntu but not in Arch. I think ruby would be the best choice for being included for one-off sprite imports due to its great system interaction.

Another option would be to adopt the pokesprite naming scheme and simply cp'ing the sprite folder, but I believe having to deal with all the different form names and deviating from pkhex's structure would cause issues in the future.

So what are your thoughts? I'm personally leaning towards the ruby/one-off script approach due to discontinuous updates and ruby's ease of use.

[zaksabeast]

I think this is a great idea. :smile:

Between a submodule and make import-sprites, I think a submodules would be the best option:

• Anyone with the latest master branch has the same images
• We can roll back to previous images if there are issues
• No need to run additional commands to download assets
• make import-sprites is effectively creating a temporary submodule, however we won't get the benefits of source control

CaptureSight's build pipeline uses a slightly custom docker image (in fact, I should probably commit it to this repo), so any extra dependencies our pipeline needs won't be an issue.

I'm not entirely opposed to copying the naming scheme of msikma/pokesprite, however if the naming scheme of msikma/pokesprite ever changes, we'd have to update CaptureSight's code to support it, which may not be the best method for CaptureSight's use. Having a script allows us to code CaptureSight in a way that works best for CaptureSight.

If we introduce a scripting language, these are the considerations I'd like to think of:

• How popular is the language? (More devs can contribute if they know the language and will have the tools necessary to build csight, regardless of the default tools installed on operating systems)
• How easy will it be to use for our use case? (Work smarter, not harder!)
• When the script runtime updates to new versions, how much/often will the script need to be updated too (We'll want to make sure the latest runtimes are used since that's what most people will have installed)

Thoughts?

[ulucs]

If extra dependencies is not an issue, then I'm leaning towards Ruby. The script basically involves reading from a json file, flatmap'ing the sprite data and running mv for each sprite to move things into romfs. So it will be basically a bash lookalike, and most people shouldn't have any problems even if they only know a bit of bash.

I don't know how popular the languages are in the homebrew community, but I both Javascript and Ruby are used in game engines for scripting and all three are generally popular languages. All three are mature enough that they won't break backwards compatibility without a long-lasting depreciation warning.

I think I can first write all three variants and then we could choose between them on how nice each script is and how fast they run (as it's going to be executed on each build).

[zaksabeast]

Looking at the naming scheme of msikma/pokesprite, I think it's probably a good idea for us to pursue the script route. The file names are very human readable, but will cause Csight to give names to specific forms of specific species, which isn't ideal.

Between JavaScript, Python, and Ruby, the first two have been more popular for the past several years.

You're right about all three not breaking for a while. That said, popular JS runtimes will be backwards compatible with previous versions. Interestingly, msikma/pokesprite is setup to be a node module, which might be useful for us. I've also seen a few python scripts used in 3ds and switch homebrew (I believe crypto operations were involved, which made it favorable over other languages).

I'm not quite seeing the appeal to Ruby at the moment. It might be easy to follow syntactically, although the same could be said for JavaScript and Python too. With JavaScript and Python being more popular scripting languages, plenty of people will be able to read both without trouble. I might be missing something though, so just to help me understand, since all three are arguably easy to read and won't have many version issues, what benefit will Ruby provide over JavaScript and Python?

Truth be told, I've done some Python and have done JavaSript professionally for several years. I don't have much experience with Ruby, but am not opposed to it if it provides the most value in this case.

I'd be up for seeing all three variants. :slightly_smiling_face:

[zaksabeast]

I'm going to close this since it's stale. If anyone still desires this feature, it can be added to the overlay.