Inconsistent implementation of Attributes

[nshram]

Example position:
Stipulation =1
Option Variation NoWK NoBK
Pieces
black Chameleon Ga6 (1.b8=Q/R/B/S/G/cQ/cR/cB/cS/cG=) <--?
white Pb7
Twin add black Jigger Ga6 (1.b8=Q/R/B/S/G)
Twin add black Kamikaze Ga6 (1.b8=Q/R/B/S/G)
Twin add black Paralysing Ga6 (1.b8=Q/R/B/S/G)
Twin add black Royal Ga6 (1.b8=Q/R/B/G)
Twin add black Volage Ga6 (1.b8=Q/R/B/S/G)
Twin add black functionary Ga6 (1.b8=Q/R/B/S/G)
Twin add black halfneutral Ga6 (1.b8=Q/R/B/S/G)
Twin add black hurdlecolourchanging Ga6 (1.b8=Q/R/B/S/hccG) <--?
Twin add black Protean Ga6 (1.b8=Q/R/B/S/G)
Twin add black Magic Ga6 (1.b8=Q/R/B/S/G)
Twin add black Uncapturable Ga6 (1.b8=Q/R/B/S/G)

As can be seen above:

1. With a Chameleon Black Grasshopper present, a normal WP is able to promote to both a normal G as well as a Chameleon G.
2. With a Hurdlecolourchanging Black Grasshopper present, a normal WP is able to promote to only a hcc G.
3. In all other cases the WP is able to promote only to a normal G.

In the upcoming v4.91 version, the implementation of "Bul" and "Dob" attributes are following the hcc attribute case, according to the notes by Thomas here (#335).

I suggest that the implementation of Chameleon, HurdleColourChanging, Bul, and Dob be corrected as:

1. If a fairy piece having one of these attributes is present in the diagram, then a normal P can promote to the normal fairy piece NOT having such attributes.
2. A Pawn with a particular attribute can promote to a fairy piece with the same attribute if such a fairy piece (with or without the same attribute) is present in the diagram.
3. Currently Popeye ignores the hcc attribute for non-hopper type pieces and gives a warning. The same can be continued for the "Bul" and "Dob" attributes too.

[thomas-maeder]

Do I understand your point 1 correctly as
If a fairy piece having one of these attributes is present in the diagram, then a normal P can promote to the fairy piece NOT having such attributes as well as to the fairy piece having one or more of these attributes
?
I.e. the hcc case would be changed to 1.b8=Q/R/B/S/G/hccG?
And the Chameleon case would remain unchanged?

[thomas-maeder]

And point 2 would lead to the introduction of hcc pawns, Chameleon pawns etc.?

[nshram]

1. If a fairy piece with attributes is present in the diagram, a normal pawn can promote to the same fairy piece without any attributes only. Only a pawn already having an attribute can promote to the fairy piece with the same attribute.
2. chameleon, hcc, bul, and dob should be treated as attributes applicable to any piece.
3. For chamelon, pawns and Ks are exempt and the chameleon sequence should be defined.
4. hcc, bul, and dob should not be allowed as attributes for non-hopper type pieces. however they should be allowed as attributes for pawns (including pawn-like pieces like dragon), to allow them to potentially promote to hopper type pieces having these attributes.
5. WinChloe does not treat chameleon, hcc, bul and dob as attributes. Due to this, specific pieces with these attributes can only be used if they have been programmed. For example, a bul Rookhopper is not available. Currently, WinChloe has a fixed number each of chameleon pieces, hcc hoppers, and bul and dob hoppers.

[thomas-maeder]

Thanks for the clarifications!

I am reluctant to modify the current default behavior of Popeye for the following reasons:

• Bul/Dob: WinChloe is the reference implementation, and as far as I can tell from the published solutions of many example problems, Popeye's default behavior is consistent with WinChloe's
• hcc: Popeye's default behavior is the reference implementation
• Popeye's behavior in the presence of Bul, Dob and/or hcc hoppers is consistent

This doesn't mean that your suggestions can't be implemented. But as I have stressed above, it shouldn't be the default behavior. They could be activated as some fairy condition or piece attribute.

As for chameleons (NB: I saw one today in the wild! :-) ), Dmitrij Turevski suggested to align Popeye's default behavior with that of Bul/Dob/hcc. This suggestion obviously has some merit, but I'd like to know first how it would affect Popeye's "opinion" on published problems that are generally considered correct.

[thomas-maeder]

As for chameleons...

After further thought, I think that the current behavior is the only one that makes sense (apart from introducing Chameleon pawns).

After all, the presence of a chameleon piece means that all types in the chameleon sequence can be present at some time, so a pawn must be able to promote into all types of that sequence.

[nshram]

Ok. Looks like the weight of past implementations couldn't be overcome!
Still, something to consider for any future implementations of attributes.
WinChloe has implemented more attributes than Popeye.
Need to check if their behaviour is similar.
EDIT: Found one! "Sauterelle à sautoir Einstein". This is again, a hopper-only attribute, like hcc, bul, and dob!
After a non-capturing hop, the hurdle changes as Q-R-B-S-P-any fairy piece that is present.
After a capturing hop, the hurdle changes as P-S-B-R-Q-any fairy piece that is present.
This is also implemented in WInChloe in the same way as chameleon, hcc, bul, and dob.