Leaderboard

i would suggest going to 1.11.2 and then later when many people will be playing 1.12 upgrade again

Create a normal I storage implementation but then in your provider leave deserializeNBT And serializeNBT empty

Remove real first person render from the server, I'm guessing it's a client/single player mod.

You don't need to check it when you're seeing an entity, right? Then before the getBlockState call, check if the target is on entity and if it is, don't do anything there( put return or similar).

i believe that there is a mod that does it

IStorage#writeNBT is @Nullable, so it can return null. IStorage#readNBT can simply be a no-op. If your capability doesn't need to be serialised to NBT, don't implement INBTSerializable on the ICapabilityProvider you attach with AttachCapabilitiesEvent.

Note the word ALL Yes, the file extension is part of the file name.

Forge policy is always to target the latest stable build (currently 1.12 - 14.21.1.2387). Otherwise we get another situation like we had with 1.7.10, where no-one wanted to update.

In your log Heres the answer

1) item.getRegistryName() instead of MODID + ":" + id 2) Post your log file, if there's a problem loading models or textures, there will be an error there. 3) Found your problem, it isn't assets.slingshot, it's supposed to be nested folders. Same thing here.

He probably wasn't totally awake.

Chiming in as one of the other leaders of Sponge, I've always believed that making heavy modifications to the game (as coremods sometimes do) would benefit from being viewed source, since often times debugging odd interactions between SpongeForge (and SpongeCommon as the larger part) have been often times difficult to say the least to work out where the issue lies. That being said, I strongly support the idea around coremods being viewed source for the sake of inter-coremod compatibility overall, as the goal with SpongeForge has always been about remaining compatible with as many mods as possible out of the box (even if the technological attempts at maintaining that compatibility is not as evident or thought up very fast). As @Zidane has mentioned, SpongeForge will be making the necessary changes in the very near future to abide by these requirements. As per usual, my goal with inter-mod compatibility is always to provide as much descriptive console spam error logs to help Sponge and/or the mod itself get a better fix and make the users happier overall.

I don't speak for the whole community but since I am a leader of Sponge, I'll throw my 2 cents in by first saying that yes, SpongeForge will be adjusted to comply. We find these changes to be a good-faith effort to make some wholesome changes to the ecosystem as an attempt at dealing with the elephant in the room: coremods. SpongeForge falls under a coremod which will not function at all without its core changes but, as Lex has mentioned above, we can simply make the core portion not function at all should the whole thing not be here and throw up a descriptive error to say why. Expect to see some changes land in the next couple of days (when someone gets some time) on Sponge's end to make this change.

Do you have a pack.mcmeta file in src/main/resources with pack_format set to 3? If you don't, Forge will load your mod's resources using the LegacyV2Adapter IResourcePack wrapper. This means that your lang files will be loaded with the old mixed-case names (e.g. en_US.lang) rather than the new lower-case names (e.g. en_us.lang). If you do, your lang files should be loaded with lower-case names. Try refreshing your IDE project (i.e. click the "Refresh all Gradle projects" button in IDEA's Gradle window or re-run the eclipse Gradle task) and/or rebuilding it.