Leaderboard

First of all I'm not here to get support or to point fingers. I'm here because I have seen this crash reported a few times (66650, 66657, 66742, 66708, 66717, 66703) but none of them mentions which coremod is causing the crashes. I understand this forum is not the place to report mod problems (esp. coremod), but it might help someone else (maybe people stop reporting it more times). Crashlog, Debug log The mod causing this crash is NotEnoughIDs. In the debug log this mod prints lines like this: [18:14:20] [Server thread/INFO] [neid]: Patching class: "net.minecraft.world.chunk.ChunkPrimer" with Transformer Group: "TransformerGroupChunkPrimer" [18:15:08] [Server thread/INFO] [neid]: Patching class: "ru.fewizz.neid.asm.Hooks" with Transformer Group: "TransformerGroupChunkPrimer" Also I drop this notice from the mods curse page: "Worlds created with NEID is not compatible with clients without it." Probably best to stay on 2760 for the time being. (I might start a new world without this mod, don't think I actually need it)

MCPConfig on the forge repo allows for viewable decompiled code. However it doesn't have the tools to reobfusicate/package jar mods because that era of Minecraft modding is dead. And we should not be supporting it. As for the FG side of things, getting a raw Minecraft deobfed jar to link against will be possible.

As far as I know, MCP 1.13 is not coming out. There is no need for it. And there is a replacement project that does things in a far better way.

It is not quite as easy to reach that limit. In one of my mods I have items that can hold items that can be nested inside of other such items. Even a very big invenroty(100+) slots filled with those items each of which also holds items inside doesn't go near the packet limit. You can use CompressedStreamTools.write to write an NBTTagCompound to anything that implements a DataOutput, for example a DataOutputStream or a ByteBufOutputStream(this is the one that the game uses anyway), then get the length of that stream.

This makes no sense. You've just accessed the NBTTagCompound that contains the serialized item data. Nothing about this says anything about a ByteStream. Yes, it is true. 32767 bytes. Don't have insanely large NBTTagCompounds. In pretty much all cases you won't have the tag bigger than the limit. If it is it is likely not your fault and you need to complain to whomever caused this issue.

Basically it all goes down to the initial init method class WrappersHolder { ICECProvider wrapperA; ICECProvider wrapperB; void init() { if (Loader.isModLoaded("ModA")) { wrapperA = Class.forName("AWrapperProvider").newInstance(); } if (Loader.isModLoaded("ModB")) { wrapperB = Class.forName("BWrapperProvider").newInstance(); } } } By default the fields contain a null value. The init method checks if the mod is loaded and if it is assigns a new wrapper object to that field. If the mod isn't loaded then no wrapper is assigned and the field stays null. So checking for null is then the same as checking for whether the mod is loaded or not - if it is then the field won't be null. As for the naming, well you can name the fields whatever you'd like. The instance in that line is there because these fields aren't static and thus need an instance to access them. The instance is just a field declared perhaps like this: public static WrappersHolder instance = new WrappersHolder(); It is not needed, you can instead make the fields that hold the wrappers static and then you don't need an instance to access them. Edit: as for the class loading I would imagine forge scans the packages to find either more packages to scan or .class files. It then would read those .class files as a binary stream and convert them to bytecode using the ASM library. Then it is trivial to analyze that bytecode to find an annotation. If an annotation is present then the class name/path is stored somewhere to load at a later date. The bytecode is then discarded. This way the classes are never loaded since they only exist for a short amount of time as bytecode in memory, not as actual loaded classes.

Yeah, do that. Your block does not override createBlockState() and yet it tries to have properties.

By default it won't. Classes are loaded on demand. However I do not really trust this since I do not know if this is a required specification of the JVM behaviour or not. If it isn't a custom JVM provided by a third-pary may indeed load the class. If someone could link me to a specifications for this case it would be great. // In your TE for (EnumFacing side : EnumFacing.values()) { TileEntity tile = this.world.getTileEntity(this.pos.offset(side)); if (tile != null) { EnergyCapability energy = tile.getCapability(CapabilityEnergy.ENERGY, side.opposite()); // This if/else construct is very important because other mods may use a different energy API but still expose their energy capability as a forge energy one via a wrapper. In fact as far as I am aware all of them do. However in case they don't the else goes into play. if (energy != null) { energy.transferEnergyTo(...); } else { if (WrappersHolder.instance.teslaWrapper != null) { ICECProvider teslaProvider = WrappersHolder.instance.teslaWrapper; ICompatibleEnergyCapability cap = teslaProvider.createWrapper(tile, side); if (cap != null) { cap.transferEnergyTo(...); } else { ... } } } } } // The wrapper creation class TeslaWrapperProvider implements ICECProvider { // Since this class is loaded only if the mod is loaded it is completely safe to reference that mod in it. @CapabilityInject(Tesla.class) static final Capability<Tesla> TESLA_CAP = null; ICompatibleEnergyCapability createWrapper(TileEntity tile, EnumFacing side) { Tesla cap = tile.getCapability(TESLA_CAP, side); if (cap == null) { return null; } return new ICompatibleEnergyCapability(){ ... void transferEnergyTo(...) { cap.transferEnergyTo(...); } } } }

Yeah, there will be more eventually. I'd rather wait until 1.13 to make any new ones because of all the changes, but I might do a few more 1.12.2 tutorials because 1.13 is taking longer than I thought it would. Either way though, I'm really busy with school right now so I don't know when I'll have time to make more tutorials.