Factorio Forums

TL;DR

Idea for an easy way to support multiple character skins in one game

What?

One of my mods comes with a character selector that allows you to change your character during the game. It works, but there is one big flaw: Most mods that provide new character skins ("skin mods" from now on) assume that the mod is active because their character should be used. Currently, vanilla does the same thing. There's only one character in the game (data.raw.character.character), so this is the character that the game will always use.

In order to make sure that their character will be used, skin mods have to overwrite data.raw.character.character with their own! This doesn't really matter if only one such mod is used. But if you'd ever choose to have two skin mods active at the same time, only the one that's loaded last will be usable because that is the last mod that overwrote the default character. (Things may even get worse if the last mod has less properties set than the previous one, and doesn't clear the prototype before overwriting it!)

Why?

There are mods about that provide new character skins, so there must be players who'd like to try a game with a differently looking character.

As author of a character selector mod, I've tried to convince skin mod authors to follow this procedure:

• Define your character in data.lua. Don't overwrite the default character yet, but give it an alternative name! The name should follow a common pattern so that character selector mods can filter out unwanted characters.
• Do nothing in data-updates.lua! This way, character selector mods will get a chance to compile a list of all available characters and do whatever they need to do.
• In data-final-fixes.lua, check if a known character-selector mod is active! If there is, do nothing. Otherwise, overwrite the default character and hope that no other skin mod is loaded after yours!

In my selector mod, I then look for characters with a name matching the required pattern and apply a scale factor to certain properties and the graphics of these characters during data-updates.lua. In control.lua, I make a list of all valid characters (i.e., name matches pattern) and construct the character selector GUI. This also has a flaw: I need to convince other modders to play by my rules (use the pattern I impose on them)! Also, there will be skin mods that I don't know about (so I couldn't even add them on my own), and where the other author doesn't know about my mod and its requirements. My mod would ignore these characters if they had another name than the default character (e.g. if the mod provides different skins), so if you start your game with such a character and exchange your character with my mod, you wouldn't be able to change back to the original unless you used another mod or console commands.

The procedure outlined above would make sure that my mod (and other character selector mods) can access different modded characters, if available, as well as the default character. It also guarantees skin mod authors that their character will be used if no character selector mod is active. But it would be way easier if skin mod authors wouldn't have to overwrite the default character at all!

How about this? There's a table where skin mod authors can register their characters. (Characters may be created for different reasons -- e.g. as dummies that are placed in vehicles, see AAI Programmable Vehicles and Autodrive. Giving skin mods the chance to register their characters would filter out characters that are not meant to be used by players.) The table is part of vanilla, so it can be accessed by skin mods and character selector mods during the data and during the control stage. If that table is empty (or contains no name of a valid character entity) at the end of data-final-fixes.lua, just use the default character. If the table contains one valid entry, let Factorio assume that the player wants to use that character and activate it. If the table contains several valid entries, assume that a character-selector mod is active as well and leave everything as it is, so all characters that are meant to be used by players (but no others) are easily available to character selector mods.

Would you mind adding this? I mean, a vanilla character selector would be great ), but adding just one persisting table should be a lot less trouble and would make the life of many some modders a bit easier.

ssilk wrote: ↑Sat Nov 28, 2020 3:20 am moved from suggestions to modding requests— ssilk

Please move it back to suggestions.

This is *not* a request for mods, nor is it even *possible* to mod this. The engine does not support changing the graphics of a Prototype/Character without swapping the entity. But swapping the entity inheritely breaks compatibility with all sorts of other mods. Also any current attempt to implement skin swapping by entity swapping inheritely creates a "walled garden" for each skin-selector mod that is incompatible with skins from any other skin-selectors walled garden.

I've spend a great deal of time thinking about the problem, and my conclusion is that engine-level support is imperative for any proper non-hacky attempt to create skin-selector mods. But even something "simple" as a system similar to graphics_variation for the whole character animation tree would imho be out of the scope of "interface requests", thus "Ideas and Suggestsions" is infact the correct subforum to discuss this.

eradicator wrote: ↑Sat Nov 28, 2020 10:27 am Please move it back to suggestions.

I'd rather move it to modding interface requests. If I understand, the request is not that there should be several skins in vanilla, but rather that the game is made into supporting the feature for modders to take advantage of.
[Koub] Moving to Modding interface requests

Koub wrote: ↑Sat Nov 28, 2020 11:42 am I'd rather move it to modding interface requests. If I understand, the request is not that there should be several skins in vanilla, but rather that the game is made into supporting the feature for modders to take advantage of.
[Koub] Moving to Modding interface requests

Thanks! You've got it right: It's not about getting a new mod, but about giving modders a common tool. Why should every mod be required to invent the wheel again? That only causes compatibility problems and unnecessary overhead.

Koub wrote: ↑Sat Nov 28, 2020 11:42 am If I understand, the request is not that there should be several skins in vanilla, but rather that the game is made into supporting the feature for modders to take advantage of.

Correct. Except that it's the kind of (possibly breaking) prototype change that usually gets instantly shot into "won't implement". So i saw this more as a thread to gauge community interest before writing a proper request. I guess we'll have to see how/if the devs react.

After some thought i think a sufficiently easy-to-implement solution would be to allow overwriting the armor animation at runtime. This is not perfect as things like footsteps sounds/positions and water reflections aren't part of the "animation" but it would still be a big step towards non-entity-swapping skin-changing. Mods would use it by defining a hidden visual-only armor for each skin and sticking it to all characters.

What?

The ability to dynamically make a character entity look like it's wearing one armor (i.e. "light-armor") when they have another armor (i.e. "power-armor") equipped. As simple as: Why?

This would allow seperating "visual" from "function" (collision, inventory size, crafting category, etc) of a character. Thus greatly increasing the compatibility of "skin" (animation) mods with mods that change how the character works (Bob classes, Space Exploration, etc), while "only" requiring the storage of one additional string(?) per character entity.

Examples of skin mods: Gear Girl, Mechanicus, Nepgear

I'd definitely use something like that, if only for temporarily "hiding" characters by giving them completely transparent sprites as "armour", which would avoid the need for wild shenanigans involving invisible indestructible cars and having to track and clean them up again under multiple contingencies.

+1 for this