desht

As it happens, I've been trying to figure out how to do this too; the item in question is the PneumaticCraft Minigun, whose barrel spins (or at least it did in 1.7.10) when it's firing. A few questions (not looking for code! just checking that my approach is sound): "If you insist" sounds ominous. Is there a better way than using TileEntityItemStackRenderer? The docs at https://mcforge.readthedocs.io/en/latest/rendering/teisr/ suggest it's a good way to handle this. My understanding is that if my item model has a parent of "builtin/entity", it's an easy way of getting isBuiltInRenderer() to return true. Right? Really, I only want a fancy animated model for the in-hand (left/right, 1st & 3rd person) transformations, not for GUI/ground/fixed. Can I specify (in my blockstate file) a simple static model (which I already have) for GUI/ground/fixed, and my "builtin/entity" model for the held variants? Can that "builtin/entity" model be empty (define no quads), since I'm going to be handling all the rendering via TileEntityItemStackRenderer? I already have a Java model for the animated minigun, since it's also rendered in an entity renderer (drones), and TESR (sentry turret). Presumably it's OK to render that, with the appropriate transformations, in my TEISR handler?

Actually, all registry events are fired just after preInit (by preInit, I assume we're talking about mods' FMLPreInitializationEvent handlers being called). So preInit handlers cannot assume that anything (blocks, items, sounds, models...) will be registered. Any mod code that deals with anything in the registry should be done in init (FMLInitializationEvent) or later. Capabilities. See https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/, in particular https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/#migrating-from-iextendedentityproperties

Damn, I knew the PneumaticCraft drone code was more complex than it needed to be. This'll make the mod way smaller!

williewillus is maintaining a primer on the 1.13 changes here: https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a It'll be significant work for modders but I'd say considerably easier than 1.7 -> 1.8 was.

partialTicks is used to smooth animation by interpolating between ticks. For example (code from PneumaticCraft: Repressurized to smoothly animate rotations of the Assembly Drill - see https://github.com/TeamPneumatic/pnc-repressurized/blob/master/src/main/java/me/desht/pneumaticcraft/client/render/tileentity/RenderAssemblyDrill.java): void renderModel(TileEntityAssemblyDrill te, float partialTicks) { if (te != null) { float[] renderAngles = new float[5]; for (int i = 0; i < 4; i++) { renderAngles[i] = te.oldAngles[i] + (te.angles[i] - te.oldAngles[i]) * partialTicks; } renderAngles[4] = te.oldDrillRotation + (te.drillRotation - te.oldDrillRotation) * partialTicks; model.renderModel(0.0625f, renderAngles); } else { model.renderModel(0.0625f, new float[]{0, 0, 35, 55, 0}); } } The rotation angles and previous rotation angles are stored in the TE - every tick, the angles are updated as appropriate and the previous angles are copied into te.oldAngles[] (multiple angles in this case, since it's a robot arm which has several points of rotation). The actual render angles are calculated as an interpolation of the current and previous angles, based on partialTicks: renderAngle = oldAngle + (newAngle - oldAngle) * partialTicks. Of course, this can also apply to any other rendering: translations, scaling etc. But that's the principle.

The CSV files can also be downloaded from http://export.mcpbot.bspk.rs/ I also find https://github.com/bspkrs/MCPMappingViewer very handy - a Java-based GUI to search for MCP symbols. As for the changes in KeyBinding, there's no simple solution there other than to study the KeyBinding class in 1.8 and 1.12.2 and work out why the keybinds changed from a list to a map. It's almost certain that the mod's code will need to be adjusted in some way to account for it, although if the mod was simply using it to iterate over, it might be a fairly simple change.

No, you really should not be doing that (modifying the actual ItemStack on the server). Stop thinking like a Bukkit developer - you have access to both client and server here. Never mind that, I misread. If you're storing the functional data server-side using NBT and using Item#addInformation() clientside to display it to the player in a readable way, that's good. To add "lore" (and that's really a Bukkit term - it's just a tooltip here), all you need to do is one of: If it's an item from your mod, override Item#addInformation() and append your text to the item's tooltip. If it's an item from another mod (or vanilla), you can use the clientside ItemTooltipEvent to insert your tooltip. Remember, this is all happening on the client. Tooltips are just information that is displayed to the player, not actually stored in a server-side item stack. And your clientside code also has access to I18n.format() so you can correctly localize your tooltips.

You can also use the @ObjectHolder injection system if you need to get a reference to an arbitrary block or item (or indeed anything that lives in a registry). Example: class MyClass { // If the block actually exists, Forge will inject its value into SOME_BLOCK // when block registration is done @ObjectHolder("somemod:someblock") public static final Block SOME_BLOCK = null; // later on, during the game... public void myMethod() { if (SOME_BLOCK != null) { // then it was registered and you can use it doStuffWith(SOME_BLOCK); } } } See https://mcforge.readthedocs.io/en/latest/concepts/registries/ for more information.

Try using RenderHelper.enableGuiStandardItemLighting() / RenderHelper.disableGuiStandardItemLighting(). Working example: https://github.com/TeamPneumatic/pnc-repressurized/blob/master/src/main/java/me/desht/pneumaticcraft/common/progwidgets/ProgWidgetItemFilter.java#L69-L84

If world.isRemote, then you do absolutely nothing. The client should never be manipulating items in the player's inventory; make your changes on the server and Minecraft will (usually) handle sync'ing those changes to the client(s) for you. Note that this applies just as much to a "single-player" world as to you're logged into a remote server. Even a single-player instance has a local internal server.

Well, it turns out that it was happening in my dev environment too. I've worked around the problem for now by just drawing the gauge lines directly with Gui.drawRect() calls, but I'm no nearer to working out why it was a problem...

Yeah, I'd considered that, but my mod is the one & only mod in my non-dev test world, and I still have the problem. So other-mod interference can be ruled out.

This may or may not be relevant: https://www.reddit.com/r/feedthebeast/comments/6yi8l0/psa_modders_axisalignedbb_method_renames_causing/ The .expand() method doesn't do what it used to.

Just hit a weird problem with GUI rendering, specifically drawing a tank gauge texture on a GUI screen. It works fine inside my dev environment, but when the mod is run in a regular client, the problem crops up; instead of the GUI background showing up behind the texture, the background renders solid black, or occasionally with parts of other textures intruding (which suggests that I'm being careless with my texture coords, but I'm pretty sure I'm not - and why would it work in a dev environment and not outside?) The code is here: https://github.com/desht/pnc-repressurized/blob/master/src/main/java/me/desht/pneumaticcraft/client/gui/widget/WidgetTank.java#L48 and the texture in question (16 x 64 PNG file, mostly transparent) is here: https://github.com/desht/pnc-repressurized/blob/master/src/main/resources/assets/pneumaticcraft/textures/gui/widget/widget_tank.png And an example of what it looks like (5 tanks here, 3 with solid black, 2 with other textures creeping in): https://imgur.com/a/nUi5E. The problem happens whether or not there's any fluid to render. If there is fluid, the fluid renders fine, and the gauge is rendered over the fluid OK. Just the part that's rendered over the GUI background goes wrong. Anyone seen anything like this before? It's got me scratching my head...

Been doing some work on this: see https://github.com/MinecraftForge/MinecraftForge/issues/2851 for detailed description and link to sample implementation. In short: I took option 3. No need for extended properties, though; this just uses the normal IBlockColor tinting mechanism, allowing tinting to be controlled via the "custom" property in the blockstates file.

Despite the versioning on McJty's tutorials, his 1.12 series is much better, and still applies as long as you're on a recent 1.10.2 version of Forge (which you should be). https://wiki.mcjty.eu/modding/index.php/Rendering-1.12

Yeah, I can see a few problems here offhand... Stop using getItemModelMesher() and start using setCustomModelResourceLocation(). And do your model registration in an event handler for ModelRegistryEvent. Don't use upper- or mixed-case resource locations. "blockHektometer" is bad, "block_hektometer" is good. Using getUnlocalizedName() to determine the model resource location like you do in ModBlocks#registerRender() is horrible practice. The block/item registry name should be considered the source of truth, not the translation key. (So derive your translation keys and model resource locations from your registry names) Start using RegistryEvent.Register<Block> / RegistryEvent.Register<Item> for registering your blocks and items (and other resources like sounds...), and move away from doing that explicitly in an init() method. See https://mcforge.readthedocs.io/en/latest/concepts/registries/.

Caused by: java.io.FileNotFoundException: 110core:models/item/110core.hektometer.json You haven't shown your code, but it looks like you're putting your domain (mod id) into the path part of your resource location (in addition to the domain part, where it actually belongs).

Encountered this myself today and did a little research. Choonster is exactly right about NBT & ItemPredicate, but it wasn't clear to me just what should be in the NBT. With a little research, I learned that something of this form works: "criteria": { "etchacid_bucket": { "trigger": "minecraft:inventory_changed", "conditions": { "items": [ { "item": "forge:bucketfilled", "nbt": "{FluidName:\"etchacid\",Amount:1000}" } ] } } } So, the item needs to be "forge:bucketfilled", and the NBT includes FluidName and Amount tags (it's a serialized FluidStack, to be exact). The fluid name is of course the name under which you registered your fluid, and doesn't have to be from your mod.

So, I saw this issue: https://github.com/MinecraftForge/MinecraftForge/issues/2851 ...and I'm guessing there's no direct way to allow tinting (via IBlockColor) of an OBJ model (either the entire model or selected faces of the model) at this point. That said, what would be the recommended way to achieve this indirectly? The thoughts I had: Add a TESR to the block; it's a tile entity anyway Add one or more JSON submodels to the block to allow tinting of certain faces of the model Do something with the IBakedModel to replace the appropriate quads with the desired colour, based on some extended block property Recommendations? (1) would be simple enough but worst for performance, I assume. (2) is also easy, but limited to horizontal/vertical faces of the model (or it'll look bad). (3) if possible might be best, but can I intercept the baked model and modify certain quads? That's something I've been having difficulty getting my head round...

Are you registering the packet on both the server and client side (with the same discriminant, obviously) ? The error message suggests the packet isn't registered on the client side, although I don't have an IDE to hand right now to verify that.

Apologies for the minor necro, but I have some information to add to this thread which I figured might be useful... I hit this same problem today while porting PneumaticCraft's air cannon to 1.12 - one of the air cannon's modes allows players to be launched into the air. Worked fine if I triggered the cannon via a button, but I got the "player moved wrongly!" message when triggering with a pressure plate. The reason for this is that the pressure plate's redstone signal (and the resulting actions) is directly triggered by entity movement, so EntityPlayerMP#setPositionAndUpdate() effectively ends up getting called from within Entity#move(). This is sufficient to trigger the server's move validation checks, since the player has moved further than expected. I got around it with a bit of a gross hack: using reflection to set EntityMP's private invulnerableDimensionChange field to true right before calling setPositionAndUpdate() - the server validation code will be ignored if this field is true. This at least has the nice side effect of being automatically switched off pretty much straight away; as soon as the server receives a CPacketConfirmTeleport packet, which happens as soon as the client gets the SPacketPlayerPosLook packet. It's not pretty, but it works.

Right, that makes sense now that I think about it. OK, makes life even easier! I'm liking the new system, it turned out to be a lot easier to move things over than I initially feared.

I'm converting my mod to use a fully registry-based block and item (and sound etc.) registration system, but I'm a bit uncertain about how ItemBlock registration (and associated model registration) should be handled. Would the following be the right way to go about it? @GameRegistry.ObjectHolder("my_mod_id") public static class Registrar { @GameRegistry.ObjectHolder("myblock") public static MyBlock MY_BLOCK = null; // is this correct..? @GameRegistry.ObjectHolder("myblock") public static ItemBlock MY_BLOCK_ITEM = null; @SubscribeEvent public static void registerBlocks(RegistryEvent.Register<Block> event) { event.getRegistry().register(new MyBlock().setRegistryName("myblock")); } @SubscribeEvent public static void registerBlocks(RegistryEvent.Register<Item> event) { // will MY_BLOCK have been injected at this point? event.getRegistry().register(new ItemBlock(MY_BLOCK).setRegistryName("myblock")); } @SideOnly(Side.CLIENT) @SubscribeEvent public static void registerModels(ModelRegistryEvent event) { ModelLoader.setCustomModelResourceLocation(MY_BLOCK_ITEM, 0, new ModelResourceLocation("my_mod_id:myblock", "inventory")); } } Update: I've tried this and it does appear to work as expected. But the question stands: is this the right way to do it now? In particular, using @ObjectHolder annotations for the ItemBlock registration.

Maybe require new members to be signed up for at least 24 hours before posting? Possibly reject posts with non-ASCII characters in the subject (or is that being unfair on genuine foreign-language posts)? Something needs to be done in any case, the forums are completely flooded with spam right now; they're becoming unusable.