* Fix broken layer hiding on clothes with multiple equipment slots
* Refactor ToggleVisualLayers, HideLayerClothingComponent, and ClothingComponent to allow more
precise layer hide behavior and more CPU efficient layer toggling.
* Adjust HumanoidAppearaceSystem to track which slots are hiding a given layer (e.g. gas mask and welding mask)
Add documentation
Change gas masks to use the new HideLayerClothingComponent structure as an example of its usage
* Fix the delayed snout bug
* Misc cleanup
* Make `bool permanent` implicit from SlotFlags
any non-permanent visibility toggle with `SlotFlags.None` isn't supported with how its set up. And similarly, the slot flags argument does nothing if permanent = true. So IMO it makes more sense to infer it from a nullable arg.
* Split into separate system
Too much pasta
* Remove (hopefully unnecessary) refresh
* Fisk mask networking
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
* Keep old behaviour, use clearer names?
I'm just guessing at what this was meant to do
* english
* Separate slot name & flag
* dirty = true
* fix comment
* Improved SetLayerVisibility with dirtying logic suggested by @ElectroJr
* Only set mask toggled if DisableOnFold is true
* FoldableClothingSystem fixes
* fix bandana state
* Better comment
---------
Co-authored-by: ElectroJr <leonsfriedrich@gmail.com>
* Borg type switching.
This allows borgs (new spawn or constructed) to select their chassis type on creation, like in SS13. This removes the need for the many different chassis types, and means round-start borgs can actually play the game immediately instead of waiting for science to unlock everything.
New borgs have an additional action that allows them to select their type. This opens a nice window with basic information about the borgs and a select button. Once a type has been selected it is permanent for that borg chassis.
These borg types also immediately start the borg with specific modules, so they do not need to be printed. Additional modules can still be inserted for upgrades, though this is now less critical. The built-in modules cannot be removed, but are shown in the UI.
The modules that each borg type starts with:
* Generic: tools
* Engineering: advanced tools, construction, RCD, cable
* Salvage: Grappling gun, appraisal, mining
* Janitor: cleaning, light replacer
* Medical: treatment
* Service: music, service, clowning
Specialized borgs have 3 additional module slots available on top of the ones listed above, generic borgs have 5.
Borg types are specified in a new BorgTypePrototype. These prototypes specify all information about the borg type. It is assigned to the borg entity through a mix of client side, server, and shared code. Some of the involved components were made networked, others are just ensured they're set on both sides of the wire.
The most gnarly change is the inventory template prototype, which needs to change purely to modify the borg hat offset. I managed to bodge this in with an API that *probably* won't explode for specifically for this use case, but it's still not the most clean of API designs.
Parts for specific borg chassis have been removed (so much deleted YAML) and specialized borg modules that are in the base set of a type have been removed from the exosuit fab as there's no point to printing those.
The ability to "downgrade" a borg so it can select a new chassis, like in SS13, is something that would be nice, but was not high enough priority for me to block the feature on. I did keep it in mind with some of the code, so it may be possible in the future.
There is no fancy animation when selecting borg types like in SS13, because I didn't think it was high priority, and it would add a lot of complex code.
* Fix sandbox failure due to collection expression.
* Module tweak
Fix salvage borg modules still having research/lathe recipes
Engie borg has regular tool module, not advanced.
* Fix inventory system breakage
* Fix migrations
Some things were missing
* Guidebook rewordings & review
* MinWidth on confirm selection button
* split logic into own system
* add support for different size displacement maps
* some clothes may not use displacement maps
* displacement maps spport hand sprites
* Update DisplacementMapSystem.cs
* rename things
* fuck stencilmask
* fix bugs
* no masks
* Update jumpsuits.yml
* fix species specific sprites
* Update ClothingSystem.cs
* shoes + ears displacement, some bugfix
* Update DisplacementMapSystem.cs
Requires https://github.com/space-wizards/RobustToolbox/pull/5023
This uses the new engine features (above) to add a displacement map shader. This allows deforming a sprite based on another sprite.
Primary use case is automatically adapting human clothing sprites to different species, something we want to make species like Vox a reality.
A basic example of wiring this up with Vox has been added. The system is however incredibly simple and **will** need more work by a content developer to select and toggle displacement maps when appropriate. I am leaving that to somebody else. For example right now the displacement map is applied even if a species already has custom-fit sprites for a piece of clothing, such as the grey jumpsuit for Vox.
Basic Aseprite plugins to help with authoring displacement maps have also been made.
* remove deprecated entity coordinate extension functions. Reduces warning count by approximately 50
* final toCoords Removed
* Remove all unused variables and dead code paths
* remove always true variable, should be a cvar or something instead
* remove superfluous variables from tests
* add color field to clothing layers
* add support to randomsprite
* bababa
* finalize spriting work
* add to game
* fix
* remove space
* edit patelle, +1 decor variant
* added only pants, some sprite fix
* inflation
* fix mixed
* not tested commit
* Revert "not tested commit"
This reverts commit 4a904df3452263e87c9cb819ab5d8cf411ebe468.
* naked human is fun
* update
* add new style
* some sprite pixel tweak
* Update meta.json
