[DONE] [Suggestion] Multi-Layered Paperdolls

[SuperCaffeineDude]

Hi, the paperdoll system is something I think could maybe use some improvement.

I'd love for the armors to be on a seperate layer to the base paperdoll, it'd eliminate having to have stacks of image files per armor type with the pale/tan/light-brown/dark-brown skins and any variant dolls.

So instead of having to save a paperdoll of; skintype1 with hairstyle1 and armor1,  skintype2 with hairstyle1 and armor1,  skintype3 with hairstyle1 and armor1, etc...
We Instead just have the armors store/reference their own image, of the female/male/alt suits, and overlay it on the soldiers own assigned paperdoll.

(It'd also be good if the armor came with some sort of cropping mask, so large hair styles can be contained within helmets and such.)

I think this would allow for much more cross-compatibility between modpacks and improve the speed with which mods can be created and edited.

Just a suggestion not sure how feasible it is.

[Solarius Scorch]

Yes, this idea (or similar) have been going around for some time...
I think it's not the least feature feasible ever, but still quite a bit of work. And as far as I remember, the actual number of necessary layers would be something like 4 or 5 (to account for pieces of hair going over the shoulder, etc.). So effectively, the number of layers may have to be configurable or even dynamic - or at least reasonably high.

[SuperCaffeineDude]

I suppose I hadn't thought of that. Though if we presume you have 3 layers; body_behind (ponytail's), body_mid, body_front (fringes/glasses), say like this...

current
8(BodyVarients) *1 (layers) = 8 layers, * 4(stand_armors) = 32 layers
proposed
8(BodyVarients)*3(layers) = 24 layers, +4(stand_armors) = 28 layers
proposed_femaleVarientArmor
8(BodyVarients)*3(layers) = 24 layers, +(4(stand_armors) * 2(body_type)) = 32 layers

at 12 armors it becomes something like 96 layers verses 48 layers

Then again; I guess using the extended mod you'll have the 16 sub-varients of each skin+sex, so maybe I'm full of shit and the savings don't really occur until you have a huge portfolio of armors in your mod :/

Though, thinking on it more, I guess you could remove the head and modify that separately...

current with subvarients
8(bodyvarients)*16(subvarients) = 128 layers
*
4(stand_armors)
= 512 Total Image Layers=

proposed femaleVarientArmor with subvarients
8(BodyTypes (Male/Female/SkinTone))
+
(8*16(HeadVarients))*3(sublayers) = 384 layers
+
4(stand_armors) * 2(body_type)) = 8 layers
= 400 Total Image Layers =

(edit: I've slept on it and completely forgotten why I thought removing the head would make a difference lol, but I guess you could also use the head as an extra layer over the neck and body)

Spoiler:

current with subvarients
8(bodyvarients)*16(subvarients) = 128 layers
*
4(stand_armors)
= 512 Total Image Layers=

proposed femaleVarientArmor with subvarients

(8(BodyTypes (Male/Female/SkinTone)*16(BodyVarients))*3(sublayers) = 384 layers
+
4(stand_armors) * 2(body_type)) = 8 layers
= 392 Total Image Layers =

Am I doing bad math? Shame it would require so much fuss. But factor in more armors and the savings seem like they could be huge, though in the short-term I imagine this would create a lot of work for current mods.

Love to hear your thoughts of course

[bulletdesigner]

Theres a ez way , just give inv box to face 2*2 then make lot of itens that look like bears a staches .
The hard code is make that box only usable to that itens and that itens only usable to box also not show in equip list
Done hahaha

[Dioxine]

Clothing layers would be a tremendous upgrade, and I cannot overstate it - tremendous.
Example:
10 armors current: 10x96 = 960 images
10 armors, 3 layers (including hair): 96+96+10 = 204 images. Compressed to 20%
50 armors: around 5000 vs. 194+50 = 244. Compressed to 5%
10 layers, partial interchangeability, 204 images: max. 10x8 = 80 armors
So it's down to 20% on standard mods, and adds ability to go non-standard (effectively unlimited paperdoll combinations for limited effort, like in RPG games).

[Meridian]

If you're willing to update all your images, I'm more than willing to do a couple of layers

Can all layers be 320x200 and just stack on top of each other?
Any special requirements?

And one set of layers for testing please...

[SuperCaffeineDude]

Sounds cool! I'll try to convert the vanilla sprites into layers within the next couple of days for testing, unless someone has the paperdolls in underwear ready? or Dioxine has something ready to go?

[SuperCaffeineDude]

Sorry still messing around, I have the day off tomorrow so I'll buckle down.
The body proportions are so janky i'm trying to work out a nice base for the male + females, the shading is a little off still

[ivandogovich]

PirateZ has premade paper dolls of all the females without clothing, that may help with a base.  there are also male figures in their as well.

[SuperCaffeineDude]

Having to run some errands sadly, here's what I managed today
https://drive.google.com/open?id=1faaG0YWNNgbScHFbfgVo0TmWEH5dc-kn

Just seen your comment I'll have to check out the piratez files, I haven't got it to hand.
I'm not making the most of the layers for the head just yet, I need to get the power armor done, anyone got an image of the pw-armor with the helmet in the hand?

[Meridian]

Feature implemented in OXCE 5.1

You can now define any number of layers you want to use in your mod.
It's the same number of layers for each paperdoll, so give it a little thought at the beginning, or you'll have to rework your ruleset if you decide to add a new layer somewhere in the middle later.

Furthermore, each layer can not only use its own sprites, but also sprites from other paperdolls.
(only one sprite "set" per layer)

I admit the description is not very simple/easy to understand... maybe some ruleset examples will help:

Code: [Select]

armors:
  - type: STR_NONE_UC
    layersDefaultPrefix: HUMAN
    layersSpecificPrefix:
      8: JUMPSUIT
    layersDefinition:
      M0: ["", "", "M0_NAKED", "", "", "", "", "", "M_JUMPSUIT", "", "M0_FACE", "", "", "", "", ""]
      M1: ["", "", "M1_NAKED", "", "", "", "", "", "M_JUMPSUIT", "", "M1_FACE", "", "", "", "", ""]
      M2: ["", "", "M2_NAKED", "", "", "", "", "", "M_JUMPSUIT", "", "M2_FACE", "", "", "", "", ""]
      M3: ["", "", "M3_NAKED", "", "", "", "", "", "M_JUMPSUIT", "", "M3_FACE", "", "", "", "", ""]
      F0: ["", "", "F0_NAKED", "", "", "", "", "", "F_JUMPSUIT", "", "F0_FACE", "", "", "", "", ""]
      F1: ["", "", "F1_NAKED", "", "", "", "", "", "F_JUMPSUIT", "", "F1_FACE", "", "", "", "", ""]
      F2: ["", "", "F2_NAKED", "", "", "", "", "", "F_JUMPSUIT", "", "F2_FACE", "", "", "", "", ""]
      F3: ["", "", "F3_NAKED", "", "", "", "", "", "F_JUMPSUIT", "", "F3_FACE", "", "", "", "", ""]
#
#
  - type: STR_PERSONAL_ARMOR_UC
    layersDefaultPrefix: HUMAN
    layersSpecificPrefix:
      8: PERSONAL_ARMOR
    layersDefinition:
      M0: ["", "", "M0_NAKED", "", "", "", "", "", "M_PERS_ARMOR", "", "M0_FACE"]  #trailing ""s are not needed
      M1: ["", "", "M1_NAKED", "", "", "", "", "", "M_PERS_ARMOR", "", "M1_FACE"]
      M2: ["", "", "M2_NAKED", "", "", "", "", "", "M_PERS_ARMOR", "", "M2_FACE"]
      M3: ["", "", "M3_NAKED", "", "", "", "", "", "M_PERS_ARMOR", "", "M3_FACE"]
      F0: ["", "", "F0_NAKED", "", "", "", "", "", "F_PERS_ARMOR", "", "F0_FACE"]
      F1: ["", "", "F1_NAKED", "", "", "", "", "", "F_PERS_ARMOR", "", "F1_FACE"]
      F2: ["", "", "F2_NAKED", "", "", "", "", "", "F_PERS_ARMOR", "", "F2_FACE"]
      F3: ["", "", "F3_NAKED", "", "", "", "", "", "F_PERS_ARMOR", "", "F3_FACE"]

Based on this, sprites with composite name will need to be defined.
First part is the "prefix" (e.g. HUMAN), then layer number (e.g. and last sprite name (e.g. M0_FACE); they are separated by two underscores.
Example:

Code: [Select]

extraSprites:
  - typeSingle: JUMPSUIT__8__M_JUMPSUIT
    fileSingle: Resources/LayeredJumpsuit/08-outer_clothes_armor_and_boots/male.png
  - typeSingle: JUMPSUIT__8__F_JUMPSUIT
    fileSingle: Resources/LayeredJumpsuit/08-outer_clothes_armor_and_boots/female.png
#
#
  - typeSingle: PERSONAL_ARMOR__8__M_PERS_ARMOR
    fileSingle: Resources/LayeredPersonalArmor/08-outer_clothes_armor_and_boots/male.png
  - typeSingle: PERSONAL_ARMOR__8__F_PERS_ARMOR
    fileSingle: Resources/LayeredPersonalArmor/08-outer_clothes_armor_and_boots/female.png
#
#
  - typeSingle: HUMAN__2__M0_NAKED
    fileSingle: Resources/LayeredHuman/02-body/M0_male_blond.png
  - typeSingle: HUMAN__2__M1_NAKED
    fileSingle: Resources/LayeredHuman/02-body/M1_male_brown.png
  - typeSingle: HUMAN__2__M2_NAKED
    fileSingle: Resources/LayeredHuman/02-body/M2_male_asian.png
  - typeSingle: HUMAN__2__M3_NAKED
    fileSingle: Resources/LayeredHuman/02-body/M3_male_african.png
  - typeSingle: HUMAN__2__F0_NAKED
    fileSingle: Resources/LayeredHuman/02-body/F0_female_blond.png
  - typeSingle: HUMAN__2__F1_NAKED
    fileSingle: Resources/LayeredHuman/02-body/F1_female_brown.png
  - typeSingle: HUMAN__2__F2_NAKED
    fileSingle: Resources/LayeredHuman/02-body/F2_female_asian.png
  - typeSingle: HUMAN__2__F3_NAKED
    fileSingle: Resources/LayeredHuman/02-body/F3_female_african.png
#
#
  - typeSingle: HUMAN__10__M0_FACE
    fileSingle: Resources/LayeredHuman/10-face/M0_male_blond.png
  - typeSingle: HUMAN__10__M1_FACE
    fileSingle: Resources/LayeredHuman/10-face/M1_male_brown.png
  - typeSingle: HUMAN__10__M2_FACE
    fileSingle: Resources/LayeredHuman/10-face/M2_male_asian.png
  - typeSingle: HUMAN__10__M3_FACE
    fileSingle: Resources/LayeredHuman/10-face/M3_male_african.png
  - typeSingle: HUMAN__10__F0_FACE
    fileSingle: Resources/LayeredHuman/10-face/F0_female_blond.png
  - typeSingle: HUMAN__10__F1_FACE
    fileSingle: Resources/LayeredHuman/10-face/F1_female_brown.png
  - typeSingle: HUMAN__10__F2_FACE
    fileSingle: Resources/LayeredHuman/10-face/F2_female_asian.png
  - typeSingle: HUMAN__10__F3_FACE
    fileSingle: Resources/LayeredHuman/10-face/F3_female_african.png

As you can see, we have added also a shorter way of defining single sprites.

The following definitions are equivalent:

Code: [Select]

  - typeSingle: HUMAN__10__F3_FACE
    fileSingle: Resources/LayeredHuman/10-face/F3_female_african.png


Code: [Select]

  - type: HUMAN__10__F3_FACE
    singleImage: true
    width: 320
    height: 200
    subX: 0
    subY: 0
    files:
      0: Resources/LayeredHuman/10-face/F3_female_african.png

I am also attaching a working sample, which you can try with xcom1... it replaces paperdolls for jump suits and personal armor.

PS: for big mods, this could cut down the number of paperdolls by 90% or more... and improve both loading time and memory usage... and most importantly time to create new paperdolls

[Stoddard]

@Meridian,

I think that    assigning meanining to the structure of / storing information in     YAML identifiers is very wrong.

Can I ask what was the rationale behind that?

EDIT: versus something like

Code: [Select]

extraSprites:
  - typeSingle: JUMPSUIT
    layer: 8
    spriteName: M_JUMPSUIT
    fileSingle: Resources/LayeredJumpsuit/08-outer_clothes_armor_and_boots/male.png

?

[Yankes]

Extending meaning, there is already case for M0, F1 etc.

[Stoddard]

Extending meaning, there is already case for M0, F1 etc.

Hm,
I wasn't aware of  that.

Still I'd say it goes against ... well, I forget the proper incomprehensible name for it, but let's say against the spirit of keeping identifiers and sematics apart. Because once you get to encoding information into identifiers themselves, why even have YAML, and not just invent yet another YAYAML.


So I'm kinda curious why not keep information structured when there's every chance to do it.

[Meridian]

I think that    assigning meanining to the structure of / storing information in     YAML identifiers is very wrong.

I humbly agree.

Can I ask what was the rationale behind that?

EDIT: versus something like

Code: [Select]

extraSprites:
  - typeSingle: JUMPSUIT
    layer: 8
    spriteName: M_JUMPSUIT
    fileSingle: Resources/LayeredJumpsuit/08-outer_clothes_armor_and_boots/male.png

?

It just happened this way. Original proposal came from Solarius/Dioxine (they actually didn't even want extraSprites, but direct filename construction based on some rules... that's however not possible) and then Ohartenstein, Bloax and myself iterated to this final form after a few rounds of brainstorming.


Technically, the "type" still needs to be unique.

At the moment, I just copy "typeSingle" into "type".
With your example above, I would need to:
1/ either concat "typeSingle", "layer" and "spriteName" into "type" anyway... being basically the same as my solution, just longer for modders to write
2/ or refactor whole extraSprites to support non-unique "type"

Offtopic: I'm very glad I didn't do that refactoring, because SupSuper did a completely different big refactoring for lazy loading just a few days later... and I wouldn't be able to merge. I could think of refactoring now, but... meh

As for the first option... well, I don't have any counter-arguments really... just that modders really liked the 2-line format, when I first showed it to them.