yeelp
commented
4 years ago Thankfully, this works. NBTExplorer shows that the FoodCapModifier is stored as an NBTTagList (although it has 0 entries... strange). The world I used for 1.4.0 development was loaded successfully without crashing, and it kept my original FoodCapModifier, so I say this was a successful update.
To implement Hunger Plus/Minus easily, I'd need to use the FoodCapModifier capability. However, the FoodCapModifier can't distinguish between the different modifiers (from modules, hunger plus/minus) which may cause errors in setting the final modifier value. This PR attempts to fix this while preserving compatibility with 1.4.0 and below.
FoodCapModifiers now keep a map: String -> Short which differentiates modifier values by a String identifier.
IFoodCapModifier now extends ICapabilitySerializable<NBTBase> as opposed to ICapabilitySerializable<NBTTagShort>. Now, Minecraft should attempt to read any type of NBT data when reading and writing NBT data for the FoodCapModifier. In particular, it can read BOTH NBTTagShort and NBTTagList.
when deserializing NBT data (Which now takes an NBTBase as an argument), we can check if this NBT tag is an instance of NBTTagShort. If so, get the stored short value (call it x) and put the entry ("modules", x) in the map (The ModuleHandler class now uses the identifier "modules" for it's modifier, which is the only class in v1.4.0 that uses the FoodCapModifier). This should successfully convert from the old storage to the new storage. If it's an instance of NBTTagList, we read it in the new format which is an NBTTagList of NBTTagCompounds, where each compound tag has a String and Short entry, which correspond to the id and modifier value respectively.
When serializing NBT data, we serialize for the new format.
If this doesn't work (I hope this does as I have no ideas after this), I'm going to continue to document my attempts in this PR. If this DOES work, I'm merging this into the 1.5.0 dev branch.