SERVER: Character mods that use custom container or stats break the wardrobe on servers.

Geneticus0 shared this bug 3 years ago
Outdated

If a modded Character is supposed to have either different health values or inventory size changes, a new subtype must be used. However, using a new subtype causes the characters on a server to break the wardrobe UI for skinning even if the AssetComponent remains Default_Astronaut.

Once a character with a custom subtype is chosen, you will be unable to select the vanilla male or female astronaut, but can select other modded characters. The old Color Picker is the interface used once the wardrobe breaks. This occurs on characters that are skinnable as well. It does not seem to impact an SP world. All characters can be used and swapped freely.


STR: (tested server had 3rd person turned off)

Add this mod to a server: https://steamcommunity.com/sharedfiles/filedetails/?id=1338477778

Log in to the server, switch back and forth between the Vanilla male and female models (by hitting OK)

Notice that you get the new skin UI and can swap freely.

Pick a custom suit (should still show in the new picker wardrobe) and switch to it.

Notice you may be stuck and have to hit your jetpack to get free.

Go back to the wardrobe, select another custom suit, you can see the currently applied suit in the DDL.

Notice you now have the old color-picker UI.

Attempt to switch to a vanilla suit.

Check the wardrobe again, the suit didn't change.

The only way to get back to a vanilla suit is if the mod is removed from the server when you log in.


This mod has the same behavior: https://steamcommunity.com/sharedfiles/filedetails/?id=1458836790

Comments (4)

photo
1

I didn't have the server access to change the 3rd person view back on. However, it occurs to me I could have turned it off in SP and checked for a broken wardrobe that way. I'll try it this evening.

photo
1

Gwindalmir also ran into several of these issues when making Xocliw's Team Colors Mod.

His solution is completely ModAPI based, whereas mine is xmlObject based.

Found in assemblies that skins are only applied to characters with subtype of Default_Astronaut and the female version, regardless of whether or not the custom model used is compatible with them.(i.e. adding additional model details like face changes or additional meshes with custom textures layered on top of the existing character model. )

It does not appear that the Asset Component Modifier object Subtype( which should be an existing subtype) is defined anywhere. (looks like a hack to get skins to work). I say this because the AssetComponentModifier requires a SubTypeID but there are no Asset Components matching "Default_Astronaut". Likely because the game will not apply skins to any models other than the default.

Character Models appear to break with SE Object conventions in that you can have several suits that have the same subtype which are then allowed to duplicate based on the Name field being different which causes some scripting confusion.

photo
1

In the case of my mod, I actually wanted to disable skins, so this breaking bug actually worked in my favor.

However I also understand modders wanting to be able to support adding player skins onto custom models. It's obviously possible, since the female engineer was added with skins support.

I poked around in the game, and found at least one hardcoded reference in the wardrobe to the character subtype for the default astronaut suits (both male and female). It would be nice if instead they could check for the presence of said AssetModifierComponent. This would ensure character mods that want skin support can get it, and those that don't won't.

That component is already marked as optional.

EDIT: Regarding the stats component, I found an issue with scripts not reattaching after respawn: https://support.keenswh.com/spaceengineers/general/topic/modapi-scripts-attached-to-character-are-lost-when-player-respawns-or-changes-suit

Not sure if it has any relation.

photo
1

Hello, Engineer!


Thank you for your feedback! Your topic has been added between considered issues.Please keep voting for the issue as it will help us to identify the most serious bugs.


We really appreciate your patience.


Kind Regards

Keen Software House: QA Department