This metamagic feat requires the character to choose one energy type when taken, but can be taken multiple times, each time with a different energy type. However, if you have multiples of the feat, and you want to add a spell prepared with the feat, you have no way to select which of your choices you want to use. In a similar vein, the choice is ignored when the spell is referred to by an output token.
Alright, why not rework the feat to use the same CHOOSE:STRING or whatever, and apply one of the choices instead? The difference, the Master Feat is visible on the GUI only, and the displayed Feat is Export only. That leaves the existing characters not broken, and addresses your concern.
Example:
CHOOSE:STRING|Acid|Fire|etc.
(I'm using shorthand here)
ABILITY:FEAT|AUTO|Elemental Spell ~ Acid|PREABILITY:1,CAT=FEAT,Elemental Spell(Acid)
Solves the problem I would think. Or if we want to use the new implementation
CHOOSE:ABILITYSELECTION|FEAT|TYPE=ElementalSpell
I just don't want to have to have a user have four, or eight or whatever iterations of what amounts to being the same feat in a list instead of just the one.
Thoughts?
The first idea might work, but I'm not sure the invisible "subfeats" will actually show up in the metamagic application dialog. I'll have to check that.
The second idea with the new syntax would require that the subfeats are named identically to the original CHOOSE:STRING choices (i.e. just "Cold" etc.), or characters would break anyway, and I wouldn't really want to use these very generic terms as keys for a specialized feat as this.
If we implemented the new method we would intentionally be breaking the Feat as it is. I've already displayed the new syntax. I agree, using the generics for a CHOOSE:ABILITYSELECTION would be a very bad idea. I'm thinking in this case the CHOOSE:STRING with the AUTO:FEAT / ABILITY is a more agreeable solution. It addresses both of our needs - mine for a smaller list and not breaking existing characters, and yours for having something the new Metamagic can handle. Let's do the first implementation, it should work and doesn't break anything.
After brainstorming on IRC, Andrew and I found a new solution which needs recoding of this feat along with little code work (see for that).
New solution:
1) Keep one master feat with a chooser that is selected when the feat is taken. This feat is only visible in the GUI and does not appear in the metamagic chooser due to the change made in CODE-2172.
2) Add new invisible sub-feats, one per choice, that are automatically granted. These feats will show up in the metamagic application chooser.
3) Add a new feat that is only used on export which is also granted automatically.
Implemented as of Subversion revision 20397.