Forum:Combined Stat Challenges

Forums: Index > Wiki Updates > Combined Stat Challenges

Combined Stat Challenges

So, now that Combined Stat Challenges are officially part of the game, and work somewhat differently than Dynamic Challenges, what work needs to get done to the Wiki as a result? For the moment it looks like we're just using Challenge Info bespoke for each such action, which is certainly passable as an interim solution, but I think a more structured approach is both possible and desirable.

Obviously we'll want some template updates for {{Action}} and downstream dependences like {{ChallengeSection}}. One question is whether we just new parameters to make an auto-populated Challenge Info section like how ModifiedQuality currently work, or something that more closely matches the in-game UI. Could go as far as saying something like Broad, + 10 × + 15 × 700 where it currently just says .

Also wondering how to extended Property:Has challenge and Property:Uses in SMW. My current thought is that modelling a single challenge against multiple stats is possible but might be too convoluted to be worthwhile. But I might want to add a new Use Type to represent challenge modifiers. - PSGarak (talk) 18:58, 21 April 2024 (UTC)

Sorry for the late reply but yeah, we should totally doc these properly, heck even the Modified parameters aren't stored nor are they extendable (if there's more than one it's put into Challenge info). Should be easy to whip up numbered parameter processing in Lua, plus we could even cram them together with a separator (like not have a separate quality, amount and increase). Have an extra challenge type and shove the mods into a record (surely you can have a record in a record?).

If you're up for making the property changes, I'll modify a version of the new planner to accept data from URL params so that we can auto-generate a link to that from the action pages! Wouldn't that be real cool? :D Reminds me, how do you like the new way some quality queries are generated from Ask subpages? (Related post) People brought up that the original full links were way too long and I think this is quite an elegant solution! (Plus the extension opens up many other exciting possibilities!) CarrONoir (talk) 18:15, 22 May 2024 (UTC)

I definitely like the new URLs. The long, query-laden ones were tragic and I just sort of resigned myself to them. Having a clean-ish, practical URL mitigates one of the advantages that Category pages had over queries.

I can do all of the Property set-up if we agree on a data model. Pretty sure you can do a record in a record, but I'm not sure that will effectively handle a challenge having multiple modifications. Like we can extend Property:Has challenge to include fields for modified difficulty and combined stats, but if the challenge is modified by multiple qualities or is combined from 3+ stats that's not something the record can effectively model.

Also challenge modification is not always linear, so I have reservation about including the multiplier in the record, and I'm not sure it's salient--the main purpose of these properties is to to a Quality's page to its uses, and I think it's OK to click through to get the details. Combined challenges are more regular with a fixed linear multiplier, so it's easier to model them with a record in some way.

Note that you don't need Lua to do numbered arguments, we have the Loop extension around with forargs. See e.g. {{Variant table}} which makes exclusive use of that for processing multiple arguments. Or do Lua if you want, I just like keeping stuff in a single language if possible. PSGarak (talk) 02:04, 23 May 2024 (UTC)

We could have a different property for modifications, that's a record with one field linking it to the challenge quality, perhaps? I'm currently a little more interested in having them properly in parameters at least so we could generate that planner link.

I'm aware of loops but MediaWiki development is planning to parallelize parsing and we'll have to give up variables when that happens (see the extension page), so I try not to use them any more than we already do to reduce the potential work of replacing them in the future. It probably won't be an issue for years but it seems wise to futureproof. Lua modules are also more efficient than parser functions. Replacing variable uses around the wiki is one of the big projects I have on the list. CarrONoir (talk) 20:42, 23 May 2024 (UTC)

Well I'm certain I haven't made that project easier for you!

While it's hard for a record to point to several other records, it seems more feasible for a record to be pointed from several other records. So I'm going to fiddle around with that data model when I get some time, perhaps this weekend. PSGarak (talk) 02:35, 24 May 2024 (UTC)

Quick update: Currently investigating Subobjects as an option. They can handle repeated properties, i.e. one-to-many relationship so a Challenge can be Modified By more than one Property. But, despite Records being built on top of Subobjects they work a bit differently so I need to check whether the change can be made in-place. PSGarak (talk) 01:02, 25 May 2024 (UTC)