No shinies

[mahousenshi]

There's should be a minimal chance for a shine pokemon, just a improve.

[LazoCoder]

If you deliver 1 masterball to my home I will add this feature.

[dweipert-3138720606]

Would you just use an alternate color palette and apply that to the existing image or would you make a whole new image? 🤔

[samuelhnrq]

I bet you could use stuff like image magick to apply a filter on top of a existing one and generate a new "shiny" image on the fly rather then doubling the size of the repo 😅

[LazoCoder]

I agree with @samosaara, it would be best to add a filter instead of creating new images. Probably a simple hue shift would be enough.
But I'm not sure that everybody knows what a shiny pokemon is... maybe some people will think its a bug if the images come up as random colors occasionally. Furthermore the extra dependency on an external library like image magick or PIL makes it seem to me that there might be more cons than pros to adding this feature.
Alternatively, if somebody really wants a particular shiny pokemon, they can just find one online and add it to the Images\Extra folder and it will show up in the program (as per the Adding Custom Images section in the readme).

[dweipert-3138720606]

I think people who like Pokémon that much to use them as their terminal background would know what a shiny is. 😄

[giftig]

The nice simple shapes and limited palette of the backgrounds make them nice backgrounds where you need to be able to read text over the top. Having a shiny picture in my terminal background would be less appealing.

[indiecyberpunk]

The nice simple shapes and limited palette of the backgrounds make them nice backgrounds where you need to be able to read text over the top. Having a shiny picture in my terminal background would be less appealing.

@giftig https://bulbapedia.bulbagarden.net/wiki/Shiny_Pok%C3%A9mon Shiny Pokemon are basically just palette swaps (though that's not entirely 100% correct)

[giftig]

Ah fair enough, I thought they were literally shiny. Guess I've proved @DRogue1337 wrong :D

[IamCarbonMan]

I could work on this. The creator of most of the wallpapers, PLDH, never did shiny wallpapers, but his site does have regular and shiny sprites. I could color-convert the wallpapers we have using colors from the shiny sprites.

@LazoCoder, you had mentioned not wanting to bring in an extra dependency via ImageMagick. Perhaps it could be an optional dependency? I suppose one way to do that would be to use the ImageMagick shell commands directly instead of using a Python wrapper. Many people will already have ImageMagick installed on GNU/Linux systems, and if the command isn't found, we can just tell the user they would have found a shiny if they had it installed.

The other question pertaining to this feature is when to randomly inject a shiny Pokemon into a regular request. Should the change_wallpaper and change_terminal_background methods randomly choose to replace any given Pokemon with a shiny version (which would give the potential for any command line option to yield a shiny)? What should the frequency of shinies be? Should we put a (preferably undocumented) shiny command line option to specifically select a shiny?

[IamCarbonMan]

Examples: https://gist.github.com/IamCarbonMan/247f3c08f765e020f39e4934386790c5

[sylveon]

That seems like a great idea to minimize download sizes. However, the file would still need to be stored somewhere, and because of terminal emulators such as tilix where the setting is permanent or cases like setting the image as wallpaper, we can't just store it in /tmp. I would rather avoid to store it into the Images folder of the script because on Arch Linux, since the install is system-wide, you wouldn't be able to write here. We could store the files in ~/.cache and populate them with imagemagick as required.

…

On Sun, Jun 25, 2017 at 4:49 PM, IamCarbonMan ***@***.***> wrote: Examples: https://gist.github.com/IamCarbonMan/247f3c08f765e020f39e4934386790c5 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[LazoCoder]

The optional dependency sounds good to me if you can get it to work. The odds of encountering a shiny pokemon in the games are 1 in 8192, so we can use those odds.

The hard part of all this is figuring out a way to integrate it seamlessly into the project in a way that the code is still readable and easily maintainable. Adding it to change_wallpaper and change_terminal_background seems intuitively the best way to do it. But consider the case where a user does pokemon light and gets a shiny pokemon that is instead dark. Maybe have a flag to not do shiny's if the light/dark functions are called.

And @charlesmilette makes a good point about storage. There is a lot to consider here.

[IamCarbonMan]

I'll keep working on this, it's rather tedious because I have to use a color picker to get every single color from the shiny sprites. I'll hopefully find a way to automate it a bit later today.

As far as storage, storing it in ~/.cache sounds fine. With the new light and dark commands, we can have those pass along an optional parameter to skip shinies. At a 1/8192 chance though, I kind of think people would prefer to have to type the command again than miss seeing it.

[LazoCoder]

I kind of think people would prefer to have to type the command again than miss seeing it.

What do you mean?

Are you implying that you want to put in a command like pokemon charizard shiny? If so, that's fine with me.

[IamCarbonMan]

Well, I think if there's a shiny functionality in the package then there should be a shiny command. But I also think that if I type pokemon light and get a shiny (black) charizard, I'd be more impressed that I had gotten the 1/8192 chance than I would be irritated that I got a different color. We could block shinies from appearing when used with light and dark options, but I think the shinies feature is cooler.

[LazoCoder]

@charlesmilette @samosaara @cclauss @dosman711 What do you guys think of this?

If a user types pokemon light should there be a chance of a shiny pokemon? Or should shiny pokemon only be limited to the command pokemon random?

[IamCarbonMan]

Not just pokemon random at the minimum. pokemon pikachu should have a chance to spawn a shiny Pikachu, and possibly pokemon slideshow should include shinies.

[IamCarbonMan]

On the technical side, here's basically what the data files look like:

bulbasaur b3ffb1 77ac98 83cf7a 4e8872 008421 5b9b76
ivysaur a1d544 288887 779d1d 1a6e6b
venusaur 99d43d 57a6a1 ffce0a b5525f
charmander efa003 f4b186
charmeleon efa003 d3675a
charizard 84799c db8d4b 870d29 cf824c
squirtle 58ae29 836f62
wartortle 8a7db5 a7bee0
blastoise 8a7db5 a7bee0
caterpie fac40f 8bc87a
metapod fe743a 86b243 c55a16 78a152
butterfree d8adc3 dcefeb 63ef5d aa203e df505f 9fc3db
weedle ffb401 d19e43
kakuna c0cd31 f4e08a 9bb929 d8c173
beedrill 80c721 edce64 3e5ace ca4b60
pidgey 8a8c0d a06a2e
pidgeotto 788433 ae6e30 fdda18 f09170
pidgeot fffcaa ca4f43
rattata 918e2e a760a5
raticate b45329 cc9552
spearow efa206 d3756e c0ae20 9b6b54
fearow 8a8e325 ad7341 ced373 895a32 de7605 d66b57
ekans 838927 8d6893
arbok af7d26 a69fbe 2c6696 c96258 d0f378 c4a952
pikachu fea502 f7de81
raichu d84c36 f1bc4a

To make a Pokemon shiny, you run it through the imagemagick command convert -fuzz {2-10}% -fill "#{color}" -opaque "#{color}"- each pair of colors is filled into a separate fill/opaque block. Also the -fuzz value is typically 5, but you can tweak it if the picture comes out weird and it should fix the problem.

I'm filling these in manually using a color picker and https://pldh.net/dex/sprites/. It takes a while and is somewhat error-prone, so this feature could be delayed at least a week.

[IamCarbonMan]

Well, it's definitely been a lot longer than a week 😓

I'm going to start working on this again. It was mentioned that in the samples I created the boundaries between colors can get blurred, hopefully I can adjust the fuzz values per-Pokemon to account for this. Either way each Pokemon takes at least 5 minutes to do, so I'm hoping to be able to have this done before too extremely long.