Buildable Definition
Last updated
Last updated
Buildable Definitions is where you set up the data and functionality for your buildables and proxy actors.
To create a Buildable Definition head to the Content Browser -> Misc -> Data Asset -> Buildable Definition.
You should then be presented with a class when opened which looks like this:
The Generation Category allows you to the creation of some of the parameters within the Buildable Definition helping speeding up the creation of a new Definition.
Generate Material Data will create material data for the Overridable Materials Array. This should only be used if you plan on overriding the materials of your mesh within the buildable.
Generate Socket Data: Will create the sockets based on your developer settings and the sockets that has been set up within the developer settings. It is highly recommended you use this feature for all of your definitions as it will save you a lot of time.
Initialize Default Data Will populate your definition with the default data based on your project settings, such as Post Build Events, Placement Conditions etc.
Owned Tags defines what this buildable is. In our example below we've defined this buildable as a Foundation type and gave it the material type Wood. This allows us to easily identify what type of structure this is by querying these tags from the outside, which can further enhance gameplay interactions if needed.
Name: The name of the buildable
Mesh: The mesh used for this buildable. When choosing a new buildable the sockets will be reinitialized.
Buildable Class: The class spawned upon placing a buildable
Material Overrides: Here you can override the default materials on the selected mesh. Clicking “Generate Material Data” will generate this data for you to edit easily.
Actions can be used for activating specific behavior on a buildable. Actions will be covered in a later section.
Tag Qualifier Conditions allows you set up conditions for when a tag will be added to the Buildable. The plugin comes with a range of different conditions already predefined which will allow you to customize when a buildable will receive a specific tag, such as a pillar functioning as a Foundation when placed on a foundation or overlapping with parts of the environment.
Dependencies determines when the buildable will become destroyed. A dependency example could be a range based check where the buildable needs to be within a certain range of another type of Buildable. For example, maybe you want to make sure that a ceiling can only be placed within a range of 4 from a buildable which is considered a foundation.
Sockets: This will be populated based on the mesh sockets, using the data set in the project settings. When snapping an object to a socket, the forward vector of the socket will be used. This means that when you snap a proxy to a buildable, the proxy and buildable sockets will be facing each other.
Socket Owned Tags: This is the tags which other sockets will connect to. Often times you would probably set a Socket Type Tag on these which other sockets can connect to.
Socket Name: This is purely for referencing the actual socket on the mesh this socket is referencing
Outbound Connection Tag: This defines the tag this socket will connect to.
Connections: You will find connections as a sub array of a socket. Connections allows you to have multiple snapped objects to the same socket, with rotation offsets. Connections are optional, and if you don’t add any connections then only one object can be attached to the socket, at the sockets forward vector. The Use Socket Connections needs to be turned on in the Project Settings to use them.
Proxy Behavior: You can create a template class of a proxy behavior for your definitions, this will speed up the creation of newer definitions of the same type, or in cases where different types would be using the same functionality on the proxy itself. For example, a wooden foundation would be using a Foundation Proxy Behavior, while a Stone Foundation would also be using a Foundation Proxy Behavior. However a wall, ceiling, and other generic types of definitions would be using a generic Proxy Behavior Template.
Trace Behavior Allows you to easily change the type of placement trace that will be applied to the proxy. An example of this would be that a foundation needs to be traced against the ground while a wall will just be traced to be floating in front of you.
Proxy Location Offset will allow you to modify the location on any axis after the trace has been completed. For example a foundation might need to be moved further down after the trace has been completed, setting the Z value to -150 would allow for a 300cm call foundation to be placed half its height further down.
Placement Conditions allows you to easily add different conditions for when something can be placed. This can range from anything such as type type of resources needed as well as if its overlapping with something to if it needs to be placed on an existing buildable or if it has been snapped etc. practically anything you can think of. You can add as many placement conditions to this list as you want, and mix and match as you need.
Post Build Events allows you to have logic run after the building has placed. Like placement conditions, this can be anything. If any of the default functionality isn’t enough, then you can either use any existing Post Build Events that comes with the plugin or create your own. This can range from anything from destroying a nearby structure to making sure that it has been properly attached to other buildable sockets.
Here you will be able to set up placement and removal sounds and visual effects for your buildable. These will play upon being placed, removed and destroyed.
In case you need a description and icon for your buildables for selection in UI, then you can add that here.
