Structure Skin & Cosmetic Base Classes
Note: There are 2 types of custom cosmetics now: functional (contains graphing) and non-functional (no graphing, opens to defaults). Non-functional custom cosmetics will get whitelisted automatically while functional custom cosmetics will be manually reviewed. Due to this, we wanted to provide a robust framework to eliminate as much need to graph as possible (some of the new functionality is also intended to ease creation of functional cosmetics, the intention isn’t to force people into non-functional cosmetics, skins benefit from this as well).
There are now 4 skin base classes (also cosmetic bases that inherit from these):
1.) StructureSkinBase - new base class for all skins, contains all functionality so all skins have access to the same features & provide a consistent user experience. This should only be used when making a skin that doesn’t add components like the following bases do.
2.) StructureSkinBase_SingleSwap - this is for skins that put the same components on one or many structures.
3.) StructureSkinBase_Stack - this is similar to single swap in that it applies the same components to one or many structures but has multiple levels of components (eg table and items on the table), additionally, levels can be dependant on each other (ie if you change the table with a new table that has a different height, the items on the table will adjust height) or not (ie changing the chairs around the table shouldn’t cause the items on the table to change height).
4.) StructureSkinBase_MultiSwap - this is for skins that put different components on specific structures (ie tileset skins where you have unique components for each structure).
New Features
1.) Mesh Handling - Choose to show or hide the structure’s original meshes (ie adding functionality to a structure probably doesn’t require changing its mesh). Hiding the mesh also handles placement, where the original meshes will be hidden when placing the skin and the original mesh will be used as the preview hologram when removing the skin.
2.) Rotation - Choose one or more axes of rotation, multiuse entries will be created automatically.
3.) Scale - Only uniform scaling, multiuse entries will be created automatically.
4.) Shared Data - It’s difficult for multiple classes to work with the saved skin data since it’s only arrays (eg if we save rotation in the float array, then all mods will have to work around that). There are now some data handling functions that turn the string array into a map (there are functions for saving float arrays and strings if you want to store your data another way).
5.) Shared Timers - Since there are only 2 timers for skins (looping and non-looping), it is quite easy for a child to stomp a parents timer. There are now key based timer access functions so that multiple classes can work with a timer seamlessly (note: this only uses the non-looping timer so mods are free to use the looping timer normally).
6.) Shared Settings Multiuse - With multiple options on the base skins & potentially more on mods, the multiuse menu can get cluttered pretty quickly. Instead settings are put into a common Skin Settings category that is created dynamically if there are any settings.
7.) Inventory Access - Skins can now access the first item on containers inventories (eg weapon rack mod). By default this only works on containers with max 1 inventory items (eg decor box) but can be overridden if you want to work with other containers.
8.) Helper Actors - These allow you to do things that skins can’t do themselves (eg tick events, volume triggers, etc).
9.) Multiple Mesh Components - Skins can now add as many mesh components as they want.
10.) Material Overrides - Skins can now also override materials and material parameters.
11.) Particle Systems - Skins can now add particle systems & parameters (doesn’t require a mesh, can just add a particle system by itself).
12.) Variants - All skins now support variants which contain all the data of normal skins such as multiple meshes, material overrides & particle systems (setup varies based on base, this is an example of a stacked base with variants but could also do something like a tileset skin with multiple variants for each tileset piece).
Additionally, all BP settings are now in the “Skin Settings” category & all native settings are in the “Structure Skins” category.
All functions have been categorized into Override (children can use these to change behavior or receive callouts), Internal (most users would have no reason to override these) or Utility (not meant to override but used to perform actions/get info).
