-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Request] Track CustomModelData as different item #148
Comments
I believe this is not something we currently support, sorry! Since the ID Flattening in 1.13 resolved almost all edge cases where items the user would consider distinct had the same ID. What's your specific use case and what prevents you from splitting it into multiple IDs? |
I'm creating a mod that dynamically adds rarity to vanilla and modded food (which changes the stats when you eat) and I don't want to duplicate each item 4 times so I simply use the CustomModelData to manage the logic (and allow customization of the textures of course) |
Interesting! When designing the mod, I envisioned that variants would either be distinct enough to warrant separate IDs/food list entries/etc. or similar enough to have the same ID and count as the same thing. I suppose there may be a niche here where the rarer variants are sufficiently harder to get that they should count as separate entries while the items are sufficiently similar to be confusing as separate entries, but it sounds to me like maybe separate IDs really would make sense here. The items look the same, but they have different effects and aren't really interchangeable. Further, using CustomModelData to achieve different behavior really feels like a hack to me that is likely to break other things too (e.g. what happens if you put them in a Storage Drawer?). Then again, sharing an ID means they can all be used in recipes just like the original, which may be worth all the downsides if that's really important to you. Either way, we don't currently support this functionality and I don't really have the time to add it right now, so you might want to reconsider splitting into separate IDs. |
The use of NBT instead of ID is really the heart of the concept, the rarity system is inspired by Stardew Valley but what made me want to make my mod is in fact another mod (Quality Crops) which adds rarity with separate IDs (and work very well with this SoL), although I really like this mod I faced some problems when making a modpack with many food : a lot of food had no rarity because the compat had to be done manually (which makes everything confusing and inconsistent, especially when vanilla food is used in modded recipes that have no compat), my implementation aims to correct this among other things ^^ For the visual I currently use the CustomModelData but indeed given that the rarities are dynamic but that the alternative textures must be provided manually the items rarity tend to have the same icon, I planned to add an indicator a bit like Quality Crops in these cases (like a small colored star in a corner of the object). For now I have customized the tooltip render to add a rarity line, a colored name and prefixes/suffixes (all translatable) About the recipe, I use the "forge:partial_nbt" type to create recipes that produces food of the same quality. I am careful to make everything compatible with the other mods, the mod is still in development but so far I have not found any insurmountable problem linked to the use of NBT ^^ |
I see! That is quite the unfortunate situation then. We'd have to add a whole API for registering subtypes of items, figure out a way to represent it in our stored food list, and probably some other things I'm not thinking of. To be frank, I don't really see this happening any time soon—maybe it's not that important for foods of different rarity to count separately? The effects that come with them should be reward enough right :p |
I am working on a mod that uses CustomModelData to create different versions of food within the same item, would it be possible to have a config that allows spice of life to consider these separately in the food already eaten ?
Or add events to the API that I can intercept to add this check on my side ?
The text was updated successfully, but these errors were encountered: