Hello, I am working on a roguelike mechanics mod on Fabric 1.21.1, and Lootr is an excellent mod that fits RPG design very well. I hope to integrate support for your mod.

I want to achieve the following: if a player has Lootr installed, when they die, I want to reset all the Lootr chests they have opened. Additionally, I would like to only remove the records for that player and not affect other players.

I have read the wiki and it seems the commands currently provided may not be able to achieve the scenario I am aiming for. Could I accomplish this functionality using the Lootr API? Thank you for your time and assistance.

You should be able to use the command /lootr clear <player_name>.

Through the API, you'd want to use LootrAPI::clearPlayerLoot(ServerPlayer) or LootrAPI::clearPlayerLoot(UUID).

In 1.21, this should also clear the "openers" which will also visually reset the appearance.

Sorry to bother you again. I encountered an error while importing dependencies, and I'm not sure if it's caused by something on my end. I hope to get some help.

Since this is my first time developing a Minecraft mod, I apologize if this causes any inconvenience.

Attached is my build.gradle.

plugins {
	id 'fabric-loom' version '1.10-SNAPSHOT'
	id 'maven-publish'
}

version = project.mod_version
group = project.maven_group

base {
	archivesName = project.archives_base_name
}

repositories {
	// Add repositories to retrieve artifacts from in here.
	// You should only use this when depending on other mods because
	// Loom adds the essential maven repositories to download Minecraft and libraries from automatically.
	// See https://docs.gradle.org/current/userguide/declaring_repositories.html
	// for more information about repositories.
	maven {
		name = "Terraformers"
		url = "https://maven.terraformersmc.com/"
	}
	maven {
		url = 'https://maven.blamejared.com'
		content {
			includeGroup 'noobanidus.mods.lootr'
		}
	}
}

loom {
	splitEnvironmentSourceSets()

	mods {
		"roguelikemc" {
			sourceSet sourceSets.main
			sourceSet sourceSets.client
		}
	}

}

fabricApi {
	configureDataGeneration {
		client = true
	}
}

dependencies {
	// To change the versions see the gradle.properties file
	minecraft "com.mojang:minecraft:${project.minecraft_version}"
	mappings "net.fabricmc:yarn:${project.yarn_mappings}:v2"
	modImplementation "net.fabricmc:fabric-loader:${project.loader_version}"

	// Fabric API. This is technically optional, but you probably want it anyway.
	modImplementation "net.fabricmc.fabric-api:fabric-api:${project.fabric_version}"

	// Config
	implementation 'com.moandjiezana.toml:toml4j:0.7.2'

	// mod menu
	modImplementation("com.terraformersmc:modmenu:${project.modmenu_version}")

	// lootr
	modCompileOnly "noobanidus.mods.lootr:lootr-fabric:${lootr_version}"
	modRuntimeOnly "noobanidus.mods.lootr:lootr-fabric:${lootr_version}"
}

processResources {
	inputs.property "version", project.version

	filesMatching("fabric.mod.json") {
		expand "version": inputs.properties.version
	}
}

tasks.withType(JavaCompile).configureEach {
	it.options.release = 21
}

java {
	// Loom will automatically attach sourcesJar to a RemapSourcesJar task and to the "build" task
	// if it is present.
	// If you remove this line, sources will not be generated.
	withSourcesJar()

	sourceCompatibility = JavaVersion.VERSION_21
	targetCompatibility = JavaVersion.VERSION_21
}

jar {
	inputs.property "archivesName", project.base.archivesName

	from("LICENSE") {
		rename { "${it}_${inputs.properties.archivesName}"}
	}
}

// configure the maven publication
publishing {
	publications {
		create("mavenJava", MavenPublication) {
			artifactId = project.archives_base_name
			from components.java
		}
	}

	// See https://docs.gradle.org/current/userguide/publishing_maven.html for information on how to set up publishing.
	repositories {
		// Add repositories to publish to here.
		// Notice: This block does NOT have the same function as the block in the top level.
		// The repositories here will be used for publishing your artifact, not for
		// retrieving dependencies.

	}
}

When I run Data Generation, a conflict occurs during the remapping step:

:remapping 51 mods from modImplementation (java-api)
Mapping target name conflicts detected:
  METHODs noobanidus/mods/lootr/fabric/client/item/LootrChestItemRenderer/[render, net/minecraft/class_756/method_3166](Lnet/minecraft/class_1799;Lnet/minecraft/class_811;Lnet/minecraft/class_4587;Lnet/minecraft/class_4597;II)V -> render
  METHODs noobanidus/mods/lootr/fabric/client/item/LootrShulkerItemRenderer/[render, net/minecraft/class_756/method_3166](Lnet/minecraft/class_1799;Lnet/minecraft/class_811;Lnet/minecraft/class_4587;Lnet/minecraft/class_4597;II)V -> render
  METHODs noobanidus/mods/lootr/fabric/client/item/LootrTrappedChestItemRenderer/[render, net/minecraft/class_756/method_3166](Lnet/minecraft/class_1799;Lnet/minecraft/class_811;Lnet/minecraft/class_4587;Lnet/minecraft/class_4597;II)V -> render

Thank you for your time and assistance.

By addition, here is my gradle.properties

# Done to increase the memory available to gradle.
org.gradle.jvmargs=-Xmx1G
org.gradle.parallel=true

# Fabric Properties
# check these on https://fabricmc.net/develop
minecraft_version=1.21.1
yarn_mappings=1.21.1+build.3
loader_version=0.16.10

# Mod Properties
mod_version=1.0.0
maven_group=snowball049.roguelikemc
archives_base_name=roguelikemc

# Dependencies
fabric_version=0.115.1+1.21.1
owo_version=0.12.15+1.21
modmenu_version=11.0.3
lootr_version=1.21-1.10.35.90

The issue here is that you're using the Yarn mappings which conflict with some of the method names I'm using.

As Lootr is a multi-loader project, I'm using the official Mojang mappings instead. You should be able to switch to those instead of Yarn.

I will make a note to rename those methods however.

Thank you for your help! Remapping to loom.officialMojangMappings() did indeed allow me to build correctly. However, since my mod development is almost complete, I don’t have the energy to fix the method conflicts caused by the remapping from my project. Still, I really appreciate your assistance!

Currently, I’m considering using a datapack with mcfunction to handle resetting loot upon death. However, when running /lootr clear <player_name> on Fabric 1.21.1, it doesn’t seem to successfully reset the loot, and the appearance of previously opened chests remains unchanged.

Minecraft Version: 1.21.1
Fabric Loader: 0.16.10
Lootr(Fabric) Version: 1..21-1.10.35.90
Reproduce step:

1. Open any naturally generated Lootr chest.
2. Execute the command /lootr clear <player_name>.
3. Result: No stored inventories for <player_name> to clear.

Sorry, I have now confirmed that the chest can be reset. The previous issue might have been caused by some other factors. However, the chest's appearance is indeed not updated immediately—I have to leave and rejoin the world to see the chest's appearance re-rendered.

Thank you for your time and assistance.

Ah, I hadn't considered that. I assumed most people who would be using that command would most likely be doing it while a player was offline or via a console before they logged in. I'll have to think about how best to re-send the information.

Hey snowball, I was wondering what your mcfunction looked like to achieve the refresh on death. I am creating a similar experience where I need the chests to refresh when a player dies. Would you mind sharing your work?

@Dubledice I tried using a pure datapack and found that /lootr clear <player_name> only accepts a player name as a string and does not support target selectors (such as @s). Unfortunately, this means that a mod is still required to obtain the player_name of the command trigger.

If you don’t mind, I can share some of the implementation details here once it's completed.

@Snowball0409 I spoke with Noobanidus about adding selectors to the /lootr command list. He was happy to submit it. I was just testing the new command in 1.20.1, though I realize you are on 1.21.1 so he would have to add it to those later versions too but its progress!

Also if you don't mind sharing, how exactly are you running modded commands through datapacks? I am getting into datapacks for a unique private server utilizing the CTE2 modpack but a semi-hardcore version of it. It would save me so much time and effort if I knew how to run commands from datapacks!

Sorry for the delay in replying.

Something I suggested to @Dubledice was looking into KubeJS's PlayerResapwned event. So long as you check the "returning from end" boolean, you should have full access to the player information when they respawn from death (as opposed to just returning through the end portal) and therefore be able to call the API function or use a command to reset.

I'll port the selector to 1.21 today some time, after which I'll be working on updating 1.21.4 and then the 1.21.5 port.