Leaderboard

I would rather start with FE and not use RF, because the FE API is build into Forge itself and thus it is always available. You would also not run into problems when the RF API doesn't update anymore. Like I remember a time where the mods by TeamCOFH got the 1.7.10 version 2014 and three years later followed 1.10.2 skipping 1.8.9 etc. Also most mods which support RF also support FE. More explanation on wether to use FE or RF or both might be found here: https://minecraft.curseforge.com/projects/redstone-flux Most mods have this complex implementations because they are supporting multiply energy APIs while converting the energy internally to the one which is requested as an output or they got their own energy API for internal uses and convert to RF or FE or whatever is required by the connected machines. When searching for mods which support energy and don't have complex systems I would start searching for mods which just support FE or maybe even support FE and Tesla, but I would also suggest looking into mods which got a fresh rewrite as otherwhise it might be that at one point they added support for FE into their existing systems and later on removed all the other APIs which aren't needed and such code is harder to read when you've got no idea how it works. WARNING: I might have missed some things in the following description as my own energy system also supports Tesla and thus is a bit more complicated. As a starting point for FE, I would highly suggest to learn about the Capability System by Forge, if you haven't already done this. https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/ This is required as the Forge Energy system is based around capabilities. The next point would be create a new class extended from EnergyStorage or just implement all the code yourself using the IEnergyStorage interface which I would suggest if you plan on overwritting all methods provided in EnergyStorage anyway. This class should also implement the interface INBTSerializable<NBTTagCompound> if you want to store your energy data (I assume here that you are already familiar with Java Generics). In this class, save your data and read it in using normal NBT read and write methods (serializeNBT and deserializeNBT). This methods will later be called in for example our TileEntity's NBT read and write methods. In a more advanced system you might also use the capability methods to call wrapper classes around FE and Tesla and other capability based energy systems in this class, but this is out of scope of this basic overview. At next, you should create a TileEntity. This TileEntity needs your EnergyManager class you created before (the class which extends EnergyStorage or implements IEnergyStorage ). In here you add the read and write methods for NBT data and call the serializeNBT and deserializeNBT methods of your EnergyManager. For example: this.container.deserializeNBT(compound.getCompoundTag("Energy")); (container is here the instance of EnergyManager.) Then you also need the hasCapability and getCapability methods. I think you figure yourself out what to put in there. In the update method of your TileEntity you might want to put your logic about energy production or extraction in. this.container.receiveEnergy(int maxReceive, boolean simulate); this.container.extractEnergy(int maxExtract, boolean simulate); If you want to extract or receive energy from another TileEntity, you first need to get it at the specific location and than get the capability at the specific side. (Note: If a machine only sends energy in other machines underneath, then it might only return a capability for EnumFacing.DOWN.) An EnumFacing with null is also possible and might be used for internal purposes if I recall correctly. Do note that it is recommended for the most compatibility between mods to let your machines send the energy into the cables instead of letting the cables extract the energy out of your machines. https://github.com/SleepyTrousers/EnderIO/issues/4081#issuecomment-284911416 I hope this gives you a basic overview of how energy systems actually work. For items, I currently having figured it out myself as I've not worked with items and capabilities so far and transmitting energy wirelessly shouldn't be a challange after reading this. The basics are always the same, just how much more you put around those basic is different.

Also no. ModelLoader is correct.

There's a (World?) method that will give you the top-most solid Y for any X,Z. With that you can check an area. There are several strategies for flattening. One is to choose flat biomes, build up from the highest Y, fill down where the area is lower, and hope it comes out looking good. Another is to scrape a foundation (with room to walk around the outside) down to some median level (but keep it above sea-level). What you choose will depend on what look you want, whether you need to "force" the building at each proposed site etc.

Also I don't think that having more than 1 different non-nested public(aka top-level) class within 1 java file is even valid java. Or is this just the way you've formatted your post and not your actual code snippet?

Show your ModelRegistryEvent hander then. Annotating methods with SideOnly is not a very good way of doing anything, really. SideOnly is too unreliable. Proxies exist for a reason.

That message means that forge was unable to find an object with that registry name in a registry. Additionally you could try to change the type of the field from LightBlueStairs to Block. I am pretty sure that forge still figures out that your type is a subclass of Block and the registry for blocks is the one to search through though.

You were still missing the final modifier on the field. If you are manually setting the field to something else than null then you are not using ObjectHolders correctly, or at all for that matter. In a ModelRegistryEvent handler.

How much data do you plan on sending? I doubt the amount of data you'll need to send will show any drop in performance, especially since you'll only be sending the config packet once, on join. The easiest way to fix this would be to just always send the configuration packet... In fact, that's probably the best way to do it. The only way to know if the values were different would be to send all the values either from client->server or from server->client, so you may as well just send them from server->client anyway... Abstract away the config into an object or into static fields. When the client joins the server, the server should send the configuration values, and the client should set all the fields to the received values. Don't save it. Unless you're storing large amounts of data, caching will likely be more trouble than it's worth.. -------------------------------- How much data do you plan on sending? If it really is just a config file of integer settings for machines, it shouldn't be too much...

Also instead of setUnlocalizedName("light_blue_stairs"); setRegistryName(Reference.MOD_ID + ":" + "light_blue_stairs"); you should do something more like setRegistryName("light_blue_stairs"); setUnlocalizedName(getRegistryName.toString());

OP is setting the registry name of an ItemBlock and is getting the name from a Block. That is a perfectly fine way to do it. @OrangeVillager61 your methods that handle the events are static yet you are using an instance-based bus subscribing. If you are using Mod.EventBusSubscriber then the handler methods must be static, if you are using EventBus::register then they can't be static. Forge's documentation explains it here. The field you annotate with ObjectHolder must have the following signature and declaration: public static final TYPE NAME = null; You are missing the final modifier. Additionally there is no reason to declare a class that only contains static methods final. A final modifier on a class means that other classes can't extend from it.

I think this line might cause trouble because you're setting the registry name from getting the registry name: event.getRegistry().register(new ItemBlock(light_blue_stairs).setRegistryName(light_blue_stairs.getRegistryName())); Also, I think that uou need to register the item model mesher in your client proxy. But you didn't really say what is going wrong -- is it not showing up at all? is it showing up but with the wrong model or texture?

Translate, rotate, translate back.

Forge automatically loads every recipe file in the assets/<modid>/recipes directory, you don't need to manually register them.

I actually utilized the class version structure to create my EasyRegistry implementation before we had the registry events. I'm not saying it was better, but the hierarchical nature of the common periodproxy being a class meant that item registration (GameRegist.register calls) were in a common location and client only aspects were in the client subclass. However, those methods were generic, they contained no references to outside objects (even the static methods only referenced the main mod class in order to get the proxy instance). All of my blocks and items were handled in the main mod class. Making that work with IStateMapper (and a few other things) was a hassle, but I managed it. Unlocalized name might change for subitems. Look at wool for example: each color had a different name, but the registration name is the same for all of them. Using getUnlocalizedName() for the regisrty name makes no sense. Mods should treat their items the same way.