User talk:PSGarak

Welcome

Hi, welcome to Fallen London Wiki! Thanks for your edit to the CommentStreams:8deda8159ebde340029511b9930b91c7 page.

To find out more about how to contribute to the wiki, please visit Editing Guidelines. Check out the Quicklist page for a quick reference to rewards and icons.

Happy Editing!

P.S. Please leave a message on my talk page if I can help with anything else! -- Alan (talk) 16:51, 22 March 2021

Wiki Feature Request: Semantic MediaWiki

Hi all,

I would like to recommend the Semantic MediaWiki (SMW) extension for use on this site. I have some proposals for how we can use it and the benefits it would provide.

Extension info: https://www.semantic-mediawiki.org/wiki/Semantic_MediaWiki

What it does

tl;dr Property graphs!

SMW adds some features to the data model for the wiki. There are three main features this brings:

1. Define relationships that pages can have with each other. "Vanilla" MW basically only has the "member-of-category" relationship. SMW makes this extendable.
2. Pages can have properties or attributes defined in wikitext.
3. Pages can include content populated from queries against the above.

Proposed Use Cases

Tame the combinatorial explosion of categories

Any given Quality can have several Categories all to itself: Use, Challenge, Text Use, Source, Loss, etc. Despite having so many categories, there are still limits on expressivity (e.g. Locks vs Unlocks). And because each category is bespoke, there are no automatic relations between categories, which limits discoverability. E.g. the page for a Quality X does not include any way to discover the X Text Uses category.

SMW would let us represent this structure formally, and make use of it better. So instead of a page belonging to the "Brawling with Dockers Text Uses" category page, it would have a "Text Uses" link to the Brawling with Dockers page. And the "Text Uses" would universally be a sub-property of uses, rather than having to specify that relation for each "X Text Uses" category.

De-duplicate Data Stores

The IL and ItemList modules duplicate content that's already on the page, because pages can't have attributes. SMW resolves that, letting other pages query content directly rather than needing to manually keep a second database up to date. I probably don't need to belabor the point that having to do everything twice in two different places is burdensome.

Simplify Code for Calculators

A good fraction of the thorny Lua code on the Wiki site seems to be for filtering and sorting tables of items for the calculators. It's not strictly a benefit to be replacing one niche language for an even more-obscure one, but my gut is that using a data query language for querying the data is probably simpler and more easily maintained.

Better Data Presentation

Basically every current use of the "CategoryTree" display is an opportunity to provide more info to readers of the wiki. Properties can be extended with extra data, so e.g. the quantity for Source or Loss properties, or the Difficulty for challenges. Supplementing CategoryTree-type lists with this data would make things much more useful.

Summary

If other editors are interested in this, I'm willing to take point on figuring out how to put it into practice. I'm a sucker for graph datastores, and I've already spent some time daydreaming about what this might look like for Fallen London. Most or all of this can be accomplished with under-the-hood modifications to the existing templates that we use for everything. I'm happy to discuss details or trade-offs before committing to anything.

Any changes to existing functionality would be shown in a sandbox and vetted before being rolled out. I'm not sure what the performance impacts might be, but my naive understanding is that we might actually get a benefit out of it. We currently make heavy use of CategoryTree, which is an "expensive" function, whereas SMW seems to be optimized for the types of things we try to make CategoryTree do. PSGarak (talk) 19:08, 22 March 2021 (UTC)

Technical Side

This sounds like a worthwhile endeavour! Though it would require a lot of work, haha.

I'm uncertain about the resource consumption of SMW – I'll put it on dev.fallenlondon.wiki in the next few days (and will reply when I do) so editors can play with it if they'd like.

I have seen Cargo mentioned as an alternative data storage system, though I haven't done the necessary research into it. Alan (talk) 20:07, 22 March 2021 (UTC)

I took a peek at the dev site and saw that it's installed. Mind if I tinker? I'll hold off on updating universal templates for a while, although I would be indebted if you could enable the Attachment links property, which could hopefully replace Module:IL/images. PSGarak (talk) 17:31, 26 March 2021 (UTC)

Hi! Yes, feel free! I put it on there a day or two ago, but hadn't gotten around to letting you know. Sorry about that!

Be aware that jobs aren't running on dev yet, though I'll enable them soon.

I'll take a look at enabling that property, though I have something else in the works that could supplant it (dev:User:Alan/Template:Test and dev:Module:Alan/test, which searches the page rather than referring to IL/images).

This is yet another thing for which I had been meaning to write a blog post but hadn't gotten around to (orz). Alan (talk) 17:47, 26 March 2021 (UTC)

Pulling in the whole article text just to find the image name? Give me a day or two, I'd like to see if I can replace that with a property look-up instead. PSGarak (talk) 17:56, 26 March 2021 (UTC)

Welcome to Fallen London Wiki!

Hi, I'm an admin for the Fallen London Wiki community. Welcome and thank you for your edit to Bessemer Steel Ingot!

If you need help getting started, check out our help pages or contact me or another admin here.

Please have a look at our Editing Guidelines for some important information on editing the wiki.

Enjoy your time at Fallen London Wiki!
FANDOM (talk) 19:23, April 12, 2020 (UTC)

Search the Cloud 2

Hi, I noticed tha you removed the standard success from the branch and left only the miniature ship one. Are you confident that is accurate? This suggests that *every* time you manage to get airs of parabola to 95+ you are guaranteed a miniature air ship. I haven't been lucky myself but report from Discord suggest that's not the case and the miniature ship is a rare result even if you have 95+, with steel being the normal success...
Mikey thinkin (talk) 19:39, May 3, 2020 (UTC)

Faction Templates

Hi,

I've recently created Templates for the Faction pages. As there however was some discussion about how they should look and their potential impact I've decided to put it up to the Community how they should look at User blog:Asarta/Faction Templates. Any contributions you could make would be greatly appreciated!

Asarta
Asarta (talk) 15:07, July 5, 2020 (UTC)

Lacre

apparently I'm not the first to make that mistake

Gave me a laugh :D
Cactusorange (talk) 21:24, September 19, 2020 (UTC)

Yeah, I felt a little silly when I saw the revision history. 
PSGarak (talk) 13:05, September 21, 2020 (UTC)

I'm pretty sure I did something very similar on another page too. It happens
Cactusorange (talk) 14:54, September 21, 2020 (UTC)

Welp, looks like someone’s actually doing it.
PSGarak (talk) 04:05, December 9, 2020 (UTC)

This sounds like it’s about converting ToL to Discrete but between this and the aforementioned revision history I’m now unsure if I was mistaken to do so or if y’all just didn’t want to deal with all of the edits that required.
Mzs42 (talk) 13:28, December 9, 2020 (UTC)

It’s the latter! I was trying to do some maintenance, but decided that was too much to bite off at once. And at the time I also wasn’t 100% sure there were no change points, and didn’t have the opportunity to test. But I’m glad someone’s doing it now that we’re in the holiday season!
PSGarak (talk) 15:01, December 9, 2020 (UTC)

Oh, good. Phew.

If you know of any other needed cleanups that are being put off because they require a bunch of edits, I’d love to be informed. I occasionally get in a mood where I just want to do that sort of work for a little bit and it’s nice when I have a useful outlet for it.
Mzs42 (talk) 21:53, December 9, 2020 (UTC)

When I get that type of mood, I go to Category:Site_maintenance to find something to use it on.
PSGarak (talk) 01:33, December 10, 2020 (UTC)

Found a Way to Transclude Table in Between Fields of Action Template

Firstly, thanks for your work on Diving in the Magistracy page. That’s how I discovered the following.

I noticed that if the programmer makes a call for a template in between in the fields of another template, that called template will be displayed before the page returns to processing those fields.

You can see this in Persuade His Amused Lordship.
Rostygold (talk) 08:33, October 21, 2020 (UTC)

You mean the table in the Challenge Information? That’s not in-between fields, it’s just part of the Challenge Information field. Arguments to a Template field are allowed to have multiple lines, and the linebreaks are included as part of the arguments. (Leading & trailing newlines are stripped from named parameters, but not positional parameters, and parser functions may behave different.)

The actual issue with including tables inside templates is the pipe character. A table uses pipes to delimit cells, but if a table is defined inside a template, the pipes are treated as delimiting new arguments to the template rather than delimiting table cells. You can solve that by either using the {{!}} template to generate all of your pipe characters, or transcluding the table. I’ve been working on a template to build all the table bits, but as you found out, you can also just transclude a whole table, which never occurred to me. It sure cleans up the page code a fair bit.
PSGarak (talk) 17:08, October 21, 2020 (UTC)

It doesn’t work on the description field though - likely due to the scripts on counting characters causing problems.
Rostygold (talk) 01:55, October 22, 2020 (UTC)

To elaborate, I can’t place template calls before or after the description field. I think that the QuoteSummary template is preventing this from happening, specifically the lines that call the Truncate templates.
Rostygold (talk) 02:13, October 22, 2020 (UTC)

Speak with Beatrice about Furnace

I’m not sure the text can vary with Discovered: the Need for Hellworms, since if I’m reading the wiki right you can get that quality but still decide to lay the rails through Parabola. So it seems more likely to me that it varies with just the Train through Parabola quality at 0 or 1.
Cactusorange (talk) 21:11, November 15, 2020 (UTC)

Is that actually true? I assumed they were mutually exclusive but I chose the Parabolan route from the get-go, so I can’t confirm for sure.

The Wiki may not be 100% reliable here, since the Hellworms quality is hidden. If the Parabolan route is locked by it, it may not be recorded. We should seek confirmation from a player who took that route.
PSGarak (talk) 02:27, November 16, 2020 (UTC)

I took the Hellworms route. While I didn’t look at any hidden qualities myself I’m fairly confident the wiki is right on this – that there’s a hidden quality that unlocks the Hellworms plan when you try to go straight up the mountain. After I tried going up the mountain and that choice was revealed as impossible, I had the choice of Parabola or Hellworms.
Cactusorange (talk) 02:47, November 16, 2020 (UTC)

(It might be possible that going through with the Parabola route removes the Hellworms quality, but I don’t see any reason it would.)
Cactusorange (talk) 03:00, November 16, 2020 (UTC)

If you’ve actually seen it, then I’ll defer to your experience. The idea that they were mutually exclusive was just an assumption on my part.
PSGarak (talk) 03:58, November 16, 2020 (UTC)

No worries! I’ve reverted the change (but added links to the two relevant paths).
Cactusorange (talk) 17:46, November 16, 2020 (UTC)

Courier Table

It’s not London airs, it’s a hidden airs which doesn’t seem to be used anywhere else. So I’m not sure if your added entry has got the right numbers.
Cactusorange (talk) 13:26, December 20, 2020 (UTC)

That would explain why my Airs of London was 16, and I was seeing text listed for Airs 35. I’ll fire up the old network tab and see what’s going on.

[edit] That definitely looks like a quality that was meant to stay hidden. But it has fitting art, which is more than I can for some other hidden Airs values.
PSGarak (talk) 18:45, December 20, 2020 (UTC)

Single pages versus multiple pages

Hi, I saw that you changed https://fallenlondon.fandom.com/wiki/Lay_track_through_hilly_land_and_keep_your_workforce_well_fed_(After_Stoppage)?redirect=no# from an independent page into a redirect. Why did you do this? Two separate pages seems a lot clearer to me.
Asarta (talk) 08:00, January 25, 2021 (UTC)

The Next Stretch of Track page was too long. I was driven to make the change because we finally started getting template errors, but I’ve been dissatisfied with that page for a little while now. I just feel like there’s too many pages with content that’s 90% the same.

Personally I think it’s more clear, because the information I’m usually interested in is the comparison between similar options. And a single page makes it easier to find which information applies to me, because the difference is in the content itself rather than trying to find the relevant page. But if you think the separate pages are more clear, I’m open to persuasion.

I’m hesitant about merging the similar pages through grassland, because the text variation is complicated. And that means we’re not consistent between the hills & plains. But we’re inconsistent elsewhere as well: The tracks to Ealing use consolidated pages, and the tracks to Jericho do not.
PSGarak (talk) 14:32, January 25, 2021 (UTC)

Yeah the original reason I asked was because someone over on Discord got confused because they only read the titles, not the rest of the content and therefore thought that Hills wouldn’t trigger the strike. I’m also not really sure of an alternative however and I do like the consolidated pages. Only other option I see is splitting the Next strecth of Track into multiple pages but that wouldn’t work well either I think
Asarta (talk) 14:39, January 25, 2021 (UTC)

Refactoring the Best in Slot Calculator

Thanks for cleaning up the template! I really appreciate it. I took a look earlier today but got stuck. Evidently I need to brush up on parser functions. 😅
Alanhuang122 (talk) 03:27, March 9, 2021 (UTC)

I hope you don’t have to! Working with those features feels needlessly complex, workarounds stacked three layers deep to deal with issues caused by the previous workarounds. The root issue is that wikitext isn’t evaluated in an XML tag, which the forms use.

But it was all worth it for the satisfaction of a changelog that dropped the page size by 75%.
PSGarak (talk) 16:34, March 9, 2021 (UTC)

Errors in Module:Item when adding new Zeefaring qualities

Hi PSGarak,
It was noted today that trying to add the new Zeefaring qualities to the various ship pages is resulting in a Lua error in Module:Item; see Special:PermanentLink/377150 for an example. As this appears to be caused by SMW code could you look into why its breaking? Thanks in advance, --Asarta (talk) 13:41, 25 May 2021 (UTC)

The issue is not occurring now, even though I didn't change anything.

The problem seems to originate in the effect-parsing code, not in the SMW code itself, although the SMW code doesn't handle that error condition gracefully. The preceding code has a regular expression Lua Pattern that tries to pull the link URL from the expanded {{IL}} code. When the link points to page that doesn't exist yet, the link has a query parameter that confused the pattern. (Actually, the problem might be that the text link has the parameter but the image link does not, the pattern expects the two links to be the same.)

I'll update the SMW code to check for nils and fail gracefully. PSGarak (talk) 14:09, 25 May 2021 (UTC)

The issue no longer occurring may be my fault - I added IL calls for Zeefaring and Luxurious to my sandbox page, which I then purged. After purging both of these, the issue stopped occurring (also, before the purges both of these calls used the old fallback method). Sorry for any confusion. 34Witches (talk) 14:14, 25 May 2021 (UTC)

Thanks for adding the sanity checks for the smw calls in Module:Item. But as noted the real issue was that Module:Item failed to correctly parse the new effects from the expanded "IL" template. Any idea why and how to solve fully? Was this just because the Effect parameter was added before IL was updated with the new qualities' image files? Adnoam (talk) 14:19, 25 May 2021 (UTC)

It's because the Effect parameter named a page that doesn't exist yet. If the page exists, everything is fine (regardless of the contents of that page and whether it has an icon).

The Effect parameter expects IL to expand to something like this:

[[File:___|link=Quality]] [[Quality]]

In particular, it expects that "Quality" will be the same in both parts (the pattern matches a previous capture group). When the quality doesn't exist, then the link becomes a redlink, and the expanded IL template looks like this:

[[File:____|link=Quality]] [[Quality/edit?redlink=1]]

The string "Quality" is not the same string as "Quality/edit?redlink=1", causing the pattern to fail to match. PSGarak (talk) 14:28, 25 May 2021 (UTC)

Got it, thanks. We can of course improve the pattern there to recognize this case. Got any tip on how to sanely debug this? (i.e. see in real time how the expanded Effects fields look in the module code?) Adnoam (talk) 14:41, 25 May 2021 (UTC)

I've seen reference in the Scribunto docs to a "Debug console," although I never found it before. It turns out it's the funny-looking box underneath the "Save changes" button when you're editing a Module. I always ignored the text box there because it looked read-only to me, but it turns out it's a full-blown Lua REPL! Use the function mw.log to print to console.

I'll also mention the nuclear option, which is changing how Effects are passed to the Item template. It's a little odd in the first place that editors are expected to wrap things in IL, and then we un-wrap IL to find what they originally typed. PSGarak (talk) 15:10, 25 May 2021 (UTC)

Yes, I've been using the debug console. Problem is that it seems to be mostly good for standalone code sequences. So I can't use it to see how the expanded IL template looks to the module if the expansion occurs before the module is called.

As for Changing how effects are passed, that's a completely different change which will effect thousands of pages. Tricky to plan. Adnoam (talk) 15:35, 25 May 2021 (UTC)

You can ask Lua to expand the Template call. I'm honestly a little surprised this works, since I was not expecting a "real" frame object, but it looks to me like it's generating the right stuff.

mw.log(mw.getCurrentFrame():expandTemplate{title = "IL", args = {"Not a Real Item"}})

Another option is writing the Template call on a sandbox page, then putting "?action=raw&templates=expand" at the end of the URL, which will give you the expanded wikitext. Then you can copy-paste into the debug console. However I feel like this doesn't always make category links show up? PSGarak (talk) 17:00, 25 May 2021 (UTC)

Variant table: wiki markup vs <table>

I've been playing around with various templates, experimenting with switching some of them from using wiki markup to using HTML for particular parts. {{Variant table}} wasn't initially one that I was looking at, but I took a closer look after some issues were pointed out to me. After some experimentation and testing, I'm pretty sure that we should be using <table> rather than wiki markup tables in {{Variant table}}. I've laid out a demo with far too much explanation at User:Mzs/Variant table if you're interested in specifics.

I'm ready to apply the change to {{Variant table}}, but first I wanted to check in to see whether you're aware of any reason I shouldn't or anything that might break or be worse off after such a change? I assume you used wiki markup instead of <table> because wiki markup is the more reasonable default starting point unless problems arise, but I'd rather ask you to confirm rather than just act based on that assumption.

Thanks! mzs (talk) 19:53, 24 June 2021 (UTC)

No objections from me. Your assumption is correct: I assumed wiki markup was the "right" way to do things and generated the same mark-up and raw HTML, so I didn't explore alternative styles. I was mildly aware of some of the whitspace issues, but assumed they were fundamental to MediaWiki rather than specific to using wiki mark-up.

I can't think of any particular reason why HTML tables might break anything, but I also wasn't aware of the formatting issues that wiki tables create. One thing I would pay attention to is the wrapping behavior on over-long header names, especially long quality names. Another thing to pay attention to is what the table looks like if {{Truncate}} adds the warning about too-long text, although since it's an error condition I think it's ok if it's ugly.

Other formatting issues that I've noticed include how the width changes when the table is collapsed, and sometimes the "Expand" link scrunches up header text. I don't know of HTML tables can address that, either directly or giving better tools for fiddling with stuff.

Unrelated: The editor seems to really not like the code in your comment, and that makes it hard to post a reply. PSGarak (talk) 20:38, 24 June 2021 (UTC)

Looks like the comment magic didn't like me using <nowiki> in the section title. I suppose I shouldn't be surprised by that.

You're very nearly correct that the markup-generated HTML is the same as the HTML created by directly using HTML. The only meaningful difference in this case is that mediawiki requires {| to start on a newline and does not remove that newline from the output. If we prepended an extra newline before every <table>, the output would be basically identical.

That also means that all the other behaviours you mention are unchanged, for better or for worse. The collapsible stuff comes from a mediawiki module and isn't really fixable from a template or wiki page. The good news there is that I've already hacked that module for our wiki, so more local changes shouldn't be a big deal. The width change issue might be fixable, but I need to do some cross-browser testing since the solution isn't fully supported by all browsers. The scrunching issue is definitely fixable but I'll need to make sure either that it doesn't break anything else or that the increased spacing is optional. If there's anything else collapsible-related (not necessarily just for Variant tables) you think I should look into, let me know. With our ad hoc "release" process, it's better for me to group changes if I can. mzs (talk) 21:47, 24 June 2021 (UTC)

Template editor granted

I created the template editor group. This group has permission to edit previously fully-protected templates. I know you've edited highly-used templates in the past, so I've added you as a member. Alan (talk) 06:01, 30 June 2021 (UTC)

World Quality Info/Source of Truth

I noticed you're doing work on World Quality presentation and requirements; thanks for that!

At Asarta's prodding, I created User:Alan/World Qualities, which auto-updates the value of World Qualities that exist on the wiki, in a form suitable for Labelled Section Transclusion.

Setting up an automated process to update WQs was on my to-do list for a while, and I was persuaded to centralise updates over having each WQ page be its source of truth to avoid cluttering the edit history of the WQ pages. (though this route doesn't leave a history of changes on the pages in question, which might be undesirable; I might change it, since I'm not committed to this route yet)

Automatically pulling values and last modified timestamps and setting SMW properties in the WQ template is also something that I'm planning to do but haven't gotten around to yet. Alan (talk) 18:32, 30 September 2021 (UTC)

That's excellent news. I'm in the middle of writing up a blog post on what I'm working on; this invalidates about half of it, but in a good way. The major down-side of the route I was talking was some extra work on the maintenance side. Auto-updating values should alleviate that.

While there's a bit of duplication of effort, I think there's benefit to having the auto-updates plus the SMW approach. The values on that page are a little raw--most of them are just numeric values. Each World Quality page could use a #switch to decide how its own values should appear, which can then be set in SMW properties for direct consumption. PSGarak (talk) 18:43, 30 September 2021 (UTC)

> Each World Quality page could use a #switch to decide how its own values should appear, which can then be set in SMW properties for direct consumption.

Would you be envisioning something like:
{{World Quality |Current Value = {{#switch: <map>}} |[…] }} ? If so, it might make sense to perhaps specify a map between levels and QLDs within the template (LevelX, QLDX, e.g., like EffectsX or OptionX), to ease the task of setting up WQs for editors.

The method I'm using for WQs, uh, only gives me numeric values, so the ability to map to displayed values is certainly a must. I very much approve of this approach, broadly. Alan (talk) 18:53, 30 September 2021 (UTC)

Yes, I was initially thinking of a bare #switch statement in the page code. But your suggestion is a substantial improvement.

Blog post is up, and an example of doing fancy things with it is over at The Smaller Stalls. PSGarak (talk) 19:00, 30 September 2021 (UTC)

A handful of comments on the World Qualities page.

1. Will it always live in your user space, or will there be a permanent location at some point? Feels a little odd having templates point to user pages.
2. The Rat Season: seems to be missing
3. Do we have a record of historical values? Mapping numbers to names takes some guesswork.
4. The Rat Market (Quality) is a funny special case, because the name of the in-game quality isn't the same as the name of the wiki page. We can handle this in the quality page, but is it easy or not to handle it on whatever generates the World Quality page itself?

PSGarak (talk) 13:34, 1 October 2021 (UTC)

Yeah The Rat Market is annoying, because all variants are plausible search topics. I've already moved every other discrepancy I think, but I'm not sure if moving here is the best option. --Asarta (talk) 06:29, 2 October 2021 (UTC)

Apologies; didn't realise you'd replied until Asarta commented.

1. Eventually I plan to move it, though I'm not sure where it'd best fit. Template:World Quality Values, perhaps?
2. It's because the Quality name is The Rat-Season: hyphenated - I've moved the quality page and replaced links.
3. Unfortunately, no; I only started tracking these things recently.
4. Not particularly easy to handle (would require me to edit the script to add special cases); I think it's just easier to use the {{{Name}}} parameter I added to the WQ template. Alan (talk) 07:24, 2 October 2021 (UTC)

Twelve? The current rat-season is twelve? That would mean at least fourteen distinct seasons, mechanically more likely to be 15 or 18.

Not sure where I would put the page, honestly. Not even sure what the best Namespace would be, I almost want it to live in Special:. Template doesn't make sense to me because it's not intended to be used directly a Template call, although I could see it as a sub-page of a template. Perhaps its own article page, or a subpage of Category:World Qualities. PSGarak (talk) 18:28, 2 October 2021 (UTC)

Actually only 12, I think that number was confirmed on Discord. And yes the namespace is a thing. It could perhaps go under {{World Quality}}? Say Template:World Quality/data --Asarta (talk) 12:12, 3 October 2021 (UTC)

The unlock qualities are displayed as if Scitter-Scatter and Dimmest-Dark are higher than Kifer-Caitiff. But I suppose they could only use values 1-12, but give alias to values -1 through 14 to give the appearance of true wrapping.

I was initially ambivalent but after some thought I've come around to thinking sub-page of {{World Quality}} makes the most sense. The idea being that World Quality itself is the only direct consumer of the raw data, and everything else uses 'clean' version of the data processed and surfaced by World Quality. PSGarak (talk) 18:16, 3 October 2021 (UTC)

After two rounds of crab, I've come to the realisation that there are a few significant drawbacks to the approach of centralising WQ values.

1. Updates to the centralised page propagate to all pages that refer to WQs and trigger reparsing. This becomes problematic when there's a world quality that updates every minute and thus Assembling a Skeleton (Guide) is reparsed every minute,
2. It's more difficult to assess when a given world quality has changed - any change to any world quality causes an edit to the centralised page. If someone were to want to track historical changes to a single world quality, they would have to pull every revision of the centralised page and parse through each one to figure out which revisions were changes to the world quality in question.

I'm now leaning more towards having world quality pages be the source of truth for their current value. I wanted to run the notion past you to see if you could spot any issues before I move forward with this change.

I seem to recall some uncertainty surrounding SMW's propagation of changes, though I'll try to suss out any issues before changing things for real. Alan (talk) 01:41, 28 November 2021 (UTC)

I think the Bone Market guide is updating because the {{World Qualities Box}} template includes a direct dependency to User:Alan/World Qualities for the revision timestamp. Were you seeing similar effects on pages that use World Qualities without that template? E.g. The Trifling Diplomat, or The Rat Market (Guide)/Tables? (The main page for The Rat Market (Guide) includes the infobox so it would have had the same issue, but the Tables only depend on SMW properties.)

With the current strategy there's no getting around a re-parse for the page for each World Quality. But if the World Quality value is the same, the change propagation ought to stop there. It updates the database, and the database marks pages with invalid caches. Perhaps check that this property is enabled?

I agree with what you're saying about revision history. Having a historical record of values might be nice. PSGarak (talk) 03:32, 28 November 2021 (UTC)

Good point - I didn't realise that there wasn't a direct dependency between the WQ templates and the centralised page, but rather that SMW mediates change propagation. That's very neat, and indeed non-material edits to the centralised page only update pages that rely on the timestamps.

The config option in question is indeed enabled, and it seems to be more reliable than I had thought. Cool! I'll prepare to decentralise world quality data in earnest. Alan (talk) 07:13, 28 November 2021 (UTC)

Might I ask what approach you're planning on taking? I'm guessing the simplest is that a bot edits the template arguments on the quality page itself. Another approach would be to have a "History" sub-page. So e.g. Direction of the Rat-Wind: would have a page Direction_of_the_Rat-Wind:/History with an append-only of historical values & timestamps. Then the main quality page could transclude the most recent value (and perhaps a timestamp). This would keep the history-of-values separate from other changes or edits to the page in question. Plus we could back-fill some known history. PSGarak (talk) 18:34, 28 November 2021 (UTC)

I was planning on doing bot edits to the quality page directly, yes, but having a History subpage gives us the best of both worlds, so to speak. The Current value text in {{Item}} could link to the subpage and it'd be easy to parse. Thanks for the suggestion! Any thoughts on a preferred format, or just "pick one and stick with it"? Alan (talk) 22:53, 28 November 2021 (UTC)

I don't have strong opinions on formats, if there are specific reasons to prefer one them I'm not aware of them. Ideally the current/latest value is represented in a way that's trivial to grab, without having to do processing in the template (i.e. no taking max over timestamps). PSGarak (talk) 00:39, 29 November 2021 (UTC)

This reply is as much for documentation's sake as communication's sake.

I've updated {{World Quality}} to transclude the Current Value and Last Updated sections from the page's History subpage. My process has been modified to update these sections on the History subpage, as well.

Currently, the History subpage has values that are useful for machine parsing, but less so for human parsing (single line break between values; MediaWiki displays them without line breaks); I might go through and change this tomorrow.

The biggest test will be whether the Bone Market World Qualities update properly tomorrow. Alan (talk) 04:36, 30 November 2021 (UTC)

I checked about a half-hour after the update this morning, and I had to click the "purge" button on Bone Market Fluctuations: to force the new value to show up. But I also wasn't logged in at the time, and I know logged-out accounts hit caching issues more frequently. After purging, everything went fine (aside from not knowing the Boring Midnighter is buyer #4).

On an unrelated note, perhaps using /History as the suffix wasn't the wisest suggestion, since the edit history is accessed through /history. I had Occasional Buyer:/history in my browser history, and accessing Occasional Buyer:/History was actually really hard. If you do decide to make the list of histories human-readable, perhaps we could add a link to the template. PSGarak (talk) 17:27, 30 November 2021 (UTC)

Using SMW for a graph of story branches

Hi, just to dump my thoughts somewhere, what I would eventually love to have is something similar to a CategoryTree, but with stories and categories. That is, I would love to provide, say, a category as an input, and it would give me a graph of all stories available in that category, ideally also checked against whether they are retired or not. I assume we would use the "From Story" parameter for an appropriate connection. Do you have a good idea on how to model the properties for the least server load (if that's a concern)? -- RagCall (talk) 09:40, 29 November 2021 (UTC)

Of the different ways I can think of modeling this, I don't think the performance characteristics are very different. The important thing is to try and get all of the info you need in a single query, rather than recursive queries.

I do think that should a widely-deployed property should be configured as a "Fixed property," which you'll need to talk to Alan about setting that up. If performance is still a concern after that, then you can look into setting up Concepts for the most common or largest categories.

Using the From parameter is one option, but that's not always reliable becomes sometimes it's free text. Right now the wiki templates have links in both directions between a card/storylet and its actions: From the action to the storylet in the From parameter, and from the storylet to its actions in the OptionN parameters or free-standing {{Options}} calls. My gut is that the latter is slightly more reliable to add a property to.

In either case there will need to be some logic in the template to make sure the property is only attached to card & storylet pages, not when transcluded via {{Embed}}.

According to SMW documentation, the server often works harder to display results than to fetch results. A table shouldn't be too difficult, but if you want something actually graph-looking you might look into Lua/Semantic Scribunto, or one of the result-format extensions for SMW. PSGarak (talk) 14:54, 29 November 2021 (UTC)

Baffling ItemList bug

Rahv pointed out a strange issue with ItemList - both Honed Ushanka and The Swan Bride's Mask claim that they're strict best-in-slot for KT. However, when I try to debug the Item module, the debug output insists that they're (correctly) shared BiS. I've added a lot of comment logging to Module:Alan/Test (called by User:Alan/Template:Test - difference from current revision of Module:Item is here) and it similarly insists that there's only 0 or 1 of a given item matching the category/effect parameters for that enhancement level.

Looking at things more closely, it seems things are perhaps being extremely strange - User:Alan/Sandbox has completely incorrect qualifiers for the Honed Ushanka effects (in case this is a transient issue, here is a screenshot). I have no idea what's going on here. Alan (talk) 01:51, 6 December 2021 (UTC)

Oh man, the BiS stuff. That logic is a thorny nest of exceptions, special cases, and working at things backwards. That piece of code tended to have some bugs even before SMW, although in this case it's probably my update.

So I worked back through the logic, and here's what I think might be happening. One of the changes I made was that find_minmax always tries to exclude its own page from the query. That is, on the page for the Honed Ushanka, the queries executed to find the maxes will explicitly exclude the honed Ushanka. (This is the "self" argument.) This is partly a logic update and partly quality control--SMW is non-deterministic about whether properties set on a page will be included in queries executed from that page.

I think maybe other pieces of logic weren't updated to include that? There's some stuff checking whether count >= maxvalues or count > 1, and maybe the comparison should be strict, or the logic should be count > 0. If I'm right that this the cause of the issue, then the problem manifests in particular when there are exactly two items that are shared BiS, which is the case for the Ushanka and Swan Bride.

No idea what's going on with the sandbox page. Maybe the self-exclusion is causing issues? It's very odd. In any case, the existence of that page will affect BiS displays on the Mask & Ushanka, as it is also recorded as a KT Hat: see link below for SMW query of KT hats.

Honed Ushanka
The Swan Bride's Mask

Actually come to think of it, I could filter user pages out of ItemList results. But one thing at a time.

[edit] On staging, I changed the two instances of count > 1 to count > 0. Compare A Crooked Cross on prod vs stage. Shadowy and Persuasive are both shared with 1 other profession item each, and Mithridacy is shared with a mood. PSGarak (talk) 02:53, 6 December 2021 (UTC)

PSGarak, how does your change work? The function "find_minmax()" in Module:ItemList does not receive any 4th argument (it's just: p.find_minmax(class, quality, minmax)). So when Module:Item calls this function and now passes "name" as an argument - it should do nothing, right?

EDIT: OK, I *think* I got it: find_minmax() indeed ignores the "name" argument now being passed to it by Module:Item. *BUT*, it always calls "fetch_items_class_quality()" with the special "self" argument, which causes *that* function to try and figure out from which page it was originally called, using "getCurrentFrame()" and looking for "#var:item". This is really messy, and makes the module code highly dependent on the internal workings of other templates/modules. Adnoam (talk) 08:05, 6 December 2021 (UTC)

Yeah, adding the "self" param was a last-minute thing. It's more robust to pass along that parameter, but I was hesitant to change signatures of the functions in-between.

What really should happen is that fetch_items_class_quality should take a more flexible optional parameter that lets callers add more restrictions. Right now it's effectively an enum, and then too much logic lives inside fetch_items_c_q. It might be the only way for that to happen is to just have the caller pass in SMW query syntax. I'm not in love with that, because it doesn't encapsulate SMW as well, but it's the most flexible approach. Then find_minmax can be responsible for inserting !item. PSGarak (talk) 15:14, 6 December 2021 (UTC)

Update has been pushed to Module:Item and Module:ItemList.

• In Item, effects receives a name parameter from {{Item}} as before, and passes it to bis_msg
• In Item, bis_msg has updated signature to receive name parameter, and pass that along to find_minmax
• In ItemList, find_minmax has updated signature to receive name parameter. This function is now responsible for turning the name into SMW syntax for excluding from fetch call.
• In ItemList, fetch_items_class_quality has been renamed fetch_items, and the "options" enum has been split into a neg flag in the third argument, and an extra restrictions in the fourth param.

PSGarak (talk) 21:14, 6 December 2021 (UTC)

Looks fine to me. Thanks. Adnoam (talk) 08:57, 7 December 2021 (UTC)

Another Modul:ItemList question - line sorting

Hi - another module question, regarding the function compare_lines():

This function gets two "lines" of items, and compares them - quality by quality - to see which should be displayed first. It goes over all qualities of item 'a' (already sorted by significance), and compares that quality's value to the corresponding quality's value of item 'b'. So far so good. But, if none of these values are larger than the other, then in lines 429-432, the function compares the qualities' *names* (and more than that: backwards - so that if the values are the same, the qualities' names are compared with a reverse lexicographical sort). Why?

From a naive reading of the code, it seems to me that this means that if one item's top quality is "Dangerous +5", and the other's top quality is "Watchful +5" (equivalent values), this means that the first item will always be sorted first (based on the quality name comparison of lines 429-432), even if item a's next quality is "Shadowy +1", and item b has the higher "Shadowy +4".

EDIT: example: in Companions#Dangerous, the Double-Headed Terror Bird (+7, +5, +3, +1) should have come before the Thoroughly Experienced Gondolier (+7, +5, +1). Adnoam (talk) 09:56, 6 December 2021 (UTC)

I touched the display-related code as little as possible, and I don't think I modified compare_lines at all. If it's doing something different now than what it did before, I could try to take a look at it. From the history, it looks like the function itself hasn't changed since June 2020. PSGarak (talk) 14:46, 6 December 2021 (UTC)

I have no idea how and when this was changed (didn't claim it was your change), but it's definitely not the way I coded it originally :-)

Any objections from you on removing that quality name comparison? (it also doesn't match the function's documentation) Adnoam (talk) 08:55, 7 December 2021 (UTC)

No objections, go right ahead! Not that you need my permission to make the wiki better =P. But my nebulous feelings of what code is "mine" extend to fetching and filtering data. Anything related to the display of data, including sorting it, is firmly in the territory where I'm glad there's someone else who wants to do it. PSGarak (talk) 17:33, 7 December 2021 (UTC)

Done.

Module:ItemList used to be a pet side-project of mine - I taught myself Lua to create it. But since then more editors with coding experience played with it, and took it further than I originally aimed (especially with the addition of SMW). This is why I wanted to check before changing.

And as FYI - not sure if you are on the Discord channel, but Alan has installed now the Template Sandbox extension. So now when editing templates or modules, at the bottom of the edit page there's an option to see a preview of the effects of the (yet unsaved) changes to the code on any chosen page. Really helpful for checking while modifying the code of complex modules. Adnoam (talk) 21:52, 7 December 2021 (UTC)

That's awesome--it's amazing what we do when we get the motivation!

I am in fact not on Discord. That's a pretty handy tip, than, you. PSGarak (talk) 02:53, 8 December 2021 (UTC)

Variant on Template:Current Value for details?

Hi PSGarak, how feasible would it be to make a variant on {{Current Value}} (or a parameter in Current Value) which instead of showing the current value would show the detail associated with that value? --Asarta (talk) 17:39, 7 December 2021 (UTC)

Yeah, I've been mulling about that. I assume this for maintenance of {{World Qualities Box}}?

Absolutely possible. From a tech standpoint, it's not much work. Set up a second property similar to Property:Has current value, and extend {{World Quality}} to set that new property the same way it sets the current one. Then modify or copy {{Current Value}} to query that property

The more difficult thing is interface. Perhaps you could offer some suggestions here. Many of the "Detail" values are currently links or {{IL}} calls. The Diplomat's Current Fascination has both. Some of the current uses (i.e. {{World Qualities Box}}) want to reformat the value for display. I'm not sure how to handle that. Right now the best thing I can come up with is having {{World Quality}} take a third argument for each value, like "AliasN" or "DisplayN" intended for use inside links or template calls. But that seems like a lot of work in the template, and even then the World Quality Box will still needs some case-by-case handling.

Maybe the formatting isn't necessary if we modify the site CSS a little?

- PSGarak (talk) 18:32, 7 December 2021 (UTC)

if we modify the site CSS a little?

👁️✍️

Anyways, what did you have in mind? Alan (talk) 19:23, 7 December 2021 (UTC)

I'm not a webdev and know barely enough about CSS to fight my way out of a very damp paper bag. So take this with a grain of salt.

My understanding is that currently {{World Quality Box}} needs chunks of code like [[:Category:World Qualities|<span style="color: #bba994">World Qualities</span>]] because the CSS currently overrides styles applied outside of links. If you were to try to write something like <span style="color: #bba994">[[:Category:World Qualities]]</span>, it does not display as color #bba994. The Cosmos theme applies color styling to <a> elements, and the magic rules of CSS means that the a selector overrides enclosing style tags.

If I understand this right, which I might not, but here goes anyways: if there were a CSS rule like

  .dark-background a {
      color: #bba994
  }

then the Template could include something like <span class="dark-background">[[:Category:World Qualities]]</span>, and the color styling would apply.

This would also work with things like <span class="dark-background">{{IL|Skeleton: Legs}}</span>, or <span class="dark-background">{{Current Value|The Diplomat's Current Fascination|detail=yes}}</span> when that expands to a link or {{IL}} call. PSGarak (talk) 19:39, 7 December 2021 (UTC)

Unrelated to whether or not this would actually work, if possible tech wise @Alan could you install mw:Extension:TemplateStyles if we decide to go this way? It allows for defining template specific style sheets which would allow something like this without requiring a new addition to MediaWiki:Common.css, which gets unconditionally loaded on every page load --Asarta (talk) 19:45, 7 December 2021 (UTC)

Yeah, that basically looks like it lets you do exactly what I suggested but also substantially more maintainable. Template-specific CSS can be part of the Template definition rather than having to put a bunch of stuff into the main site CSS. PSGarak (talk) 19:53, 7 December 2021 (UTC)

Ok, done. Alan (talk) 20:16, 7 December 2021 (UTC)

I'm getting a 'Fatal exception of type "Error"' message when I try to preview or save a CSS file for a template. Should I just be patient and wait a little longer, or is the extension expecting you to do a Server Wizard thing? PSGarak (talk) 21:00, 7 December 2021 (UTC)

I didn't notice the instruction to ensure dependencies when installing – try again, perhaps? Alan (talk) 23:00, 7 December 2021 (UTC)

We're good now! PSGarak (talk) 02:29, 8 December 2021 (UTC)

Alright, we're in business.

{{World Quality}} now stores the current DetailN parameter in Property:Has current description. {{Current Value}} will use this value if you set detail=yes.

I've made a few changes to {{World Qualities Box}}. It now uses the TemplateStyles extension that you asked Alan to enable. Custom CSS changes link text to the appropriate color if links are enclosed in elements with the "quality" or "value" classes. The structure of the template has been updated to remove most (not all) custom colors with those classes, especially on links. Because of this, links and {{IL}} calls no longer need style attributes inside of their appearance.

The False-Season item and the Engineer's Fasciation now pull details directly from the relevant quality pages, and the #switch statements in {{World Qualities Box}} for those values have been removed. The result is not quite exact parity, the wording of the Engineer's item shifted a little bit. But it's a lot more manageable now.

I haven't updated zoological mania or The Trifling Diplomat. The Detail args on that page are very different from what's currently displayed on the world qualities box. Someone will have to make some editorial decisions on how to align them. PSGarak (talk) 03:48, 8 December 2021 (UTC)

BDR Union ItemList Fixed

Just FYI, I think your edit deploying SMW ItemList changes broke Bizarre, Dreaded, Respectable (Guide) - previously, the call to {{ItemListByQuality}} was returning nothing.
Your implementation of items_exist didn't account for the usage of {{ItemList}} that combines multiple Qualities in the {{{1}}} parameter - I implemented a quick-and-dirty fix to allow the creation of ItemLists for multiple Qualities, though long-term we probably need to change the way multiple qualities are accepted as a parameter (and update documentation accordingly) - what if an item gets an Enhancement for a Quality whose name naturally contains a comma, i.e. Alan (talk) 00:57, 8 December 2021 (UTC)

Your Q&D fix is the same one I used for find_minmax when dealing with BDR. I had not considered qualities with commas, although this would have also broken the previous implementation.

I don't think there's any case where we search for unions except for BDR. Unless someone wants to start making itemlists for the Khaganian intrigues, it might be easier to just special-case "BDR" as a quality and have that expand to Bizarrre||Dreaded|Respectable.

At one point I experimented with having SMW treat BDR as a separate "quality" when recording item qualities. This ends up having a few issues that make it more trouble than it's worth. Maybe I'll find a solution one day. PSGarak (talk) 03:01, 8 December 2021 (UTC)

I agree. "BDR" instead of "Bizzare,Dreaded,Respectable" string is both easier to use when passing the param and also easier to parse by the code. If we have just this one instance, no need to maintain a generic capability of supporting any theoretically possible quality union. Adnoam (talk) 14:53, 8 December 2021 (UTC)

Worst in slot

Not sure where to put it, but seeing as you are working on the module: is there any possibility to generate a Worst in Slot list the same way as the Best in Slot list on, say, Dangerous Items? Sometimes you just want to get lower, be it for purposes of wiki research or otherwise. Ideally it would have the same options, just with the ordering flipped. RagCall (talk) 15:08, 8 December 2021 (UTC)

@RagCall, for that, see Stat-reducing items. Adnoam (talk) 15:32, 8 December 2021 (UTC)

Gain and Loss templates

Hi PSGarak, I recently finally started to draft a rework of our current system of Gain and Loss templates (current idea: only keep {{Success Increase}}, {{Failure Increase}}, {{Gain}}, and {{Loss}}), and since I'm both messing with SMW in doing so (see Property:Increase Type) and reworking them anyway is there anything you'd like to see done on the SMW side of things? --Asarta (talk) 17:44, 10 December 2021 (UTC)

I have ideas and opinions!

From an administrative point of view, SMW recommends the use of Fixed Properties if you expect to set the property a few thousand times. (Think of it like a database index.) Action results are definitely this common. While most of SMW you can change on the fly, Fixed Properties have an important order-of-operations: First define the property, then make it Fixed (probably ask Alan), and last fill in the data by rolling out templates.

For Gain and Loss, I've thought a lot about whether anything useful can be encoded into the Property beyond which item/quality was gained or lost. I've come to the conclusion that amounts are simply too dynamic and unstructured. It seems to me the best you could hope for is a raw text field, but that's only marginally useful, and has additional problems if the text contains category links or ref tags. Two things that would be more immediately useful and seem feasible are linking an Action back to its card or storylet (and from there potentially it's location or setting), and pulling in Qualifier information like Fate, Festival, or Ambition categories. But neither of these require that the "Gains" or "Loses" property itself contain more than a link to the item/quality page.

Separating success/failure increases from "regular" increases might be useful. It's also possible, but complicated, to denote which results come from success vs failure vs rare success. Actually modeling this in SMW has challenges, because sub-properties are less useful than I would like. It seems sub-properties are used for selection but not querying.

One aspect of our current system that I would like changed is the bestiary of Categories related to items and qualities. If you add an item X, that will usually entail the create of Category:X Uses, Category:X Gain, and Category:X Loss (and potentially others). A lot of these categories are trivial or very close (e.g. Category:Overgoat Gain has 1 entry), but still entail bookkeeping overhead because editors need to click over to create the categories with the templates every time a new item exists.

To that end, something I have on the back burner is a SMW-powered replacement for {{Category tree}}, currently existing over at {{Property listing}}. This ended up being more complicated because a handful of "X Gain" categories actually have useful content, and we want to continue to support that, so there's a flow to re-create that with Concept pages.

What are the goals or changes that you have in mind for reworking the system? Is it focused on changing the underlying information structure, or taming the collection of templates that we use for everything, or something else?

- PSGarak (talk) 19:41, 10 December 2021 (UTC)

Its mostly taming the collection of templates, and converting them into easier base versions (no more remembering if you need Gain, Increase, or Item Gain).

My current plan of action is to set three new properties (thanks for the note on Fixed properties; its a bit late now because I already did two, but pinging @Alan): whether or not something is an item (Property:Is Item), whether or not something is a quality (haven't created this one yet), and what the increase type is (Property:Increase Type). The idea is then that Gain/Lose 2.0 basically looks up those properties in a massive set of if/ifeq/switch statements, and massively lowers the process related to adding new ones by eg removing the need for setting Discrete=yes, because the template simply looks up whether or not Property:Increase Type is Discrete.

With this kind of simplification I hope to be able to merge all variants of gain/lose except the two special cases I mentioned above and therefore make the display much more consistent between templates. The eventual implementation would say let you do * {{Gain|A Leasehold on All of London|1 x}}, and then automatically see okay this is a item, there is no occurrence/now so use this wording. --Asarta (talk) 19:53, 10 December 2021 (UTC)

I've dragged my feet on conversion to fixed properties because it's extremely disruptive (SMW forces a full-page interstitial for all pages if it detects a misconfiguration) – I'll go through and list the most common properties as fixed and run the data rebuild process tonight. Alan (talk) 19:56, 10 December 2021 (UTC)

I'm hoping we don't actually need it that much. It's only recommended for high-volume properties. Aside from Property:Has icon and Property:Gains, which are already fixed, I think the highest-volume is property:Has effect which is less than 2,000.

If the Property doesn't have any data, does the rebuild still happen? It might be preferable to remove the property from the template, then fixate the property, and then restore it to the template. PSGarak (talk) 20:28, 10 December 2021 (UTC)

The order of operations isn't as critical as you perhaps think; conversion of an existing property is possible; it just requires rebuilding the data store (which already happens weekly). If this were a major problem, I wouldn't have dragged my feet on setting this up. It'll be taken care of tonight. Alan (talk) 20:45, 10 December 2021 (UTC)

Actually, looking at the list of properties, I'm not sure which ones would in future become widely used and thus be candidates for fixation. Certainly ID is one that should become fixed, and there are some special properties that span several thousand pages, e.g. Property:Comment on, Property:Has query, and Property:Modification date. Not sure if those can/should/are already fixed properties.

I think I'd want to hold off and push through all the property fixation at once, once I know which ones will need to be fixed. I'm satisfied with performance so far; I'm not desperate to eke out optimisations. Alan (talk) 02:06, 11 December 2021 (UTC)

This is drifting rather off-topic from the original thread. But since you want to affix properties as little as possible, I've gone ahead and defined all the properties that I currently Have Plans For which are likely to reach that volume.

• Property:Loses, opposite of Property:Gains
• Property:Uses which will apply to every use of {{Use}} and {{Unlock}}, & constituent fields:
  • Property:Use
  • Property:Use type
• Property:Located in
• Property:Has action, which will apply to almost every use of {{Options}}
• Property:Has challenge & constituent fields:
  • Property:Against
  • Property:Difficulty
  • Property:Challenge type

No rush or anything, I don't have plans to actually roll these out immediately. Or even soon-ish.

I don't know if anyone else has plans that would require fixed properties (I don't think the Market or other economic properties will have bighuge volume).

- PSGarak (talk) 21:32, 21 December 2021 (UTC)

Market will not. There will be two properties which touch all buyable and sellable items, though, that is probably most of the items. That's all of those I can think of right now. -- RagCall (talk) 09:13, 22 December 2021 (UTC)

I'm not sure that Properties are the best fit for that use case, since SMW can query Categories. However, like sub-properties, it seems to have trouble with sub-categories; when I #ask if A Leasehold belongs to Category:Items, the answer is no.

If you do move forward with Properties, perhaps set them as Booleans rather than Text. Or a single property like "Asset type" (this is not a great name) which could be Quality or Item (and in the future, perhaps Action or Card).

- PSGarak (talk) 20:16, 10 December 2021 (UTC)

Ah, I forgot Booleans were a thing, that can be done. I also agree that "Asset type" is better, but I can't think of a good name for it. What would you do with having them set as Card/Action? I see what you mean with categories, but considering the issues you outlined I think this works better for now. --Asarta (talk) 20:29, 10 December 2021 (UTC)

In the vague future, I have ideas that when we list Item Sources/Uses, beyond the list of actions it could also list parent card/storylet, and possibly other info. So e.g. you're looking for mirrorcatch boxes, the Sources Category Tree would have entries like:

• Reach towards the shore 1 (from Stay a little while, Storylet in The Waswood)
• Give an impassioned speech on Light and Beauty (from Enlighten Ealing Gardens, Card in Ealing Gardens)

For this, it's useful to know if a page represent a card or a storylet (or something less common like Item Actions). There's no particular reason to shove everything into one Property, other than that it appeals to my sense of aesthetics.

- PSGarak (talk) 21:18, 10 December 2021 (UTC)

It does to mine as well, and it has slight advantages when dealing with a situation where multiple options are possible, because they can all be solved in one {{#switch: instead of a series of {{#ifeq. This kind of top level property has my preference; really whats stopping me is that I need a name. --Asarta (talk) 21:23, 10 December 2021 (UTC)

Has game object type? Has game role? PSGarak (talk) 21:33, 10 December 2021 (UTC)

Hmm, Has Game Type might work? Its a bit ambiguous, but I think it roughly describes what it does, and it isn't user facing anyway --Asarta (talk) 14:40, 11 December 2021 (UTC)

A followup question about Property:Has Game Type: are the Game Type restrictions supposed to be mutually exclusive? In particular, should a Fate action have only "Fate Action" or also "Action" and "Fate"? Are Social Actions also Actions? (That question is the main part why I haven't touched our Category:Social Actions templates yet).

It should also be noted that the FL 1-click wiki extension now uses Has Game Type as the fallback identifier if the ID is not present (meaning that it will identify if the user clicks on, say, a card or a storylet). (It used to be categories, but it ran into issues because they are not transitive and e.g. Gold Cards are not in Category:Cards.

(And by "it should be noted" I mean "can someone actually write that down somewhere?" ;)) -- RagCall (talk) 12:17, 20 January 2022 (UTC)

SMW does not enforce mutual exclusivity. It's possible for a page to have more than one Has Game Type value.

In terms of our use of the things, I dunno? I would lean towards exclusivity, just because SMW itself does not handle negative conditions. If I want to search for the non-Fate sources of something, I can't search for Game Type::Action and then exclude Game Type::Fate.

This makes it slightly more difficult to get a list of all actions, inclusive of social and fate actions, that meet some other criteria. But I don't know how often that might come up. PSGarak (talk) 15:06, 20 January 2022 (UTC)

Hm. According to documentation, it should work by default. @Alan, can you check the configuration? -- RagCall (talk) 18:50, 11 December 2021 (UTC)

Sub-categories can be used for selection but not printouts, which is a frustrating restriction. However now that I'm thinking about it, a work-around might be possible.

Not available in printouts: See what happens when we ask for membership in a category.

{{#ask:[[A Leasehold on All of London]]|?Category:Items|?Category:Treasure}}

	Items	Treasure
A Leasehold on All of London		X

For reference, the list of (direct) categories, via {{#ask:[[A Leasehold on All of London]]|?Category}}

	Category
A Leasehold on All of London	Ambition: Heart's Desire! Items Respectable Items Shadowy Items Persuasive Items A Player of Chess Items Treasure

Now, we hack around by using selection and asking how many pages with that name are in the Items category?

• {{#ask:[[A Leasehold on All of London]][[Category:Items]]|format=count}}: 1
• {{#ask:[[A Leasehold on All of London]][[Category:Qualities]]|format=count}}: 1

Ah, so, here we have a problem. A Leasehold is in Category:Qualities. This is not an artifact of SMW, this is actually true.

Category:Ambition: Heart's Desire! Items is a subcategory of category:Ambition: Heart's Desire! is a subcategory of Category:Ambition is a subcategory of Category:Qualities. The SMW documentation on subcategories mentions this problem, see smw:help:Inferencing.

There's probably more problems like that lurking in the category hierarchies. I think setting the "Has game type" or whatever property is the appropriate solution.

- PSGarak (talk) 19:57, 11 December 2021 (UTC)

Something that just occurred to me. There are a handful of message types that are categorical. E.g. Accomplishments use a special gain message, for which we have {{Accomplishment}}. And Progress qualities have a special "gone" message, for which we have {t|Progress Reset}}. (Relatedly, the one other template I might want to keep around after consolidation is {{Gone}} separate from {{Loss}}.)

What you're working on right now could take these categories into account when figuring out the default display message. One approach would be that the template queries the Category for a handful of values, i.e. {{#show:{{{1}}}|?Category:Accomplishment}}. Another approach would be that {{Quality}} has a switch statement based on {{{Quality type}}}, and sets different values for Increase Type for a few distinguished values. So e.g. Accomplishments would have an Increase type of "Accomplishment" instead of just "Discrete."

Both of these approaches have some drawbacks and are adding complexity and special cases in a few places. But the complexity is already present in the game and the Wiki. At the least, this seems better than custom messages for such qualities.

- PSGarak (talk) 15:12, 14 December 2021 (UTC)

What do you mean by "useful" content? If this is about categories which are essentially guides, I would be in favor of moving those out of the category name space. (I already have links on my user page which find categories with a lot of text. We could feed those into a bot and do a mass-move). -- RagCall (talk) 18:39, 11 December 2021 (UTC)

Basically yes. By "useful" I mean Item Gain category pages which have player-authored content beyond just {{Item Sources}}. I've been using Category:Volume of Collated Research Gain as my primary example.

Just to go into a little more detail about my thoughts: The idea is that such pages would exist in the Concept namespace, e.g. Concept:Volume of Collated Research Sources, so the guide would still live on the same page as a wiki-generated list of exhaustive actions. The difference being, that page would only exist if there is player-authored content. So trivial category pages like Category:Lyon Pursuivant of Arms Extraordinary Gain would not have an equivalent, and simply cease to exist. A page with the listing is still accessible from the Item page, but exists as a SMW query rather than a permanent page.

The Item page would acknowledge the existence of such guides, as in User:PSGarak/Sandbox/Volume of Collated Research. Or if there is no such guide, it would encourage wiki readers to create one, e.g. user:PSGarak/Sandbox/Shard of Glim. PSGarak (talk) 19:42, 11 December 2021 (UTC)

Okay I've created Property:Has Game Type. Pinging @Alan, as if we go with that it will definitely need to be a fixed property, and also in general it will need to reparse some ~22K pages when we start deploying it. --Asarta (talk) 09:47, 12 December 2021 (UTC)

Before we do that, could we restrict the valid values with Allows value? -- RagCall (talk) 10:15, 12 December 2021 (UTC)

Sure, except I'm not sure what we should all allow. Off the top of my head Action, Storylet, Card, Quality, Item, Location would all be allowed, but would we eg also allow Social Action and Item Action?

Edit: Also do we want to go with Allows value or Allows value list, which instead defines a page in the Mediawiki: namespace containing all allowed values --Asarta (talk) 11:01, 12 December 2021 (UTC)

For the uses I have in mind, I think I would want to include Social Actions or Item Actions. When looking at a list of item sources, I might want Social Actions to be labeled as such. Allows value list might be the best approach for letting giving us the flexibility to update the list of cases, or perhaps smw:Help:Special property Allows pattern.

Item Actions are an interesting case. They're actually have two different game types, Item and Storylet. It's permissible in SMW for an item to have both of those properties, and that might be the best option.

It's also possible to model the Item Actions as a sub-objects within the page. So the item page has a game type of Item, and it contains/links to a sub-object of game type Storylet (or Item Actions) which represents the item interactions. PSGarak (talk) 20:35, 12 December 2021 (UTC)

Okay as I mentioned below I dropped it yesterday on everything except Item Actions and Social Actions, because I don't understand SMW enough to get how a sub-object works, and our collection of Social Actions scare me. --Asarta (talk) 16:00, 14 December 2021 (UTC)

I don't have edit access to the page that defines allowed values for Property:Has Game Type. Would you mind adding Shop and Market as allowable values? PSGarak (talk) 19:37, 18 December 2021 (UTC)

Should be done --Asarta (talk) 20:11, 18 December 2021 (UTC)

ID as number

Hey, I would like to change Property:ID from Text to Number. I would like to be able to sort pages by ID, ask the wiki for "nearby" IDs, ask for missing IDs within a range and so on. The main downside seems to be that there are 188 pages that have multiple IDs. I have considerend several solutions about that:

• explode the ID field by comma in all affected templates (would prefer not to do that, as that would touch around 25000 pages)
• split all affected pages into different pages (thereby generating ~200 new articles)
• ignore the warnings (kinda hard to do)

Is there anything on the side of SMW that is more neat than those? Any other thoughts? -- RagCall (talk) 09:10, 14 December 2021 (UTC)

SMW is ok with a single page having multiple IDs. Setting aside how we get there, the ideal end-state seems to me to be your first option, splitting by comma and setting multiple IDs on the page. Splitting the page isn't ideal, the wiki tries to be useful to the players first, and matching the game's model of the data is only a means to an end. It's possible there are some pages that would be better off split, but I suspect the majority of those are merged for a reason.

Reprocessing a whole buncha pages isn't ideal, but we do it sometimes. I guess ask @Alan what's the best way to go about that.

As an aside, if we're investigating the values of SMW properties, let's practice using SMW queries! In this case it's probably not any easier than using the site search function, but it has the benefit that it can print the IDs, which is illuminating.

Here's an inline query for pages with a comma in the ID field: {{#ask:[[ID::~*,*]] |?ID |format=ol |limit=10}}

1. "...yes?" (ID: 118,745)
2. "A matter of some interest to me..." (ID: 9,377)
3. "Advocate." (ID: 179,370)
4. "After I left the Palace..." You shrug. (ID: 27,455)
5. "Ambassador" (ID: 260,769)
6. "Ambassador" (Arbor) (ID: 265,311)
7. "An injustice was done." (ID: 27,532)
8. "And why would I care how Notable I am?" (ID: 108,838)
9. "Back towards the Unterzee. We have erred gravely." (ID: 259,326)
10. "Bishop." (ID: 211,777)

... further results"," is not a number.

And here's a link to get the same results from Special:Ask. The Special:Ask page is magical.

- PSGarak (talk) 14:55, 14 December 2021 (UTC)

Having asked @Alan in the past I believe the job queue enforces its own limits, so I think reparsing every single one of those should be fine (don't trust me on that however). However right now the wiki is working through Property:Has Game Type, which has been running for some 24h and I think is roughly halfway. --Asarta (talk) 15:56, 14 December 2021 (UTC)

Yeah, reparsing pages seldom poses an issue, since it just gets shoved onto the job queue for batch processing.

The length of the job queue really is inconsequential; there shouldn't be anything to fear from pushing tens of thousands of pages onto it.

If we're reworking IDs, I wonder whether it might be prudent to rework the way {{Item Actions}} works (e.g. splitting them onto new pages and embedding the storylet on the item page) – currently, I'm pretty sure every usable item has two IDs. Alan (talk) 16:02, 14 December 2021 (UTC)

Hmmm, that sounds doable, although we'd need to account for it in the storylet code. So do you envision having say Sheaf of Poetic First Drafts (storylet), which has the storylet ID, and then transclude that on Sheaf of Poetic First Drafts? That might need to be its own template; you'd want to rework some of the wording. --Asarta (talk) 16:08, 14 December 2021 (UTC)

There'd probably need to be template changes, yes – my thought was passing the storylet title as a parameter in {{Item}}. Alan (talk) 16:15, 14 December 2021 (UTC)

If you think it's better for Wiki readers that {{Item Actions}} have their own page, then by all means. But SMW can accommodate how we currently do thinks.

We can make the Item storylet a smw:Subobject. This basically means that SMW can treat the item storylet as if it's its own page, without it needing to actually be a page. So e.g. the Storylet for interaction with Shard of Glim would be recognized in SMW as "Shard of Glim#Sell some Glim." This sub-object would have its own properties (ID, Game Type, categories if we want) which are separate from the Shard of Glim.

I could whip up a prototype later today.

UPDATE: Later today has arrived.

{{#ask:[[Has Game Type::Item Action]]|?ID|?Category|format=ol|limit=10}}

1. A Bad End#Giving up the Search for the Name (ID: 51,461, Category: Storylets, Item Actions)
2. A Boxed Cat?#Pass the Cat: A peculiar tradition (ID: 15,475, Category: Storylets, Item Actions)
3. A Novel Birth-Mark#Move to a Spire-Emporium at the Bazaar (ID: 137,554, Category: Storylets, Item Actions)
4. A Surprise Package#Open a Surprise Package (ID: 119,087, Category: Storylets, Item Actions)
5. A Wink from the Manager of the Royal Bethlehem#Move to a Suite at the Royal Bethlehem Hotel (ID: 137,623, Category: Storylets, Item Actions)
6. Aeolian Scream#Use your Aeolian Screams (ID: 20,953, Category: Storylets, Item Actions)
7. Amanita Sherry#Trade your Amanita Sherry (ID: 21,041, Category: Storylets, Item Actions)
8. An Exemplary Work of Lapsarian Theological Art#Artistic Scrutiny (ID: 338,702, Category: Storylets, Item Actions)
9. An Identity Uncovered!#Study those whose Identities you have Uncovered (ID: 21,011, Category: Storylets, Item Actions)
10. An Infernally Diplomatic Privilege#Move to a Sanctum at the Brass Embassy (ID: 137,627, Category: Storylets, Item Actions)

... further results PSGarak (talk) 16:17, 14 December 2021 (UTC)

Cool, I think that pretty much works for that usecase. Only thing left is Social Actions, because A) I'm scared of those templates, and B) I'm not sure if we want a general catch all or a set of specific versions? --Asarta (talk) 18:46, 14 December 2021 (UTC)

To get back to the original topic: as of now, all IDs which are set somewhere should be numbers now (in particular, pages which have ID = 111, 222 now set two separate instances of Property:ID). @Alan @Asarta Can you think of any reasons to not change it to Number? -- RagCall (talk) 10:52, 22 December 2021 (UTC)

Sounds good to me. Checking, I think any Template Editor should be able to change that page; pretty sure I set its protection level to TE specifically pending this discussion. --Asarta (talk) 14:21, 22 December 2021 (UTC)

That's correct, I could change it myself - I just wanted to doublecheck before such wide-reaching changes :) will wait till tomorrow and do it then. -- RagCall (talk) 17:59, 22 December 2021 (UTC)

Confirmed that SMW reports no instances of an ID with a comma. PSGarak (talk) 14:28, 22 December 2021 (UTC)

#ask for record entries

Hi, if I may bother you about record entries again:

We currently have User:Asarta/Sandbox, which has multiple instances of Property:Has cap on gain set. I wanted to query those pages that have Heartless set, and want to return only the cap set on Heartless.
{{#ask: [[Has cap on gain::Heartless;?]] |?Has cap on gain.Number = Cap |sort=Has cap on gain.Number, |mainlabel=Option|limit=10 }} produces this:

As you can see, it also takes the values set on Melancholy and Hedonist. I want it to return only the 5, the value set for Heartless on User:Asarta/Sandbox, and sort by that. How would I format that? (Also, note that it wanted me to put in ? as a placeholder, not +). I have a feeling this is meant to resolve my question, but I don't understand it :< -- RagCall (talk) 18:55, 17 December 2021 (UTC)

This gets subtle. The tricky thing is that you have to select the record, not the page that contains the record. If you select the page, then you'll be querying all of the records on the page, which is what you're seeing in your example. Selecting only the record lets you grab the fields from that specific record.

{{#ask: [[-Has cap on gain::+]] [[Page::Heartless]] |?Number|limit=10}}

The [[-Has cap on gain::+]] portion selects objects which are the target of a Has cap on gain property, which will all be records. Then [[Page::Heartless]] filters for those with a Page field of Heartless. Since our selected objects are the records themselves, the printout statement ?Number is just the field, not a property chain.

The fact that the selected object is a record is why the links all have RNG-looking #fragment identifiers at the end. I'm not entirely sure how to get rid of that.

As an aside, when you create a Record type, the field declarations are property names, not types. It looks like this seems to work out anyways because Type names are also auto-generated properties. But take a look at how Property:Has effect is defined: the fields are properties, which have their own pages and declarations.

Note that the following query will also generate the same results: {{#ask:[[Page::Heartless]]|?Number|limit=10}}This is because we're just asking for objects with the Page property, which is currently only used by Property:Has cap on gain. But if a second record used Page as one of its fields, then both fields would show up in that second query. This might or might not be what we want, but it something to keep in mind.

- PSGarak (talk) 20:12, 17 December 2021 (UTC)

Thanks. I was in fact aware that data types are properties and designed it intentionally that way. Is there any downside to just using data types? (I don't really see a way around this at some point - of course we could introduce a Property:Quality as an in-between step, but that's neither here nor there imho). -- RagCall (talk) 22:46, 17 December 2021 (UTC)

I wasn't aware that trying to do it that way would even work, so I haven't thought too hard about it. The only concern I can come up with is that if two records have a Page field, then Property:Page would intermingle them. That's probably not actually a big issue, it just means you have to be more explicit when querying those records.

There are situations where using named fields would be desirable, because you could select which records would have their data intermingled. Like the Shop/economics property we were discussing elsewhere, I might want to have a "Price" field shared by "Sells for" and "Buys for" separate from other uses of Number. But perhaps Page and Number are sensible defaults for records where we're not expecting such uses.

- PSGarak (talk) 23:12, 17 December 2021 (UTC)

Hrm. So that works now, more or less. The problem now is that I would like to get the page that the record belongs to, because I want to query its properties (such as "Is retired"). The documentation says that a record is a subobject, so I thought I could get the parent page via [[-Has subobject]], but yet to no avail - I just keep getting 0 results, and the records don't even show up if I just do {{#ask:[[Has subobject::+]]|?Has subobject|format=table|limit=5}}.
(Here is an example of such a record: [1]). Any help? -- RagCall (talk) 22:21, 30 January 2022 (UTC)

Well, there's some subtleties, and then there's also what I suspect is a bug.

I know the docs say that they're subobjects under the hood, but they might be exempt from the standard Property:Has subobject listing. Instead, you can query them by reversing the Record relation, in this case [[-Has cap on gain::+]]

{{#ask:[[-Has cap on gain::+]] |?Page |?Number |format=table|limit=5}}

	PageThis property is a special property in this wiki.	Number"Number" is a type and predefined property provided by Semantic MediaWiki to represent numeric values.
"Hard lessons"
"I bring only hunger"
"I myself am my only true friend!"
"I myself am my only true friend!"
"I myself am my only true friend!"
... further results

The objects selected by this query are the records themselves (this is why the main column is in italics). So querying for the fields ?Page and ?Number are unambiguous, even if there are multiple records on the page. If you want to query a property of the page containing the record, then you need to follow the "?-Has cap on gain" property first.

Here's the thing that I think is a bug: a printout for "?-Has cap on gain" on its own should return the page itself, right? It always seems to return junk. Specifically, junk of the wrong type. I think that SMW somewhere loses track of the fact that the relation is reversed, and thinks that the reversed relation should have the same type as the relation itself, a record with two fields.

Nonetheless, further chaining properties from the containing page works fine. You can even follow the record relation backwards and forwards, which if the same record appears multiple times on the page, will un-de-duplicated them. Which is sometimes useful. See below for all of these on display at the same time.

{{#ask:[[-Has cap on gain::A dusty bookshop]] |?Page |?Number |?-Has cap on gain |?-Has cap on gain.Has Game Type |?-Has cap on gain.Has cap on gain |format=table|limit=5}}

- PSGarak (talk) 02:03, 31 January 2022 (UTC)

Could you take a look at Concept:T1? I seem to be unable to filter for the category of items returned by a query as above.

In fact, I seem to be unable to get the category of a record field printed either.

{{#ask: [[Category:Shops]]
 |?Category
 |limit=1
}}

	Category
After-Hours Market	Shops Penny Gain Drop of Prisoner's Honey Gain Sneak-Thief's Mask Gain Sober Dress Gain Set of Workman's Clothes Gain
... further results

That works fine. But if After-Hours Market is the result of a query as above (illustrated here by filtering where I can sell Sneak-Thief's Mask for 35 scrip), I should be able to pick the category via Shop.Category, right?

{{#ask: [[-Bought for::+]][[Price::35]]
 |?Shop
 |?Shop.Category=Category
 |?Shop.Gains
}}

	Shop	Category⠉	Gains⠉
Sneak-Thief's Mask	After-Hours Market		Drop of Prisoner's Honey Sober Dress Set of Workman's Clothes Sneak-Thief's Mask

the category returns nothing, while Gains returns something, so my query cannot be completely wrong? -- RagCall (talk) 07:49, 25 February 2022 (UTC)

As far as I can tell, Categories cannot be mixed with Property Chains, either for selection or for printouts. SMW's integration with Categories seems a bit uneven.

For your particular example of T1 items and tiered items, one thing I've considered in the past is using the "Economy" parameter in {{Item}} to make a property pointing items to the Item Type page whose table they appear in. My thought was to use this to auto-generate some of the item tables themselves, but that also more-or-less serves your purpose as well. PSGarak (talk) 14:41, 25 February 2022 (UTC)

Hm. Item Type pages redirect to their categories, currently (see e.g. Influence). That will require some thought. Maybe we can instead do something like {{#set:Item Category|Category:Influence}} on the item page and then check for [[Item Category::<q>Subcategory of::Category:Tiered Economy Items</q>]] in the concept. Will try that tomorrow, thankful for any other ideas in the meantime.

Thanks for answering all my questions! -- RagCall (talk) 18:05, 25 February 2022 (UTC)

Redirects aren't always something that you need to deal with, per se. SMW unifies pages that redirect to the same target. See for example how {{Item}} and Module:ItemList use Property:Equips in slot. {{Item}} stores "Hat," the property records Category:Hat, the module queries "Hat" and retrieves all the right pages. Or more simply, how Rat-Shillings (plural) pulls the icon from Rat-Shilling (singular).

But that's an interesting idea to use the fact that they're Categories, so you can use the Subcategory property. That's probably more likely to work, since Subcategory-of is a special property managed by SMW rather than trying to make use of a part of MediaWiki.

- PSGarak (talk) 18:59, 25 February 2022 (UTC)

The fact that the selected object is a record is why the links all have RNG-looking #fragment identifiers at the end. I'm not entirely sure how to get rid of that.

^ I just realized if we really want, we can

1. make a Template:Linkpage
2. put {{PAGENAME:{{{1}}} }} in there
3. pass the record result as plaintext to this new template. I have tested it and it works, it is, however, a bit awkward to handle.

-- RagCall (talk) 13:14, 22 April 2022 (UTC)

I used #explode in the templates that I wrote, but PAGENAME looks less fiddly so I might switch over.

It still seems like a big effort to fit this in. If someone is trying to construct a quick, simple table for a guide, it's a large lift to switch from the default table to using template-driven display. Especially since you can't just run mainlabel through a template, you have to have a template that processes the whole row of results. PSGarak (talk) 15:09, 22 April 2022 (UTC)

Item Action subobjects

When you have the time, could you take a look at the Item Action at Counterfeit Head of John the Baptist? SMW has a problem because the Template:Item Actions uses {{{Title}}} for the name ob the subobject, which contains dots within the first 5 characters. -- RagCall (talk) 13:08, 7 January 2022 (UTC)

How ironic, I was just talking about John the Baptist because today is his Feast Day, and here he is again.

I've stripped periods from {{{Title}}}, which deals with this error. SMW documentation on Help:Adding subobjects indicates this is the only naming restriction on subobjects, so this ought to be a complete fix that we won't have to revisit in the future. In the extremely unlikely case that the title of an item action storylet is simply "...," then SMW will simply give it an anonymous identifier.

- PSGarak (talk) 15:10, 7 January 2022 (UTC)

Help with Is retired and purging

I would like users to be able to query for only non-retired actions, storylets etc. The way I intended to do it is thus:

• certain templates like {{Retired}} set the Boolean Property:Is retired to yes. That means the property can have three values: true, false and <unset>.
• all main templates ({{Card}}, {{Action}}, {{Storylet}}, ...}} contain something like the following:
  • {{#if:{{#show:{{FULLPAGENAME}}|?Is retired}}|<!--if set, do nothing-->|{{#set:Is retired = false}}}}
  • which will set Is retired to false only for those which do not have it set to true

This works fine insofar as that it does not lead to an inconsistent state. However, all these pages require a manual purge after editing the template - the job queue does not seem to pick up on it. You can see the current state here: ... further results

Any ideas how to achieve the desired effect without a) either including a IsRetired parameter in all templates which would have to be set manually for each page or b) requiring a manual purge? -- RagCall (talk) 15:03, 14 January 2022 (UTC)

SMW has the limitation that a query on a page cannot query the current state of the current page. This is because of the order of operations: read SMW state from the database, create new page with SMW properties, commit that to database.

Generally the preferred approach for tracking in-page state is Variables. So I would suggest having {{Retired}} set a variable, and then {{Card}}, {{Action}}, etc. read that value and set the property based on that. Perhaps extend those templates to contain an optional parameter to override, and in the case of {{Item}} read the existing Access parameter. Something like:

• In {{Retired}}: {{#vardefine:retired|Yes}}
• In {{Action}}: {{#set:Is retired = {{#var:retired|No}} }}

Thankfully the {{Retired}} template is always at the top of the page so we can rely on the variable already being there. And the usual safeguards, check for embedding context--I'm sure there are lots of live cards/storylets that list retired options, especially Festival content.

There's a feature of SMW that might help in this case, the @annotation query marker. I haven't used and I'm not sure how it works. Personally I would tend towards the Variable approach.

- PSGarak (talk) 15:54, 14 January 2022 (UTC)

For documentation purposes: after some discussion in Discord, I decided to go with the annotation approach, because that seems to work alright and according to Asarta, variables might not be supported long-term with the switch to Parsoid, whereas in the case of SMW, it seems to be at least unclear.

One minor-but-not-negligible-downside is that after implementation, affected articles require a manual (HTTP) request to them to update the property. Simply visiting the page is enough, but an API request for the article content is not sufficient; or Alan can run a maintenance script. I will definitely ask Alan for larger categories such as Actions. The goal is to eventually have all game content classified as retired or not-retired. -- RagCall (talk) 12:09, 20 January 2022 (UTC)

I just came across this thingy, which might be a different way of addressing the issue: [2]. PSGarak (talk) 03:57, 28 January 2022 (UTC)

👁✍

It's installed. Feel free to play around with it and see if it works as expected.

Do be careful to not create dependency loops, as the extension page cautions against. I've configured the extension to push jobs onto the job queue rather than running them synchronously, so mistakes won't cause the wiki to hang, but I'd still like to avoid unnecessary load. Alan (talk) 04:48, 28 January 2022 (UTC)

Property:Has challenge and related properties

I really like the idea of storing challenge information, like on Property:Has challenge. One edge case I see is that there are some challenges which do not have a readily assignable difficulty - for example, the difficulty of Convince her to take you again to the river and of the other things in the House of the Watchmaker's daughter actually takes as an input the base stats of the character. How exactly would we handle that? (We could probably take a fallback value like -1 or something, but we need to have some convention). Is Property:Has challenge info used instead or supplementary? Would we also use Property:Has challenge info for modification info like the things using Template:ModifiedBy? -- RagCall (talk) 12:27, 20 January 2022 (UTC)

The vast possibilities of dynamic challenges certainly present a problem for data modeling. I've been thinking of how to replace/enhance the Category Tree of pages-with-challenges on Quality pages, and the data model I've come up with is designed with that use case in mind.

My goal for the replacement is that the list of pages will be sorted by difficulty, with the difficulty displayed, and dynamic challenges footnoted with <ref> tags. For these purposes, the number for Property:Has challenge should be some moderately-sensible "default," to be used for sorting if for nothing else. And whatever is in Property:Has challenge info would be stuffed into the footnote, which should ideally be the same as what is displayed underneath Challenges.

So to answer your question, Property:Has challenge info is intended to be supplementary. And it would include text generated by {{ModifiedBy}} as well as free text entered in Challenge information. (There is a technical challenge of making sure that categories set by {{Use}} are not stored in that property, which is mostly an issue of setting/restoring #var:embedcontext.) PSGarak (talk) 15:23, 20 January 2022 (UTC)

FL Wiki survey results

Hi PSGarak, I've just published the results of the survey and wanted to point you to it, since I think several of the suggestions could potentially solved by SMW. --Asarta (talk) 20:32, 26 January 2022 (UTC)

Agreed. Quite a few responses had variations on the theme of wrangling the Item Sources/Item Uses categories. One thing I don't think that SMW can do is separate One-Time vs Repeatable, which was a common request. I have a handful of half-baked experiments addressing other aspects: paginating over-long lists, linking to player-authored guides, connecting to source cards/storylets, and annotating options that are seasonal/retired/Ambition/etc. The survey definitely gives me a lot more motivation to get those things up and running. PSGarak (talk) 03:17, 27 January 2022 (UTC)

Thanks

...for the detailed examples of the challenges in storing Unlock/Use information. I am not sure if I am coming off as antagonistic via text in my replies, so I thought I would reiterate I really appreciate the thought you are putting into this! -- RagCall (talk) 22:38, 1 February 2022 (UTC)

Oh, not at all! That's now communication happens when you're collaboratively editing a document instead of writing a back-and-forth conversation And it's a good thing that this information is getting put into documents which are real Wiki content. At the end of the day we're all trying to help make the Wiki better, and if we have different ideas for how to do that, they need to get hashed out somehow.

For all the thinking I've done on how to use SMW, I've been remiss in documenting or communicating my thoughts on the topic. And now other editors actually want to use SMW and I'm playing catch-up. Hence my list of challenges was kind of a drive-by info dump. And now going back and writing the how-to content which I should have done six months ago.

For Gains in particular. If you have ideas for how to tackle the various challenges, then go right ahead. I'm just writing down some notes about what you might encounter. Personally, I don't see a use that makes the effort/reward ratio worthwhile. Automatic EPA calculations just seems infeasible. Free text seems the only thing you can store, but I don't have an idea for something useful to do with it (whereas I have a specific plan for Challenge Info).

- PSGarak (talk) 02:21, 2 February 2022 (UTC)

Font templates on staging

Hi PSGarak,
I saw you were working on the Font templates on staging. I've been looking at centralising those for a while, and have created a prototype at staging:Template:Font, with the stylesheet at staging:Template:Font/styles.css. This has the nice benefit of making it easier to invoke. --Asarta (talk) 12:16, 3 February 2022 (UTC)

You go ahead with your updates. I'm a novice at CSS and mucking with those templates was an exercise in yak-shaving, to try to get SMW to display something easily. It ended up not working anyways (the strip marker for the stylesheet doesn't get removed).

You'll find I put some of my work into prod. Go ahead and pave over what I did with FATE and HALLOWMAS. They are tied in a bit to {{Restrictions}}, but don't worry about breaking it. It's not used anywhere and I will have to redesign it anyways.

As a meta-comment, I'm looking forward to having the Forums. It will be nice to have a place to put ideas for feedback when they're too half-baked for a blog post. PSGarak (talk) 17:05, 3 February 2022 (UTC)

Yeah, I hope for the day of Forums (which should be coming), mostly so we can stop having the dual structure of the Discord except when it involves SMW and we all trudge to this page to consult with the seer of SMW --Asarta (talk) 17:31, 3 February 2022 (UTC)

Warplan

Hi PSGarak,
I just came across your warplan calculator — thanks for making it, it's very helpful! I was wondering if it'd be possible to add alternating row colors/column colors, or maybe freeze or float the headers. Since the tables do get rather large, it gets a little challenging to navigate them when you're in the middle of a stage. Try.else.finally (talk) 02:40, 4 April 2022 (UTC)

That's an excellent suggestion, thank you. I agree, those tables get a bit beefy. I'm far from an expert in CSS, but I'll see what might be possible. PSGarak (talk) 13:21, 4 April 2022 (UTC)

Follow-up to SMW Bug

Just poking you here to let you know that I seem to have resolved the issue you reported nearly two months ago - see here. Alan (talk) 05:46, 17 April 2022 (UTC)

New Survey

I would like to know if there's anything glaring you'd like to change, or if there are other questions you'd like to include here: https://forms.gle/yZGJkUFAeLaaVGct6

I know I mentioned wanting some more self-reported usage data, but some of that was already covered in the previous survey, and I wouldn't really know what other specifics we would find useful.

I would add a paragraph at the front about the organization of the survey, because I was a little confused I started going through it. It looks like it's one page per feedback item that was addressed? I would state that more clearly.

Some players may not know what the heck Discordant Studies are, or what the ban on its content is about.

I think the improvements to Calculators might be worth including. The appearance & functionality improvements are substantial, and I think at least a handful of Yesterhumuler's grind calculators have landed into guides. My Parabolan Warfare calculator is still beta but I hear through the grapevine it has some usage as well.

In terms of usage, here's what I would ask about.

• What's the type of information you look up most on the wiki? E.g. action or storylet details, item/quality details, comprehensive source/use lists, player-created guides.
• How do you find the information you're looking for? E.g. type search terms, search with copy-pasted game text, navigating by clicking in-text links, navigate by using categories, save bookmarks of guides or hub content.

Those are are off-the-cuff thoughts. Surveys are not my area of expertise, but I could try and massage those into a more survey-y form if you would like. PSGarak (talk) 19:41, 22 April 2022 (UTC)

Thanks, I've made some changes in response to what you mentioned. TFF (talk) 13:34, 23 April 2022 (UTC)

Your pronouns

May we ask if you are a lady or a gentleman?

• [ ] A lady
• [ ] A gentleman
• [ ] My dear sir, there are individuals roaming the streets of Fallen London at this very moment with the faces of squid! Squid! Do you ask them their gender? And yet you waste our time asking me trifling and impertinent questions about mine? It is my own business, sir, and I bid you good day.

(For real though: you often end up getting mentioned on the Discord as one of our most prolific editors and the go-to authority on SMW knowledge. People usually default to using "they" or "them" when talking about you, for lack of knowledge about your correct pronouns. Would you like us to change that? (although it goes currently give you a mysterious flair of éminence grise :p)) -- RagCall (talk) 11:34, 7 August 2022 (UTC)

I generally don't volunteer personal information about myself unless I'm asked, but I'm fine with you asking. Offline, I'm a he. Online, I rather like the idea of being an anonymous collection of bits which is assumed to relate to a real-world identity only due to lack of alternative explanations. I'm content with the undefined "they" but don't have strong feelings about it. PSGarak (talk) 03:22, 8 August 2022 (UTC)

Philosofruits content

Hullo! I'm sure it's just a momentary oversight but card names and branch titles are also generally considered Fate-locked content and are usually replaced with their images for the purposes of a guide (like on Flute Street (Guide))! Didn't wanna break the flow, hence the message! CarrONoir (talk) 22:28, 18 November 2022 (UTC)

Alright, thanks for pointing me to precedent. I know we have guides for Fate content now, but didn't know the exact contours. Apologies if I've made more work for someone to edit the history.

I'll try and make the updates tonight, but if I don't I probably won't have time to get to it until Monday. PSGarak (talk) 02:31, 19 November 2022 (UTC)

ID parameter and eager editors

Hullo! The seemingly unnecessary checks in the recent template stuff are because many editors like to include the ID parameter even if it's left empty in which case it counts as empty string and won't trigger the default option. Good ol' #if has no problem with either though! CarrONoir (talk) 16:33, 12 September 2023 (UTC)

Gotcha. I thought there was some obscure edge case where they behaved different, but for some reason that very non-obscure one didn't occur to me. PSGarak (talk) 17:56, 12 September 2023 (UTC)

Item modules

Hullo! Quick note, Module:Item is retired, the stuff it did now lives at Module:ItemEffects (in upgraded form with some extras). CarrONoir (talk) 19:15, 21 March 2024 (UTC)

Ah, good to know! PSGarak (talk) 02:12, 22 March 2024 (UTC)