User talk:RagCall

Welcome

Hi, welcome to the Fallen London Wiki! Thanks for your edit to the Template:Cartography 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) 08:13, 22 September 2021

SMW Economy Properties

The list of properties on {{Economy Properties}} looks rather daunting. I'm wondering if we can tame that complexity by using Record Types. So e.g. Surface Blooms, rather than having two properties Bazaar Sell=2.5 and Upper Sell=3, we would set a single compound property twice like this: "Sells for = 2.5e;Bazaar" and "Sells for = 3h;Upper River Exchange."

This doesn't solve everything. The Bone Market has its own layer of complexity. And there's a whole pile of issues around items which sell for other items (e.g. Memory of Light sells for 25 x Cryptic Clue). But it seems a little more elegant than defining a new set of properties for every shop. Let me know if this sounds helpful or if I need to explain this in more detail. PSGarak (talk) 19:29, 15 December 2021 (UTC)

Hm. That does sound easier, yes. Let me see if I understand this correctly. Let's say we want to do it that way on Surface Blooms. So we would need:

• a [[Property:Buys for]] Property:Bought for which has [[Has type::Record]] [[Has fields::Number;Currency;Shop]].
• a Property:Sells for which has [[Has type::Record]] [[Has fields::Number;Currency;Market]].
• a Property:Currency which has [[Has type::Keyword]] and can have the values e, h, r, and k for echo/hinterland/rat market/khanate respectively, and probably other stuff as well
• a Property:Shop with [[Has type::Page]] which would ideally be set via {{Shop}} and also have a Property:Market
• a Property:Market which would have values like The Rat Market (Area)/The Echo Bazaar!/Khaganian Markets/Upper River Exchange

Then the template {{Item}} would assemble these entries from the

• |Buying/Selling = -/2.50
• |Upper Buying/Selling = -/3
• |Rat Buying/Selling = 25/-
• |Rat Shop = Extramurine Trading Company

entries of Preserved Surface Blooms. So in our example, we would generate:

• [[Sells for::2.50;e;The Echo Bazaar!]]
• [[Sells for::3;h;Upper River Exchange]]
• [[Buys for::25;r;Extramurine Trading Company]]

Does that sound like what you had in mind?

Can we still query the different properties separately? E.g. would this allow to #ask for "all items which can be purchased with h" or "items that cost at most 10 r"? -- RagCall (talk) 20:09, 15 December 2021 (UTC)

Yes, that's very close to what I was thinking. I hadn't considered the relation between Shop and Market, but that looks useful. The one other thing we might consider is that Property:Sell price could have type Quantity instead of Number. This would let us define Echoes, Scrip, Shillings, etc as Custom Units. This has some trade-offs and I can't say with confidence that it's the best choice, but it's an option. Regardless of whether we model the price as a number or quantity, we would probably still want to have Currency as a separate field.

We would be able to query the properties separately or jointly. "Items that can be purchased with h" would be [[Buys for.Currency::h]] or [[Buys for::+;h;+]], and "items that cost at most 10 r" would be [[Buys for::<=10;r;+]].

We're currently using record types for Property:Has effect, which records item bonuses. Queries against that property are in Module:ItemList. Probably the most complicated query actively used is something like [[Has effect::Dangerous;<0]] and friends to make the tables on Stat-reducing items.

- PSGarak (talk) 20:45, 15 December 2021 (UTC)

Thanks. Could you elaborate on the tradeoffs re: custom units? -- RagCall (talk) 22:20, 15 December 2021 (UTC)

I'm trying to remember what all of the drawbacks are. It's been a while since I read that corner of the documentation, and I haven't taken it for a test spin yet.

The main drawback is that the value you set gets converted to the "main" unit before it's recorded. So if you set that Surface Blooms have a sell price of 3H in the Upper River Exchange, that would get stored as 1.5E (depending on exchange rate). The fact it's denominated in Scrip vs Echoes is something you have to store alongside it. Which, I guess, is what we're already discussing doing anyways so it's not a huge loss. But it also means we're not really gaining anything in terms of representation. Just the ability to easily query for items based on value-in-echoes, even if it sells for Scrip or whatever.

I'm also not entirely sure how to change which unit is output when the quantity is a field in a record. I know how to change the units for printouts when they're a regular field, but not part of a record. PSGarak (talk) 03:04, 16 December 2021 (UTC)

If I extrapolate from today's attempts, the above probably won't work. SMW won't let me define a property as having [[Has type::Market]], because it is not a built-in type. I have kinda been hacking around that using a Type:Record with Has fields:Market, but am less than pleased with that. I feel like I am missing something. What I would like to have is Property:Market having validators (allowed fields) and the other two properties would automatically check against those very same validators without needing to duplicate them on each page. Programmatically speaking, I would like to have Market extends Page and properties Market isInMarket and Market hasMarket. Can that be done? Feel free to edit my attempts at Property:Market, Property:Is in market and Property:Has market if you feel that would be faster than explaining. -- RagCall (talk) 19:07, 18 December 2021 (UTC)

It took me a little bit, but I think I understand what you're trying to do now.

It's possible to have Property definitions use Templates or other Transclusion strategies. The SMW docs page about Help:Custom units mentions this in passing. If Property:Allows value works the same way, then it ought to be possible to include that via template. Or use #lst to transclude it from one property to another.

One question I have is: What's going to be the Source of Truth for the list of allowed markets? Are we expecting editors to update Property:Market every time a new Shop tab is introduced? That's possible, they're not very common. Another option would be having it populate automatically from a SMW query based on either categories, or [[Has Game Type::Market]] (currently working on getting that to work).

Actually come to think of it, if #ask queries work in a property definition then you could literally include the list of allowed values from one property to another with something like the below:

{{#show: Property:Increase Type|?Allows value|template = ????}}

- PSGarak (talk) 19:45, 18 December 2021 (UTC)

I will reply to the other thing later when my brain is more... alive, but yeah, I had intended the single source of truth would be Property:Market. We only have 4 markets, after all, and I expect we would have to update the list of allowed values maybe twice a year? But that was just my plan so far, and I am also curious to see what you come up with. -- RagCall (talk) 20:20, 18 December 2021 (UTC)

An unexpected mishap in my model: putting "no" in the value of Property:Has market links to No *facepalm* I suppose that will have to be taken care of... somehow. In the templates working with the property, probably. -- RagCall (talk) 21:59, 18 December 2021 (UTC)

So, over on staging, the following is live:

• staging:Template:Item now uses a new staging:Template:Transaction to generate the different buying/selling tables. This avoids code duplication quadruplication in Template:Item.
• Template:Transaction sets properties staging:Property:Sells for and staging:Property:Bought for.
• Those in turn use staging:Property:Price, staging:Property:Currency, staging:Property:Shop/staging:Property:Market as discussed above.

Things that still have minor issues:

• currently, some item pages display the price in echo even though you cannot buy them with echoes - for example, the lodging keys, Cave-Aged Code of Honour, etc. I am not sure how to handle that most sensibly. Note that using Custom Units to translate the value of those into echoes doesn't really solve this, because the factor for selling and buying is not the same. (e.g. Key to a Lair in the Marshes is valued a 6 E, whereas the actual cost is 300 Rats valued at 0.01 each). We could either
  • introduce an optional "echo value" parameter, which I think is not ideal
  • just be rid of the echo price in those cases (which is my preferred solution)
• Items that use Memory of a Tale as currency (except A Brick from the Very Walls of Hell) throw errors at the moment - that is easily fixed via text replacement. (That also needed fixing even before the template changes, because right now, they display echoes as currency); I am not terribly sure about the display of price, though - should we also use an icon there?
• the Firkin of Hesperidean Cider has trouble with the space in the price. Several solutions come to mind, one of which is simply stripping spaces from the number before entering it into SMW.
• not sure if we should go with "(no message)" or empty string as default for purchasing/sell messages.

While I tweak those: does anyone have any additional input before this goes live on the main wiki? -- RagCall (talk) 17:31, 8 February 2022 (UTC)

Nice work, looking great! Definitely good to see the template size drop by four thousand bytes while adding functionality.

I would also be in favour of removing price-equivalents. But if we keep them, then standardize on sell-value. It's just confusing that the Code of Honour displays sell-equivalent while the Key to the Lair displays buy-equivalent. (Yes, I get that it's displaying the price to buy the rats. But I wouldn't buy them, I would farm them!) I also agree that Custom Units will not easily solve things, there's a bunch of edge cases that start getting out of hand.

For Memory of a Tale, what's the current approach for items that are bought for Hinterland Scrip, Khaganian Coins, or Pearls (e.g. lightbulbs in the Khanate)? There are other items whose buy price is denominated in non-echo items, I think we just stay consistent with that. If that means a Tale icon, I think that's reasonable.

I believe our current practice is that "(no message)" is set explicitly, while being blank signifies that no one has tested it yet. Whatever the exact solution is, I would want to continue to be able to distinguish between "unknown" vs "known to be blank."

Do we expect the Shop/Market pages to become auto-generated based on this data? PSGarak (talk) 18:32, 8 February 2022 (UTC)

@ price-equivalents: Thanks for the input, I will ask more opinions on Discord. And yeah, same on the rats. We also usually value actions by sell-value (in e.g. EPA calculations).

@ Memory of a Tale: the other currencies display just the icon. Memory items on the other hand currently say " 3 x Memory of a Tale" (see e.g. Benvolio the Bacon Thief). I am a bit concerned that for specifically, people might think it means Proscribed Material instead. But maybe I am overthinking.

*sigh* That wish is reasonable, it just means I will have to look again into how to differentiate between "set and empty" and "not set" in templates.

In the same vein, do you perhaps have an idea how to handle setting the value for "no market is accessible" for the Market parameter in {{Places}}? Currently, Market is configured to be a page, but, unfortunately, putting in "no" points to the Action in the Nadir. And I would also like to be able to differentiate between "tested and not accessible" and "tested and known to be unaccessible".

Yes, I would like to rewrite {{Shop Inventory}} for that. I would however like to wait with that change for a few days to make sure we are not relying on broken data. Why? -- RagCall (talk) 12:38, 9 February 2022 (UTC)

Re: Memory of a Tale: I don't think it's such an issue, at least not one that will cause significant problems. Proscribed materials are not a common currency, I think anyone confused by it would check either the wiki or in-game L&F market and find what currency is actually being used. Worst-case, someone spends 0.96 to buy banned books from the Bazaar. If needs be, we could make a new distinct icon thingy.

Is {{Places}} still causing that issue? I fiddled with the template back in December, and No currently doesn't report any incoming properties. In general, it's just a matter of deciding some sentinel value and special-casing it. Not the most elegant, but it works. For sell messages, I might consider having the value "no" expand to (no message).

No particular reason for {{Shop Inventory}}, just curious since it seemed like the lowest-hanging fruit for the data. One issue I could foresee is sorting, and keeping the table order to match the game order. But in practice I think the game itself actually sorts by quantity, irrespective of unit (e.g. Midnight Market), so it's easy to replicate.

- PSGarak (talk) 15:30, 9 February 2022 (UTC)

Deletion of wrong jpeg

Hello! Sorry that I uploaded Bandedcousin_promo.jpg earlier by mistake. Could you help me delete it? Thank you! (Didn't mean to mess up the wiki :( SevenPlath (talk) 13:06, 24 February 2022 (UTC)

It's no problem, you haven't broken anything (it's also very tough to actually permanently break anything here). I also, wasn't too sure myself (particularly as the fate page didn't show the new icon for me until I did a hard browser refresh, so I couldn't see the icon until then).

Just put {{delete}} on the file page - in this case, someone has already done it. An admin will come along and delete it later.
Thank you for making that article! -- RagCall (talk) 13:39, 24 February 2022 (UTC)

About Discordant properties

Hullo! Just wanted to mention that there was already a debated whether Discordant Studies - Costs and Rewards (Guide) should assign Gains/Losses. (Specifically in these comments.) Although it might be worth revisiting the issue! CarrONoir (talk) 14:18, 6 April 2022 (UTC)

Thanks for the link, I had not seen it at the time. I had read the page linked in the header and came away with the understanding that they do not care about the mechanical rewards being published, and that it's about the puzzle solutions.

I do believe it is worth bringing up, for the source of Veils-Velvet alone (I don't care about the odd secondary reward, and while I would like to see the other stuff properly SMW-ized, I am fine with that not being the case). -- RagCall (talk) 15:27, 6 April 2022 (UTC)

I'm with you about the letter part, I just liked @Mzs's reasoning. This restricting is very similar to Enigma. What the situation is also similar to is Exceptional Stories! Think about it, they also give minor items which we don't record simply because they're just too out of the way. Sure, we record all actions but those are in the "main" game.
I get the archivist calling too, but we do keep it safe on that guide page should we ever need it! Maybe not showing another weird gain option to mundane items like Cryptic Clues to confuse readers is a good thing (or at least until we sort out those massive gain lists).
The Velvet is fair game, I think. It's sough-after and has very few sources! (Another similarity to how we usually record special Exceptional Story rewards!) CarrONoir (talk) 00:00, 7 April 2022 (UTC)

Attar

Hey, just figured I'd call your attention to this edit by RagnaBot: [1] Aximillio (talk) 14:58, 2 July 2022 (UTC)

Thanks, I saw it earlier. Pretty sure that was human error on my part. -- RagCall (talk) 16:17, 2 July 2022 (UTC)