User talk:Vox Serico
What's going on?
I'm reworking the way item (block/component/etc...) pages are handled into something that should be easier to keep up to date and easily queryable using Semantic-MediaWiki queries and properties.
If you look at the source of Assembler for example, you'll see the Itembox template with a long list of arguments. Most of these arguments are in duplicates for both the small-block and large-block version, as well as few that aren't even related to buildable blocks. A single page is actually representing two (technically different) blocks. The issue is further compounded by each language translation for the same block (e.g. Assembler/de). The block's properties are once again defined where they'll quickly become far outdated from receiving less attention. This should've been solved by having only one copy of the block's properties being referenced with inline queries instead of being manually input multiple times over, once for each language.
The fact that a single page also defines two different blocks makes producing formulas and automatically computed tables (e.g. Thrusters#Overview) difficult and overly complex because you'll need to switch between pairs of properties (like lforcemagnitude and sforcemagnitude) depending on whether you need the large or small version, assuming it exists, instead of a querying a single property forcemagnitude that could work for both.
What I'm proposing is instead a single-language "properties page" for each small-block, large-block, tool, component, ingot, and ore. (Presumably named after its subtypeid from the game files.) This page can then have its data automatically referenced from any other page that would want to display it. A simple example would be very much like the current Large Hydrogen Thruster page, the "Large ship/station" and "Small ship" blocks function identically and can both be described on the same page, displaying an "info box" (Itembox / Componentbox) for both. A more interesting example would be a single Component page describing every component under a separate header with its own infobox, instead of splitting them up over multiple tiny pages. This is currently not possible as defining the same property twice on a page adds the value to the existing property, much like categories work. This makes a specific value difficult, if not impossible, to retrieve reliably. The alternative would be defining several different properties, one for each item; and that's how you end up with this mess we have now of having 6 different mass properties instead of a single Mass property for all types.
--Vox Serico (talk) 22:36, 31 March 2020 (UTC)
What to do about refining stone?
The templates and semantic queries for handling the refining tables are neat... but they don't handle Stone very well. Specifically, it's most useful to breakdown the ratios of the products, and the current framework doesn't handle that well.
I could see extending the template, or maybe using a different template for Stone... WDYT?
