Re-thinking roll button names

[joesinghaus]

All the roll buttons have "-roll" appended to their names, which seems superfluous. How is

%{ABC|initiative-roll}

any more illuminating than %{ABC|initiative}? Seems to me you could get rid of the suffix. It becomes really weird for repeating roll buttons, e.g.

name="roll_activeskills_active_skill_roll"

which produces the terrible unwieldy

%{ABC|repeating_activeskills_-Abc123_activeskills_active_skill_roll}

activeskill appears THREE times in that expression! Why not

name="roll_roll"

or

name="roll_activeskill"

(i.e. equal to the section name) or something else that makes more sense?

[Bathtor]

Ok, fair enough, I agree that it's ugly.

But why does it matter? I'm not ever using names anyway. They are all autogenerated and completely opaque from my perspective.

If ScalaJS could do proper reflection, I wouldn't be naming things things at all myself and would just use the Scala names, and they would look like com_lkroll_ep_sheet_repeating_activeskills_-Abc123_activeskills_active_skill_roll and I still wouldn't mind.

Ah, the reason that some terms appear multiple times, is because I'm enforcing context name spacing on the field names, so that name-clashes in Roll20 can't happen, but would always cause a compile time issue in Scala first. Basically I'm mapping Scala name spaces in some conservative way onto Roll20.

[joesinghaus]

If someone wants to write token actions referencing these (and say they don't have the API script to generate them once it can do that), they have to write really obscure names. It's not particularly user-friendly. Otherwise, the names don't really matter that much, fair enough.

[Bathtor]

Fair enough, as use cases go.
But I still don't feel it's worth my time to bend over backwards for people too cheap to afford API and/or too lazy to copy-paste long names.
Compile time safety really is the more important thing here, in my opinion.

If I have some time at some point maybe I'll just write a quick external tool to generate pretty much arbitrary macros/token actions from the sheet model, without having to know what the ugly names actually are. I'll do a new low-prio issue for that, so I remember.