Template talk:Radial size

0. Reserve

1. XS - Extra Small

2. Reserve

3. S - Small

4. Reserve

5. M - Medium

6. Reserve

7. L - Large

8. Reserve

9. XL - Extra Large

10. Reserve— Preceding unsigned comment added by Darkfrei (talk • contribs) 16:25, 10 July 2014‎ (UTC)

What exactly is the point of this list? It is also possible to add sizes between already existing. E.g. a size between large (2) and extra large (3) would be 2.5 and then a size between that new one and extra large is 2.75 and so on. Also the current values correspond with the numbering system by Squad like Mk2 to size 1 Adapter. — xZise [talk] 16:22, 10 July 2014 (CDT)

Squad has now changed it to Mk2 to 1.25m Adapter. --Brendan (talk) 21:46, 2 March 2015 (CST)

Numbers and Names

Continued from Template talk:Stats Table Cargo#Roman numerals and tank comparison

This template is for filling a |size= line inside of any Infobox/Part template with a code that can stay the same, even if Squad totally changes the in-game name or dimensions of parts, and just change the plaintext conversion of the code as needed.

Objections exist to the current plaintext Text column names “Tiny, Small, Large, Extra Large”. There are a set of Short codes based on these names; logically, they should change if we change the Text names. Such a change would require a bot job to be created, or a lot of manual work; neither of which I find good reasons not to improve the wiki.

There is also a Number code, referring to the size codes used inside of game files for round parts. Recently I extended the number metaphor to Mk2 and Mk3 sizes with roman numerals ii and iii. Mk1 currently coincides with "Size 1" aka "Small", (though maybe it won't always?) and Mk1 parts have thus been left as |size=1. There has been objection to this extension.

There are two goals

1. Select a uniform set of codes for the wiki's templates which are logical, easy to use consistently, and can remain independent of in-game names, and which translate to plaintext names that can be changed as needed through this template.
2. Decide on the best plaintext names for sizes.

--Brendan (talk) 21:27, 2 March 2015 (CST)

I side with Number, as the Short codes would change with any potential changes in either the scaling of parts or names. Admittedly, the risk at this point is not great, but why take the risk?

For Text, there are currently metric diameters to the radial sizes of parts. According to Radial_size#Assets there is a rescaleFactor of 1.25, but in-game there are references made to the scaled-up sizes. So, diameter-based radials has a solid basis.

My issue with it is that one could think the radius of the parts equals that “Radial size”. I'm not sure why we call them “radial” sizes here at all! I think the better term is Node size. It's only used with parts that have nodes! And consider this from CFG_File_Documentation#Node_Definitions ...

The last value indicates the visual size of an attachment node. Values may be either 0 (small half-meter node), 1 (normal), or 2 (large). This parameter is optional and will default to 1 if nothing is specified.

My suggestion is:

1. Use the metric diameters for the plaintext
2. Change Template:Infobox/Part/Parameters to read Node size instead

--Brendan (talk) 21:34, 2 March 2015 (CST)

Hmm the node thing has something to it, but is then problematic with Mk* parts as they have normal nodes but their shape at the nodes is not equivalent to the “standard”. But maybe we should split (like it seems you suggest) the parameter and list the nodes (something like “X× node 0, Y× node 1”) and then have a separate “shape” or diameter parameter. — xZise [talk] 07:25, 3 March 2015 (CST)

Yes, "node" doesn't describe all parts well. How about Attachment Size? That is the defining function we're concerned with. It would be great if there were a way to make it plural when there is a |size2= present. And I second the addition of counts to how many of a given size there are, like on tri-couplers!

As for shape, I think we can safely leave it off. Having two parameters adds complexity but I question that it adds real utility. By and large, the node sizes match the visual sizes, and parts with the same cross-section line up visually. Also, any two nodes can be joined regardless of size or shape, so noting the node size separately doesn't tell you anything about limiting factors -- it's purely aesthetic. --Brendan (talk) 01:29, 5 March 2015 (CST)