Kir-Antipov
commented
1 year ago This isn't going to happen on my end. Allow me to clarify my position on the problem.
Suppose you were to open the issue using the specifically designated template, "🔧 Mod Compatibility Request". You would notice a required field titled "Justification. Why do you think this feature should be implemented on our side?" This exists for good reason.
Ignoring concepts like the heat death of the universe and the finite number of particles within it (i.e., limits on time and space), we are left with the assumption that an infinite number of Minecraft mods can exist. Consequently, there could be countless mods that attach additional data to the player entity. As a result, I would need to dedicate literally endless hours to implementing compatibility layers for all these mods. It's important to note that implementation is only a small part of the problem. I wouldn't be so opposed to ideas like this if it wasn't for maintenance.
Mods like "Chest Cavity" aren't designed with mods like "Sync" in mind. They operate under the assumption that there's only one player entity. So, when I implement compatibility layers for them, I need to access the internals of such mods to change their behavior and isolate states of their components for different player shells. Do you know what happens next? If not, try launching your game with "Sync" and "Haema" mods installed simultaneously. Your game will crash. Because I worked on compatibility with that mod, but then its author altered some of its internals (which they have every right to do), and compatibility features quickly became incompatibility issues. If I hadn't attempted to please players by incorporating that mod's logic into mine, they wouldn't be dealing with game crashes now.
So, what do I need to do to fix a problem that didn't even exist before? I could examine the new Haema release, compare it to the previous one, study the author's code changes, and determine how I need to modify mine to support old and new versions of Haema. Then, I would implement a new compatibility layer and publish a new release. Sounds like a lot, doesn't it? Now, let's return to my exaggerated example of infinite mods. Indeed, I would need to spend endless hours just making these mods compatible with mine. Moreover, I would have to devote even more time to maintaining the new code and preventing these delicate implementations from breaking, all while monitoring an infinite number of constantly updating mods. Frankly, that's not a situation I want to be part of.
I hope you understand my perspective. However, I also realize that as a player, you just want to enjoy the game your way. And that's possible. Remember how I mentioned that all mods modifying player internals aren't developed with mods like "Sync" in mind? Well, my mod is developed with other mods tweaking the player entity in mind! I've created a dedicated api module for other developers, which can be used to achieve various levels of integration with "Sync":
- Make new entities compatible with the treadmill
- Alter the energy output of treadmills based on certain conditions
- Programmatically add new shells to the player's radial menu (implementing third-party shell constructors and shell storages)
- Prevent a player from creating a new shell
- Stop a player from syncing with a specific shell
- Most relevant to this discussion, you can attach custom data to stored shells and restore it from them
Since this is an API, it's designed for others to use and won't undergo dramatic changes between versions that would break everyone's work.
Let's revisit my analogy, but with this information in mind. Now, an infinite number of developers can spend a little bit of their time implementing a compatibility layer with the "Sync" mod using its API and essentially forget about it for the rest of their lives, reducing maintenance costs to almost nothing. See how even a comically exaggerated example turned into something feasible for all parties involved? This is the way to go, and I won't even attempt (at least not anymore) to go down a path that would lead to me being overwhelmed by the sheer horror amount of work I need to put into maintaining this mod, effectively reducing the time I could spend on more useful and meaningful tasks to zero.
Given that this is the real world and not just my hyperbole, and the number of mods requiring deeper integration with the "Sync" mod is quite finite, I am willing to help other developers implement the necessary features if they ask me to. But the basic idea is as follows:
// Implement a component that contains all the information about custom data you've attached to the player entity
import dev.kir.sync.api.shell.ShellStateComponent;
public class FooShellStateComponent extends ShellStateComponent {
public FooShellStateComponent(@Nullable ServerPlayerEntity player) {
// Initialize the component
// If `player` is not null, it should be attached to the given player
}
@Override
public String getId() {
// Change "foo" with the name of your mod
return "foo";
}
@Override
public Collection<ItemStack> getItems() {
// If there are items attached to your component, return them
return List.of();
}
@Override
public int getXp() {
// If there's XP attached to your component, return it
return 0;
}
@Override
public void clone(ShellStateComponent component) {
FooShellStateComponent other = component.as(FooShellStateComponent.class);
if (other == null) {
return;
}
// Copy the state from the `other` component
}
@Override
protected void readComponentNbt(NbtCompound nbt) {
// Restore the state of this component from NBT
}
@Override
protected NbtCompound writeComponentNbt(NbtCompound nbt) {
// Save the state of this component to NBT
return nbt;
}
}
// And register it during the mod initialization
import dev.kir.sync.api.shell.ShellStateComponentFactoryRegistry;
if (FabricLoader.getInstance().isModLoaded("sync")) {
ShellStateComponentFactoryRegistry.getInstance().register(FooShellStateComponent::new);
}
JaceSilverwave
Problem
No response
Feature
I would highly recommend adding a compatibility option with the Chest Cavity Mod. (confirmed mods do work together in a Fabric 0.14.17 MC 1.19.2 modpack.)
The Chest Cavity mod allows for players to swap out their internal organs to change their body's physical traits so they can specialize in certain activities or environments. eg;
Generally speaking, it allows for a really unique parallel loadout system that gives players a huge variety in gameplay customization without taking up the already highly contested armor or trinket slots, and I think that the Sync mod would pair beautifully with it so that you could create and save specialized loadouts of not only equipment in shells, but also the customized internal biology that Chest Cavity offers.
I imagine the game behavior to act fairly intuitively, if the compatability option in Sync is enabled, and the keepOrgansOnDeath option in Chest Cavity is disabled, then whatever organ setup the player currently has gets saved and stored within that shell/body, and is restored to them upon re-entering the respective shell.
For clarity, at the moment the chest cavity loadout persists across all shells when swapping as if the same, regardless of if the keepOrgansOnDeath option is enabled in the config, however, if the player dies and is sent to another shell, they do drop their non-original organs on the ground, respawning in the new shell with the fresh organ loadout as if they respawned naturally.
Other Solutions
No response
Additional Information
No response