target.san

1) Why not? The only reason i see is backwards compatibility. And TileEntity is in fact just a separate place for part of state and part of logic. It concludes IMO to moving logic to Block and state to BlockState. 2) I mean, ItemStack now holds NBTTagCompound directly. (De)serialization is done less often than property access. So, let's allow having some data structure instead, so Item can do one checked cast and then access properties directly. Less NBT-related code around. Ultimately this goes down to rewriting all with some kind of Object-Data-Behavior system. i know, not gonna happen.

Hi, i noticed (heh several major changes in Minecraft logic, which although look incomplete. I'm talking about BlockState, where block type and its meta were in fact packed into semi-opaque structure. So, what if bring this to logical conclusion? 1. TileEntity ceases to exist as separate concept. All logic is moved into Block class, and state is persisted inside IBlockState thing, which is NBT-serialized as it wants too. Though, it's still a question on how to separate meta-only and NBT-ful blocks states and where to store NBT-based ones. 2. ItemStack will hold some kind of IItemState object, which represents its state and also NBT-packed as it wishes. i know such changes are dictated by Minecraft. But, any thoughts?

Update. Seems that ModelLoader way doesn't work during init phase. Sorry, I kinda misguided you in opening post.

Okay, so now I feel myself dumb. First, my item's registry ID is really worldrift:riftwand , exactly this casing. The changes you suggested fixed the issue, so with only those two lines item is rendered Ok. Anyway, here's the Gist with log you asked: https://gist.github.com/target-san/3a4c8b118257a36fcbb5018741cd6d11

Okie, so that wasn't that smooth for me. To be clear, I'm using Forge 1.8.9-11.15.1.1722 (latest stable AFAIR) Frankly speaking, the only way of attaching model to item which worked for me was Item item = WorldRift.instance.itemRiftWand; Minecraft.getMinecraft().getRenderItem().getItemModelMesher() .register(item, 0, new ModelResourceLocation(item.getRegistryName(), "inventory")); invoked in client proxy's init event specialization. Now, some details. 1. Resources structure 2. models/item/riftwand.json Now, to my findings 1. Adding blockstates/riftwand.json without any Java-side code doesn't do any good. File text I used, just for reference { "variants": { "normal": { "model": "worldrift:rift" }, "inventory": { "model": "worldrift:rift" } } } 2. Attempt to load via Item wand = WorldRift.instance.itemRiftWand; ModelResourceLocation loc = new ModelResourceLocation(wand.getRegistryName(), "inventory"); ModelLoader.registerItemVariants(wand, loc); ModelLoader.setCustomModelResourceLocation(wand, 0, loc); also gives no result. I tried putting model name manually, using empty variant, putting this into both pre-init and init etc. If you ask what were the errors - I encountered either no errors at all or FileNotFound for blockstates/riftwand.json when loader apparently falled back to blockstates as thelast resort. Several mods I checked on Github also use getItemMesher approach. So I'm a bit lost at the end, with recommended ways failing.

One can register block without registering related item, i.e. passing null for item class. It might be appropriate if some block doesn't make any sense in item form. The question is, is it safe? Won't it produce some random NPEs because some code would want "item for that bock"? Or I'd better make stub item for this purpose?

I think that's the problem I'm facing. I was somehow thinking that MC will utilize model which it loaded automatically. A bit surprising, but nothing too hard. Thank you for your time.

As I understand, it's possible to apply item model without any code, by just placing properly named JSON where model loader expects it? I've been trying to use this way, along with model loader way. Though I'm still getting missing texture, along with my item looking like block. So I'm definitely doing something wrong.

Started modding after a break and a bit confused. As I understand, the preferred way to load block models is through blockstate. Though, it's not clear what's the one for items. Which seem to not load any model data automagically based on their registry names. I found following variants: 1. Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register from BedrockMiner's tutorials 2. Use ModelBakery.registerItemVariants 3. Use ModelLoader.registerItemVariants (which looks like #2) Can anyone point to some mini-guide? Google shows too much info, and Forge docs are rather slim Thanks Sidenote: It'd be nice to have some common entrypoint for all Forge stuff, like root Forge class with methods/fields like gameRegistry , modelLoader etc.

It would be easy enough if it was related only to FMP which is well-written and relatively easy to understand. My question was mainly about AE2 internals. Though you're right, and I'll look in different places.

Block classes. They're essentially 'flyweight' pattern. By having some kind of private lazy val dispatcher = if (worldObj.isRemote) ClientDispatcher else ServerDispatcher then delegating all methods through that dispatcher I mostly mean methods like onNeighborBlockChange, which are called both on logical server and logical client. Though I'll have no other option for blocks anyway, as I can't check whether specific block instance construction happens on client or on server.

Ok, thanks, got it. Though I have another stupid question. Do we always have 2 instances of tile entities, normal entities, block flyweights etc. for logical client and server? Or there's one instance in case of integrated server? What I need to know is, can I have some kind of central dispatch point for 'client' or 'server' methods? Or do I need to check for World#isRemote every time, and there's no other way? Because, TBH, it's annoying to have "if (worldObj.isRemote) return;" in each method.

Hi! I've noticed in my mod that I have too much stuff like if (worldObj.isRemote). So I decided to move to some more unified client/server logic decoupling. With this, I came to two possible solutions 1. Use FMLCommonHandler.getSide, which effectively returns side. Then have some private var in my TE's or blocks which would reference client or server implementation, then delegate all calls there. 2. Use SideOnly annotation. The problem is, it's said to be used for Forge's internal use only. So, which way is considered more convenient? Aside from fact that approach 1 allows for different logic on the same actions, where approach 2 doesn't. Thanks.

Hi again! I'm now in process of providing support for several types of TE's in my linking block. The idea is, we have two blocks, in different positions and possibly in different dimensions. At example, we put some pipe on the north side of 1st linker, and on the south side of 2nd linker, and two pipes connect like they're adjacent. Sort of. So, can anyone please provide some insight on what interfaces should I implement to make ME cables work, i.e. create valid network? I suspect it's somehow related to appeng.me.helpers.IGridProxyable. Thanks.

That's not a problem actually. I already use own tiny chunk watcher which notifies linkers that their linked entities are unloaded I've workarounded this by making my own tiny cacheable resettable wrapper. It's dropped when anything changes. Actually, each of wo linkers in a pair notifies second one that it has blocks changed around, or it's unloaded, or whatever. Then second one drops its caches, freeing TEs. Though WeakRef might really make code cleaner. Or not, since I don't always expect TE to be there. And WeakRef doesn't allow to distinguish 'null ref' from 'dead ref'. Anyway, I thought a bit on a problem and decided to not enforce chunks loaded around portal. Since it's rather generic-use, and there might be many of them. Effectively exceeding per-player or per-mod chunk load limit. Thanks.