Difference between revisions of "User talk:Vox Serico"

Latest revision as of 03:12, 23 February 2021

Useful links

Since userpages don't work, I'm sticking this here. --Vox Serico (talk) 03:12, 23 February 2021 (UTC)

Semantic-Mediawiki

Properties and types

Custom units

Special property "Allows value"

Inline queries

Help:Setting values using #set

Displaying information

Selecting pages

Archive:Template format

Mediawiki

Help:Templates

Help:Extension:ParserFunctions

Extension:Variables

Help:Formatting

Help:Magic words

Help:Tables

Help:Images

Help:Links

Wikipedia

Help:Template

Space Engineers Wiki

Special:Version

Special:Properties

Special:Browse

Special:AllPages

Mod:Vanilla

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?

D0sboots (talk) 23:16, 7 July 2020 (UTC)

Stone is the only crafting blueprint with more than one result. It was never taken into account when I overhauled rewrote Template:itembox into Template:SimpleItembox, as Stone only produced Gravel until recently.

Multiple results would be relatively simple if the wiki had access to array structures, but it's heavily out of date and doesn't have that feature. This is why there are several individually numbered component properties to imitate a list.

It is however possible to make pseudo-arrays using substrings on something like "Mod:Vanilla/Ingot/Stone;0.014;Mod:Vanilla/Ingot/Iron;0.03;Mod:Vanilla/Ingot/Nickel;0.0024;Mod:Vanilla/Ingot/Silicon;0.004". You would have to make a special case for such a string every time you want to reference blueprint results.

That would probably be the cleanest way of making it be queryable. But you run into problems once again: There are 3 different "recipes" for stone. Each has different results!

Definining the recipe in its base material is like saying that all Iron Ingots are crafted into Steel Plates.

What should have been done is for there to be a new class of pages, each describing a crafting blueprint. Every block or item would then link to this recipe page instead of listing its components in itself. It would be quite a bit of work, but it would also be the best representation of the game's mechanics. There can (and are) now in fact multiple recipes that produce the same end product.

If you don't care about making a nice data structure, you could define 8 more properties to handle the (currently) 4 resulting items and 4 resulting amounts. It wouldn't be clean, it would only represent one of the recipes, and you would still have to incorporate it as a special case for stone in every query.

For the moment, I would settle for writing the recipe details directly on the Stone page without any special properties.

    <Blueprint>
      <Id>
        <TypeId>BlueprintDefinition</TypeId>
        <SubtypeId>StoneOreToIngot</SubtypeId>
      </Id>
      <DisplayName>DisplayName_BlueprintClass_Ingots</DisplayName>
      <Icon>Textures\GUI\Icons\ingot\ingot_class.dds</Icon>
      <Prerequisites>
        <Item Amount="1000" TypeId="Ore" SubtypeId="Stone" />
      </Prerequisites>
      <Results>
        <Item Amount="14" TypeId="Ingot" SubtypeId="Stone" />
        <Item Amount="30" TypeId="Ingot" SubtypeId="Iron" />
        <Item Amount="2.4" TypeId="Ingot" SubtypeId="Nickel" />
        <Item Amount="4.0" TypeId="Ingot" SubtypeId="Silicon" />
      </Results>
      <BaseProductionTimeInSeconds>10</BaseProductionTimeInSeconds>
    </Blueprint>
    <Blueprint>
      <Id>
        <TypeId>BlueprintDefinition</TypeId>
        <SubtypeId>StoneOreToIngotBasic</SubtypeId>
      </Id>
      <DisplayName>DisplayName_BlueprintClass_Ingots</DisplayName>
      <Icon>Textures\GUI\Icons\ingot\ingot_class.dds</Icon>
      <Prerequisites>
        <Item Amount="100" TypeId="Ore" SubtypeId="Stone" />
      </Prerequisites>
      <Results>
        <Item Amount="1.4" TypeId="Ingot" SubtypeId="Stone" />
        <Item Amount="3" TypeId="Ingot" SubtypeId="Iron" />
        <Item Amount="0.24" TypeId="Ingot" SubtypeId="Nickel" />
        <Item Amount="0.4" TypeId="Ingot" SubtypeId="Silicon" />
      </Results>
      <Priority>1000</Priority>
      <BaseProductionTimeInSeconds>1</BaseProductionTimeInSeconds>
    </Blueprint>
    <Blueprint>
      <Id>
        <TypeId>BlueprintDefinition</TypeId>
        <SubtypeId>StoneOreToIngot_Deconstruction</SubtypeId>
      </Id>
      <DisplayName>DisplayName_Item_Gravel</DisplayName>
      <Icon>Textures\GUI\Icons\ingot\gravel_ingot.dds</Icon>
      <Prerequisites>
        <Item Amount="1" TypeId="Ore" SubtypeId="Stone" />
      </Prerequisites>
      <Results>
        <Item Amount="1" TypeId="Ingot" SubtypeId="Stone" />
      </Results>
      <BaseProductionTimeInSeconds>0.1</BaseProductionTimeInSeconds>
      <IsPrimary>true</IsPrimary>
    </Blueprint>

--Vox Serico (talk) 07:07, 8 July 2020 (UTC)