P3pp3rF1y

I had the exact same problem with my project where runData worked last I ran it 1-2 months ago and now stopped working with similar messages. Tracked it down to bug in how arguments are grabbed for run configs in ForgeGradle and there's apparently a fix for it that's already approved as well https://github.com/MinecraftForge/ForgeGradle/pull/657.

Definitely check out these - https://wiki.mcjty.eu/modding/index.php/Main_Page McJty is doing a great job explaining plenty of topics there and has links to other sites as well.

FYI, this was resolved in https://github.com/MinecraftForge/ForgeGradle/issues/451. Just do gradlew cleanCache setupDecompWorkspace --refresh-dependencies and you should be good.

So I just came over here to ask about exact same issue that I am suddenly getting with a project that I am pretty sure I didn't get last time I updated to 1.12. For your reference the build file that I am using https://github.com/P3pp3rF1y/Reliquary/blob/1.12.x/build.gradle I suspect this issue may have something to do with a recent update to FG?

So I finally got to plugin this in and have to say it's not as easy as it may seem. First of all removeListener for some reason is client side only method, which is just annoying and was fairly easy to solve with reflection (just removing from listeners collection directly). However the listener part is way worse. I am going through all the stacks when inventory opens and then checking for just updates which is all good until a player clicks on anything that has capabilities. When that happens CPacketClickWindow is triggered which then triggers EntityPlayerMP.updateCraftingInventory in case that the stack it just got from packet doesn't match the one on server and because capabilities are not synced it won't match ever. Which is bad because updateCraftingInventory sends back to client all of the inventory contents yet again. So basically what I can do is on every sendSlotContents call in my listener go through all of the inventory because I have no way of knowing if the player just clicked on stack that will cause sync of just one slot or full inventory. Right now I am going with a more limited variant which checks if a stack with itemhandler capability was clicked and only in that case it scans inventory and sends updates. this still means that if an item with different capability was clicked my items would lose their context, but I am going to accept that as an ok solution.

So this solution sounds fairly good. One thing I don't like about it is the fact I will need to listen to all the itemstack changes passing through just in case my item shows up, but I guess that will just have to do.

The only way I can think of when it comes to dealing with this is using regular NBT and store the data to be displayed on client in there as well. But that means that I would end up with the exact same data stored in two different places at least in case of this item. Sounds to me like another reason for itemstack caps to be synced with the stack data (or at least part of the cap data marked to be synced to client)

The code for one of them is here https://github.com/P3pp3rF1y/Reliquary/blob/1.10.2/src/main/java/xreliquary/items/ItemVoidTear.java But the problem here is that the data isn't stored in nbt which gets synced, but in capNBT which as you know doesn't get synced to client and thus needs to be synced through special packets. In the code above you can see the packets being triggered, but that only is the case when the item is in player's inventory. As soon as it is in a container this code does nothing which means on dedicated server there's no information on client on the actual capability data.

I am trying to figure out if there's a way to get ItemHandler capability sync to client when the itemstack it's attached to is in a non player inventory. Basically this breaks for me showing tooltips for ItemHandlers as I can send sync packets when these are in players inventory, but can't seem to find a way to know that player is looking at a inventory and sync the data in that case. Any thoughts on how I could go about that? Look for solution in the first reply from Leviathan143.

Vazkii does fairly simple stuff. GlStateManager.pushMatrix(); GlStateManager.enableBlend(); GlStateManager.blendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE_MINUS_SRC_ALPHA); GlStateManager.color(1F, 1F, 1F, alpha); mc.renderEngine.bindTexture(autojumpEnabled ? AUTOJUMP_ON : AUTOJUMP_OFF); Gui.drawModalRectWithCustomSizedTexture(x, y, 0, 0, 32, 32, 32, 32); GlStateManager.popMatrix(); I have tried this combination with the exception of replacing Gui.drawModalRectWithCustomSizedTexture with RenderItem.renderItem as I can't simply draw a texture because the item has tint indexes that colors get applied to. Based on this I guess something in the renderItem is messing the transparency rendering.

I am looking for an example of code that renders item into hud and uses alpha channel to how much transparent it is. Ultimately want to add a bit of code that fades the item out of HUD after a bit of time. When I just need to render item into GUI I use RenderItem.renderItemIntoGUI, but that internally renders it with alpha set to 1f so I will need to get part of its code to render my item semi transparently. However in trying this out I wasn't able to figure out what exactly. I made sure that enableBlend is called, passed value of less than 1f to alpha parameter of color method and messed around with blendFunc parameters, but wasn't able to figure this out. I used RenderItem.renderItem to render the item in GUI, which in my tries would either get me the 1f alpha channel item in HUD or a glow in the shape of the item (definitely not the transparent one). I guess this is likely very easy for someone with more opengl knowledge than I have. Would you be able to point me to an example of code that does this? Or point out the OpenGL commands that need to be run to achieve semi transparent item in HUD?

This is how I do it in Reliquary. https://github.com/P3pp3rF1y/Reliquary/blob/1.10.2/src/main/java/xreliquary/handler/CommonEventHandler.java#L497 It is a spin off from logic found in bloodmagic. The gist is track the players that you have given flight to in a list and when you figure out that they should no longer have flight mark them as such in your list and remove the flight from them just in that tick. The next tick when you check the list they are already marked as players without flight and thus you're not removing flight from them and other mods can happily use their flight stuff.

Thanks, I will give it a try.

I am trying to test out forge modifications in my mod. I made the changes, ran genPatches and uploadArchives and now have the built files in /repo folder. So now I thought I would just update my mod's build file to give it a local repo that would override where it pulls forge from, but that apparently isn't working for me. Keeps complaining about not finding the forge files. I am kind of ok with gradle, but nowhere near understanding details like these so I am very likely doing something dumb here. Is it even possible to repoint to the local repo like this? Or what do people do when they want to try the forge modifications with their mod? Here is the buildscript repositories part with the local repo. And I have also updated the version of forge I want it to pull to the version that's created by uploadArchives (1.10.2-12.18.1.0). buildscript { repositories { jcenter() maven { name = "local forge" url = "../MinecraftForge/repo" } maven { name = "forge" url = "http://files.minecraftforge.net/maven" } maven { name = "sonatype" url = "https://oss.sonatype.org/content/repositories/snapshots/" } } dependencies { classpath 'net.minecraftforge.gradle:ForgeGradle:2.2-SNAPSHOT' classpath "com.jfrog.bintray.gradle:gradle-bintray-plugin:1+" } }

So I have figured out what's going on here. Basically it relates to packets and a recent forge change. When I start using the flight stuff capabilities get modified and because there was a change to forge which made capabilities part of ItemStack.areItemStackTagsEqual comparison it figures out that stacks are different. https://github.com/MinecraftForge/MinecraftForge/commit/9df1e4b11e0d2d0fbf938cedae2da130d40cca89 Which then triggers SPacketSetSlot to be sent to client, which would be ok if this actually included capabilities. However that is not the case and it only syncs stackTagCompound. Which means that deserialized itemstack on client gets capabilities set to default value. I have my own packet that syncs the capability I need, however packets based on what I have seen seem to be treated async, which means that I am not guaranteed that the capability value gets synced before client starts using it. Thus client a lot of the times suddenly sees 0 in the Staff's charge and stops flying. Now the question is what should be the solution here. Should forge make a change and sync capabilities in SetStackInSlot given that it uses capability value to see if the packet needs to be sent? Or should it start ignoring capability comparison in this case again to avoid sending slots that delete capability data on client? Or is the solution really for my case to save capability data on player to avoid this issue? That would seem like an awkward one to me, but at the moment seems like the only solution on the mod side apart from reverting to looking at just charge at the start minus ItemUseDuration and approximating how much charge is still remaining.

I have a very strange issue with capabilities losing their state on client side when connected to dedicated server. They basically default to the default value that's set when they are initialized for the given ItemStack. However what's even more strange is the fact that if I put breakpoint in to check for the default value and it stops there when I try to retrieve the capabilities again (ItemStack.capabilities) they have the correct state (not the default one that it just evaluated to in breakpoint) I was trying to debug the issue and stopped when I was in EntityPlayer onUpdate (looking at itemstack.capabilities): if (!ItemStack.areItemStacksEqual(this.itemStackMainHand, itemstack)) { if (!ItemStack.areItemsEqualIgnoreDurability(this.itemStackMainHand, itemstack)) { this.resetCooldown(); } this.itemStackMainHand = itemstack == null ? null : itemstack.copy(); } It's always the same - breakpoint set to stop on default value which it does and even if I have watches set to show me the capabilities value they would show the default, but the moment I start editing them and just hit enter they would show the correct state. It almost seems as if there was some async call happening which wouldn't be done when the caps are queried by breakpoint, but is done immediately after. But I don't believe there is anything like that in there. Any thoughts on what could be causing this? The primary issue that I have with this is that I use the caps to store charge of staff of flight (Rending Gale) and thus it needs to understand client side if there is a charge and player can still fly. However as it stands it breaks mid air quite a bit. The same code doesn't seem to have any issues in 1.9 so I suspect some 1.9.4 change.

Thanks a lot. That did the trick. I am still not sure why I haven't seen the meta 0 in the debug previously, but who cares now that it works As for the code comments. The array in createBlockState is on me (copy paste from vanilla). The others not so much as they are from the code I have inherited and still need to do more clean up. But thanks for pointing them out anyway. At least the pointless checks were not on my radar.

I have added a new property to my block, that is used by TESR to display the model in correct orientation. That all works very well, but before I release I wanted to make sure that the previously placed blocks will display correctly. And that is not the case. They are basically gone. I don't get any notification in MC about missing blocks or anything in the logs. When I try debugging I don't see any code being triggered to get the tile entities or trying to load the block with preexisting meta (which would be -1 as there were no properties previously). The way it seems to me is that in the block registry it registers the new blockstates with the facing values, but doesn't have anything in there for the previous no property state and then just skips putting those blocks in the world. I guess there's something simple that I am missing here, but can't figure that out. Is there a way to make this backwards compatible so that the blocks without any property set would get a default facing set? My block: TESR blockstates json (I know that normal shouldn't be required here, was just trying it with it as well, just in case it would help) If you wanted to check more this code is on github at https://github.com/P3pp3rF1y/Reliquary/tree/1.3.0