102.1 — Blueprint size

This continues from 102 — Blueprint merge, with additional details regarding blueprint size values.

There are many values that control a units 'size'. This article covers them primarily from the perspective of a structure. Mobile units are largely the same, but have some key differences and restrictions, which will be addressed separately.

Supreme Commander uses XZ as the flat plane, and Y as height. As with all similar systems, X is across. You can use the fact that the glyph 'x' is a cross as a memory aid. 0,0,0 is in the top left corner from the players plan perspective with positive values extending down and to the right, with positive Y extending upwards.

For size context, a standard tech 1 wall is 1x1, but better visualisation options are available.

Collision

You can visualise this section in game with the debug cheat ctrl-alt-shift-c which displays collision boxes and spheres.

Note:

The collision positions only update 10 times a second, so fast units will need larger than normal values for enemies to consistently be able to target them correctly.

Unit collision size, shape, and position is controlled by the following blueprint values; these are the default values if undefined:

CollisionShape = 'Box',
CollisionOffsetX = 0,
CollisionOffsetY = 0,
CollisionOffsetZ = 0,
SizeX = 1,
SizeY = 1,
SizeZ = 1,

The most impactful among them is CollisionShape, which is almost universally omitted, and can also be 'Sphere' and 'None' on top of the default 'Box'. The collision centres on the unit origin in the XZ plane, and extends upwards from the origin on the Y axis.

The Size values represent "diameter" values. If 'Sphere' is selected only SizeX is used. The Offset values shift the whole collision shape in those directions. They can be decimal values.

Important note:

The self:SetCollisionShape( method functions differently; instead it takes radius values and centres on the unit origin in all 3 axes. The arguments that method takes are in the same order shown in the example. Aircraft use this method to define their collision when they finish being built, and use the blueprint value SizeSphere to determine the sphere radius instead of SizeX. In situations where you want to return a unit to its starting collision size, use self:RevertCollisionShape() instead.

Footprint and skirt

You can visualise this section in game with the debug cheat ctrl-alt-o which shows grid lines and path blocking, and entering command mode by going clicking to build a structure.

In the example below we'll be using the footprint of buildings such as factories tech 3 generators artillery, and more, outlining the values that define it, what each value controls, and how they all combine together.

Footprint and skirt are controlled by the following unit blueprint values:

Footprint = {
    SizeX = 5,
    SizeZ = 5,
},
Physics = {
    SkirtOffsetX = -1.5,
    SkirtOffsetZ = -1.5,
    SkirtSizeX = 8,
    SkirtSizeZ = 8,
},

Footprint.SizeX and Footpring.SizeZ control the area that a structure blocks with regards to the pathing of mobile units, represented by the green box on the diagram. They should be integer values, and will round if not. If they aren't defined, they fall back to rounded versions of SizeX and SizeZ from outside of the Footprint table.

Physics.SkirtOffsetX and Physics.SkirtOffsetZ control the offset of the skirt. Shocker. Both of those two pairs off numbers offset from the same origin point, represented by 0,0 on the diagram. This is why offset is generally negative. Physics.SkirtSizeX and Physics.SkirtSizeZ then start counting from where the offsets left them, represented by the green outline.

An important thing to note is that most structures have offsets ending in .5. You'll note on the diagram that the green outline is between gridlines. This is true of everything except walls and tech 1 turrets, and virtually guarantees that mobile units will be able to path between them.

Selection

You can use the debug shortcut alt-v to show bounding boxes (and bones) to get an estimation of the starting selection mesh size.

There are two groups of values that affect selection; one affecting the area that you click to make the selection, and one affecting the visual effect when you make the selection.

The physical size of the area you click is based on the following values:

SelectionMeshScaleX = 1,
SelectionMeshScaleY = 1,
SelectionMeshScaleZ = 1,
SelectionMeshUseTopAmount = 1,
SelectionYOffset = 0.5,

You are unlikely to actually need these in the blueprint; a units selection mesh is based on the bounding box of the actual unit mesh with these values, except SelectionYOffset, applying normalised multipliers on top of that. They are most commonly used with units that have large support structures, such as the naval factories; especially the UEF one, where the support legs would cause the selection area to be way larger than the main body of it. SelectionYOffset in theory shifts it up and down, but in practice this isn't that useful.

What you are likely to need is a subset of the following, which affect the highlighted area when you have a unit selected:

SelectionCenterOffsetX = 0,
SelectionCenterOffsetY = 0,
SelectionCenterOffsetZ = 0,
SelectionSizeX = 1.4,
SelectionSizeZ = 1.4,
SelectionThickness = 0.8,

The CenterOffset values are pretty self explanatory; shift the blue outline in those directions. The SelectionSize values are effectively radius, but with how it's set up; defining a plane with mostly transparent images rendered to it that don't extend all the way to the corners, you'll need to experiment. Start with slightly more than half the footprint size values, and edit them with /diskwatch. Same with SelectionThickness, which defines how thicc the outlines are.

Set thiccness to taste.

SelectionSizeY technically exists and is read by the engine, but appears to have been for a previous selection effect that was actually 3D.

Life bar

The size and position of the life bar, and other attached bars such as shield and work progress, are based on these values:

LifeBarSize = 2,
LifeBarOffset = 2,
LifeBarHeight = 0.075,
LifeBarRender = true,
Display = {
    HideLifebars = false,
}

Yes, there are two different ways to hide life bars. We may never know why. Both work, and you can exclude both if you want the bar to appear, and you only need one of them to hide them; having both is pointless. LifeBarOffset determines how far away from the units origin on the Z axis it should display, LifeBarSize determines the width. It should be a positive value. LifeBarHeight is how tall the bars are. It will look super weird if you use anything other than 0.075 for this, which is the value all default units use.

Build effects

For UEF and Seraphim, build effects use the following values:

Physics = {
    MeshExtentsX = 1.3,
    MeshExtentsY = 1.7,
    MeshExtentsZ = 1.3,
}

Similar deal as with collision size, except entirely cosmetic, and much less important. These are handled in the Lua, so it's not a hard and fast rule, but in general, if they aren't defined, they use the footprint values for X and Z, and a guess for Y.

Physical mesh

Oh also Display.UniformScale sets how big the actual mesh renders. How big or small this needs to be is based entirely on how big the mesh is in an editor. It's entirely arbitrary, and I can give no real advice for it; test and adjust.

Thought I'd mention that one last 'cause it's the hardest to miss when it's set wrong.