Forum:Simplifying special message parameters in Gain and Loss

Forums: Index > Wiki Updates > Simplifying special message parameters in Gain and Loss

Simplifying special message parameters in Gain and Loss

Edit: Changes are live, see here for the announcement.

Original text:

{{Gain}} and {{Loss}} grew increasingly convoluted during their pre-module lifespan, and in the process of porting to Module:GainLoss I replicated most of their behavior as it was. Less chance of breakage that way; redesign decisions could wait until the module was stable. I've made a few backstage improvements since but the experience for editors has remained basically the same.

I think it's time to simplify the special message parameters. The current implementation is an improvement on the pre-module version, where parameter behavior was inconsistent between templates, and of course vastly superior to the old design of separate templates for every message. However, it still has some issues:

• The module makes assumptions about game logic that are sometimes proven wrong, like the latest Firmament chapter using the "twist in your tale" message for gaining a quality for the first time through a regular CP gain
• The more parameters to juggle, the more difficult adding more special message types becomes (and I know there's at least one message out there that the module doesn't support)
• More parameters also makes it harder to potentially implement automatically displaying quality-specific gain/loss/gone messages via SMW
• Keeping track of which parameters are and aren't compatible can be confusing for editors

I'd like feedback on the following proposal:

• Use the current parameters as keywords for the message parameter to display the associated message. For parameters that take a number, use now or {{{2}}} as you would normally.
  • For example, {{Gain|Watchful|occurrence=1}} would become {{Gain|Watchful|now=1|message=occurrence}}. Unfortunately longer to type.
• Internally, the special messages would use the same logic as message does now with fewer assumptions about how each can be used.
• Deprecate the existing parameters. For page history backwards compatibility, they would still display the current message, but when used add a maintenance category / show an error message in page preview.
  • occurrence and to are straightforward to deprecate.
  • gone and reset are more useful shorthands as they sidestep needing to set a level. We can keep this behavior for convenience. Using these with a nonzero value would return an error.
    • gone also has the even-shorter {{Gone}}, so I'm not worried about the extra typing.
    • reset is less common so convenience is less of a concern. I also suspect a lot of current uses would be obsolesced by implementing SMW gone messages down the road.
  • accomplishment usually implies a level of 1, so we can assume that if no value is given. Some cases would be better handled by SMW gain messages.
  • twist is the most complex. Used with Gain, it usually implies a level of 1 like accomplishment; used with Loss, it works like gone. Only the latter use can eventually support SMW messages.

In an ideal world, we might fully remove to since it's more confusing than relevant, functioning mostly as a pseudo-now for ancient pyramidal tracking qualities. (Even more ideally we'd rename now to to for clarity, but that's way more disruptive.) I don't think this is a high priority though.

Would you find this useful? Horribly inconvenient? Are there other changes you think should be made alongside this? - Optimatum (talk) 23:08, 1 April 2025 (UTC)

Hm. I don't think I like it. It's confusing to have a parameter like message take special flags that it treats differently from ordinary messages, and it would be difficult to handle in code as well. Why not just leave all the existing flags, and take out the incompatibility logic between display flags and effect flags? That is, message, twist, accomplishment, and occurrence are parameters that say what is displayed; {{{2}}}, now, and to are parameters that say how the quality has changed. occurrence is the slightly odd one out, because right now it does both, but it would be pretty simple to convert existing cases of occurrence=VALUE to something like occurrence=yes|now=VALUE, which would be much clearer. gone and reset also do double duty right now, but in a less confusing way; they could keep doing that, but there's no particular reason we need to block someone from doing now=0|gone=yes, or even now=1|gone=yes -- for all we know the game could display that message with a non-zero quality level. Tirerim (talk) 00:36, 2 April 2025 (UTC)

Keeping in mind that we're more familiar with the current setup than many editors, is a parameter that accepts both literal text and shorthands really that much more confusing than a bunch of parameters with subtle differences in behavior and usage? We could instead do two distinct message and special message parameters, but I haven't been able to come up with a name for the latter that's both unambiguous and concise enough to type constantly.

I don't follow your explanation of the two types of parameters, because isn't that basically the other half of what I'm proposing? (Aside from to belonging more to the first category, like occurrence does.) Making the formatting parameters mostly independent of information parameters. Right now message is the only one that doesn't set a number, explicitly or implicitly, but if they're all cosmetic then why not implement them identically? Though I don't think we should allow seemingly-contradictory info unless that actually shows up somewhere.

As for code difficulty, I've already thought about how to implement it and I'm not concerned. Might make a sandbox version in the next few days. Optimatum (talk) 05:53, 2 April 2025 (UTC)

I agree with Tirerim's objection to a single parameter mixing free text and flags. I object aesthetically, and it also makes it harder for newcomers to understand how to use a template by looking at use-sites, or by copy-pasting.

Thinking over the problem last night I came to basically the same solution you did: message for custom text, and something like auto message to consolidate all the flags. I think having those two different message parameters streamlines the interface enough without making it too unexpectedly magical--the main piece of "magic" would be that some values of the special/auto message param change the default value for now.

- PSGarak (talk) 13:35, 2 April 2025 (UTC)

I've settled on special message, with sm as a shorthand. Auto message to me has connotations of the module automatically deciding which message to apply, which would get especially confusing if we add SMW-based change messages. Optimatum (talk) 05:30, 5 April 2025 (UTC)

Got an implementation with separate message and special message parameters up at Module:GainLossTest, with a bunch of test cases at User:Optimatum/Sandbox/Module testing. What do you think? Optimatum (talk) 05:33, 5 April 2025 (UTC)