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, Dangerous + 10 × Dreaded + 15 × Zeefaring 700 where it currently just says Dangerous.

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)

Alright, finally managed to investigate some of the finer points around subobject behavior and I think they're what we're looking for.

We're currently representing challenges as Records. For the extensions we want to make, I think we need to switch over to Subobjects.

Subobjects are basically SMW pseudo-pages. They're not a real page, they're a data object that's part of a page but SMW will treat like a page, meaning it can have Properties and other Properties can point to it. Records are built on-top of Subobjects, which means the data relationships won't change much, but Records have some helper syntax we'll be losing.

The big difference is that a Record is restricted to having a fixed set of fields, which is the probably we're butting up against. A subobject, being "just" a page, can have whichever Properties and can also have the same Property multiple times with different values. For example it can have Challenge Against two or three different qualities if needed.

SMW documentation recommends against naming your subobjects; I think we actually need to do that, because we want our Action page to have a Has Challenge property pointing to the challenge. From experimenting, I think only named subobjects can be pointed at by Properties. So an action like Threaten London would create a subobject named A_Player_of_Chess_Challenge, and then #set Has Challenge to "Threaten London#A_Player_of_Chess_Challenge." The created subobject would re-use the existing properties for challenge type and difficulty, more verbosely.

So overall the process looks like this:

1. Re-implement existing functionality with subobjects
   1. Requires changing the definition of Property:Has challenge, a Property used in 5k+ pages. Or, creating a new Property. Maybe I'll do that.
   2. Updating call sites in {{BroadChallenge}} and friends.
   3. Updating uses of Property:Has challenge. The only one I'm aware of is {{Quality}}--are there others?
2. Extend functionality for multi-stat challenges
   1. New parameters on {{Action}}, threaded through Challenge templates
   2. For SMW purposes, do we want a Primary quality and one or more secondaries? Or everything all together? I would lean towards the latter myself, because secondary qualities have a multiplier.
   3. Whatever we do, make sure it does something sensible for {{Quality}}
   4. Update existing content - I suppose there will be less to update if we get this out before Tuesday, but still probably not too much.
3. Extend functionality for Modified By
   1. New SMW properties but the templates don't need new arguments or anything
   2. Unsure what to do about linear vs s-curve modifiers
   3. But since subobjects don't have a set schema, we don't need to figure this out before we start work on the other bits

- PSGarak (talk) 02:51, 29 June 2024 (UTC)

I completely missed this thread until know, but I have been playing around with my own Lua implementation of how it should visually look on staging:; see staging:Template:ComplexChallenge and the changes made in staging:Module:Challenge

> For SMW purposes, do we want a Primary quality and one or more secondaries? Or everything altogether? I would lean towards the latter myself because secondary qualities have a multiplier.

Logically it feels like it ought to be one primary + any secondaries that modify it. There is also the question of how this should interact with dynamic challenges (e.g. the Railway board). In many ways, they function the same. However, I would still say that there is a semantic difference between a challenge whose difficulty level gets modified by qualities and a challenge where the tested quality gets modified by qualities (also because generally speaking you're able to influence the relevant qualities in the second case, but not in the first case).

For the rest the plan looks good to me at a quick glance -- Asarta (talk) 15:34, 29 June 2024 (UTC)