Fabulously Optimized

Fabulously Optimized

2M Downloads

Cosmetica

eyezahhhh opened this issue · 20 comments

commented

Mod name

Cosmetica

Curseforge link

https://www.curseforge.com/minecraft/mc-mods/cosmetics

Other links

https://modrinth.com/mod/cosmetica/
https://cosmetica.cc

What it does

Adds custom capes and cosmetics

Why should it be in the modpack

FO's current capes mod, Fabric Capes, supports capes from Optifine, LabyMod, MinecraftCapes, and Wynntils. Cosmetica supports capes from all those, plus Cloaks+, Mantle, Arc and 5zig.

You can use Cosmetica to enable and disable each cape server individually. You can also use Cosmetica to "replace" a cape server's cape, so for example you can tell a player has a MinecraftCapes cape, but you can choose not to see the actual cape and see a stock one instead, to avoid exposure to NSFW capes.

Cosmetica also supports hats and "shoulder buddies", which are models that attach to your player for further customization. All types of cosmetics can be upload to Cosmetica to be used, where they go through a manual screening process to filter NSFW cosmetics and to disallow official Minecraft capes.

Cosmetica is totally Minecraft EULA compliant, with no capes sold. In fact, all cosmetics are free.

Cosmetica users are given a "starter cape" when they first join, this is usually just one of three different capes. But modpacks can choose what this cape is, just by shipping a config file with the modpack. FO can use this so that all FO users that are new to Cosmetica automatically equip the FO cape.

Modpacks can also use the above method to choose which third party cape servers are shown and hidden by default. FO can use this to make all FO users with Cosmetica see MinecraftCapes capes by default, to maintain support for those who have already used MinecraftCapes for a custom cape.

Cosmetica cosmetics automatically reload periodically if it detects a user in your game has recently updated their cosmetics.

Cosmetica does not have an accounts system, and instead uses Minecraft accounts. This means you never need to input a password into Cosmetica.

Why shouldn't it be in the modpack

Changing your cosmetics currently requires you to go to the website (this is easy and there's a button in the settings screen to do so, but it breaks immersion). This however is being added to the mod in future.

Cosmetica does not yet support animated capes. Players who have an animated cape on MinecraftCapes will not see it move when using Cosmetica.

Categories

Replaces an existing mod

Additional details

Disclaimer: I am one of the developers of Cosmetica

Edit: Guthub link

commented

There have been discussions and it is possible that FO will include Cosmetica V2, whenever that gets released.

Here's the list of expected benefits that would give to FO over the current mod:

  • More cape providers
  • Customizable cape provider priority (planned feature)
  • Less network requests to fetch capes
  • Less long-term breakage - the mod can update providers' API URLs serverside
  • Easier in-game cape upload
  • Maybe an easier way to apply FO cape
  • Opt-in cosmetics
  • Existing Cosmetica users can preserve their synced settings seamlessly

I did not list any drawbacks/concerns right now as ideally (most of) these would be fixed by then.

commented

Will the custom cape mod configs get lost?

commented

Will the custom cape mod configs get lost?

The config file is obviously different between the two mods but both of them allow enabling-disabling the cape providers individually.

commented

The only cons is that users with custom config will lose it. LGTM

commented

Don't they lose their custom configs when they upgrade Minecraft versions anyway?

commented

Don't they lose their custom configs when they upgrade Minecraft versions anyway?

Usually not, because the modpack has YOSBR.

It can happen when:

  • The mod switches config system
  • I switch the mod to a different one
  • I force a specific config for some reason

Either way that is not a big concern, the user could just copy what they had in the config file (as it would persist when I swap mods, even if it doesn't work from the same file anymore) and because the user is notified by the changelog.

commented

Thanks for the feedback.

As the mod is quite a bit larger than Fabric Capes, I've decided not to currently add this for capes alone, but rather see how the non-cape models, Forge support, backports and other things will progress and then decide.

If it gets included though, I might still default to capes only at first, and "introduce" other features when the mod's critical mass has been gained. Will see.

commented

Well, you should definitely add the toggles for individual features regardless of whether the mod is in FO. Though, by the description it seems like you already do that:

Yeah we do, all features can be toggled from inside Minecraft with the exception of capes as a whole (individual services can be disabled). But this is usually fine since nobody's exactly using the mod for custom hats but don't want custom capes.

My problem with this and similar mods overall is ecosystem lock-in. Trying to do the opposite by being interoperable with other cape providers is one thing which FO already does.

That's a similar philosophy we follow. By supporting as many cape services as possible we let users use whichever cape server they're comfortable with and giving them the freedom to move around. All those cape servers have APIs that are pretty easy to interface with so nothing's stopping anyone from doing the same thing to increase interoperability (which is what Fabric Capes does to a lesser extent). Our API is also public (docs pending lol)

though I don't know how much people care and know about those other client capes

They probably don't, personally I'm yet to see someone with a 5zig cape. But I think its more of a statement that player's aren't being locked into any ecosystem.

I don't want to force anyone to use (or keep using) FO for that specifically.

That's totally fair. As much as you'd want to give players as many reasons as possible to keep using FO it's in the players' interest to be able to use the features they love outside of the modpack too. Cosmetica's public API is being used by a few other (decently large) services (I can outline them if necessary). While I guess that does technically decrease interoperability, there's always going to be a certain degree of it and we try to walk the line between interoperability and being feature-rich very tightly. Hopefully we make up for it with our public API and public source mod :) So anyone can do what we do.

Is it something Java players would expect? No, probably not. But I'm sure FO also has to walk the line between vanilla/optifine parity and having features you think your players would love. I mean, there's a reason why you're not just using Optifine and calling it a day right ;)

Love the work you're doing with FO :)

commented

We can make it so the modpack can disable shoulder buddies and lore if that helps.

Cosmetica also has a DNS server similar to Cloaks+ or Mantle so Optifine users can see Cosmetica capes and all supported services, but yeah no forge version yet :(

I saw FO encourages people to make mods for the pack, so if there's anything you think is getting in the way of Cosmetica being useful to FO, feel free to let me know and we can try get it resolved.

commented

if there's anything you think is getting in the way of Cosmetica being useful to FO, feel free to let me know and we can try get it resolved.

Well, you should definitely add the toggles for individual features regardless of whether the mod is in FO. Though, by the description it seems like you already do that:

Nearly all features are disableable.

My problem with this and similar mods overall is ecosystem lock-in. Trying to do the opposite by being interoperable with other cape providers is one thing which FO already does (though I don't know how much people care and know about those other client capes, I mostly try to promote MinecraftCapes as it's reasonably popular and free).

But introducing new cosmetics? Ehh, I don't know.
It is Bedrock parity, but do Java players expect that?
It could be nice to leverage the popularity of FO to introduce that, but I don't want to force anyone to use (or keep using) FO for that specifically. But also, is FO popular enough (yet) for anyone to even care?

These are the hard questions I have to face when choosing such mods 😅

commented

Additional cape support is nice.
Lore and shoulder buddies are a definite no.
Not sure about the additional models (even when the users can just pick them from a site), this mod is still very small - no <1.16 and no Forge.
I think some people started using animated capes on FO already.

Have to think about it...

commented

Cosmetica's public API is being used by a few other (decently large) services (I can outline them if necessary).

I am indeed curious about that. Do they use the API just for capes?

commented

Do they use the API just for capes?

PojavLauncher and by extension QuestCraft do yeah. There's also a PlaceholderAPI expansion (not officially in the registry yet afaik) which lets a multitude of Spigot plugins interact with Cosmetica. There's also a fork of Geyser which shows all capes served through the Cosmetica API (including third party capes) to Bedrock players (and hat/shoulder buddy support is coming too iirc). The developer of the open source Sol Client is also working on integrating Cosmetica into their client, which is 1.8.

We encourage using the Cosmetica API not just for Cosmetica capes, but as a kind of "Minecraft Gravatar", where your Minecraft cosmetics from multiple platforms are all available from one place.

commented

I had test it in the past, when it had fewer abilities, but the cape and extra cosmetics support looks very cool!

commented

As it seems, Fabric Capes now supports Cosmetica (CaelTheColher/Capes@209a395)

commented

It does, yeah. I still think Cosmetica is the better option (biased, duh), but at least FO will have the option to support Cosmetica either way going forward.

commented

Personally adding this would be a no brainer, the fact it supports so many capes from external service but yet in such a concise package is really good. Overall the only issues I have really seen raised so far have been with shoulder buddies and hats being too much however as these are completely togglable so I really see no issue here either. Perhaps the largest benefit however is the fact that it ties in directly with anyone else using the mod online it's pretty cool to go to a random server and find other players who are also using one of the abundant supported capes mod or the cosmetica mod directly and the community as a result is quite extensive. Beyond this I think the mod is very well built and intergrated to its online platform and, by integrating it would bring a lot of new players from these pre-existing communities.

commented

TIL Cosmetica uses http to connect between proxy server and external skin cape servers. Until that changes, I cannot use it as just a skin cape provider either (as it's a downgrade compared to other skin mods) ☹️

Edit: there will be an option to force https
Edit 2: cape servers, yes

commented

I'm not sure what you mean by skins, as we don't support custom skins yet. Do you mean capes? If so, the Fabric Capes mod only uses https for Labymod, Wynntils, and MinecraftCapes, which is done because those servers require https (Cosmetica API also uses https for those services).

As mentioned in the Discord, you'll be able to force https for all queries to our API, which secures the client <-> api connection.

But the api <-> cape server connection? Here's the status on https for all the connections we make under the hood (in the order that I just read them from our code):

HTTP:

  • Cloaks+
  • Optifine
  • Mantle
  • Eternals
  • Lunar Client (technically http but to our internal Lunar server)

HTTPS:

  • LabyMod
  • Wynntils
  • MinecraftCapes
  • 5zig
  • Official Minecraft Capes

We don't plan on changing these. Mainly because the majority of servers using http either don't support https, or we're connecting to a direct IP.

Ignoring speed, using Cosmetica API as a cape proxy is pretty useful because it anonymizes your requests. Cape servers can no longer track your IP since requests are routed through us, and your requests look the same as everyone else's.

Obviously, this means that by not giving these cape servers your information, you're giving it to us instead. But we're working on a way to show users all the data that we collect on them (which is a pathetically small amount of data and all data except for settings and preferences is cleared after it's life cycle (which for most data is 5 minutes - 12 hours))

Hopefully that's enough security.

commented

Big point here, unlike fabric capes, every API can be enabled and no performance issue happen