Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Ipsissimus418

Members
  • Content Count

    21
  • Joined

  • Last visited

Everything posted by Ipsissimus418

  1. That is something I hadn't considered in terms of threads. I have the WorldTickEvent handler do nothing on the client but run on the server. I may have some paths for the addEntry running on both the client and server. Something I need to look into and check if that is where the conflict is coming from. Thanks.
  2. I have a low occurrence issue reported by users of my mod which is resulting in a ConcurrentModificationException. I'm currently trying to investigate some possible options, since I'm having problems duplicating the problem and my understanding of a couple of Minecraft areas is not good. I've had a look at some of the Minecraft code, but I'm not understanding it well enough to satisfy my theories. I have a WorldTickEvent handler in my mod, that simply walks a list of block positions using a iter.hasNext loop. Each loop calls a simple piece of code on the current blockpos
  3. After a good day of debugging I have my answer. Server was working perfectly. It was the client that was failing. When the client was processing the Container.slotClick it does the following slot6.getItemStackLimit SlotItemHandler.getItemStackLimit Get a full stack and try to insert it into the IItemHandler calls isValidItemForSlot which on the client was returning false. My isItemValidForSlot looks up the recipes loaded on startup to see if the item is a valid input. When running with an internal server, this input item li
  4. Been doing some more debugging - including a completely fresh Intellj checkout. Items being inserted via a hopper while the gui is open work correctly - probably because they modify the destination stack size. You can correctly remove (manually or shift-click) an item from the machine inventory. The issue is limited to items going into the single slot of the machine either via mouse drag or via shift-click on the item. I've rewritten the container slot handling and the tlle entity inventory using other people's code as an example but nothing seems to fix it.
  5. (I initially asked for help of Discord where Gigaherz referenced his transferStackInSlot method which I've tried, however I'm still having issue, so I'm posting here with more context) I have a few machines with inventory slots and have implemented the whole transferStackInSlot with both my own and then Gigaherz version. With an internal server moving items manually from the inventory to the input slot of the machine or via transferStackInSlot works fine. GUI updates immediately and there are no visual issues. I've retested with a dedicated server and client and no
  6. Cannot believe it was that simple. Shifting the setSlimeSize to after the onInitialSpawn fixed the issue and now the slimes spawn with the correct sizes. Now to go back and remove all the debug. Thanks diesieben07.
  7. I'm currently updating/rewriting/experimenting with my mod for 1.14.4 and have been running into a confusing issue with spawning. I can happily spawn mobs and kill them, except for when I need to modify the entity. The best example is that I need to spawn and kill small slimes. I have an access transformer for setSlimeSize that is working fine. I then use setSlimeSize to set a size of 1 - small. But when I get the LivingDropEvent ~50% of the time the size is back to 2 - large. I've been dumping the UUID for the entity at creation time and dro
  8. @diesieben07 Well that is a embarrassing mistake! Thanks for that, I looked straight through that code multiple times and never saw the mistake. Correcting the canInteractWith method allowed the GUI to open successfully.
  9. Mine is a bit different. I'm successfully calling NetworkHooks.openGui on the server side and the request is getting to the client side handler as well.
  10. I've updated my code to use the new gui opening code, however whenever I click on the block, the GUI never displays. (Forge 1.13.2-25.0.73) https://github.com/Ipsis/Woot/tree/1.13.x So far I've done the following * registered an extension point for returning the guiscreen ** https://github.com/Ipsis/Woot/blob/1.13.x/src/main/java/ipsis/woot/Woot.java#L68 * return a new GuiScreen for the FMLPlayMessages,OpenContainer ** https://github.com/Ipsis/Woot/blob/1.13.x/src/main/java/ipsis/woot/client/GuiHandler.java#L30 * used NetworkHooks.openGui in the onBloc
  11. I've started to cache the last few entity.getCachedUniqueIdString and then used that to compare incoming event, then dropping the event if I've already seen that id. This seems to filter out the multiple Dragon ones without having any obvious impact on other entity deaths.
  12. That actually fits in with a piece of code in EntityDragon attackDragonFrom if health <= 0.0F && !currentphase.isStationary setHealth(1.0F) setPhase(DYING) That seems to tick the Dragon back up by 1 health if you attack it while it is dying, but still moving. It would therefore be allowed to reach the onDeath multiple times as the health > 0.0F. If that is the case, I might try caching the last EntityID in my event handler to try and filter out the duplicate Dragon ones. It wont be 100% successful, but it should cut them down a bit.
  13. In my mod I use the onLivingDeath event to decide if a user has killed enough of a specific mob for something to occur. I recently had an issue raised on GitHub where the user said that they could keep hitting the Dragon with arrows while it was dying and they could register multiple deaths. I've added some debug to my event handler and sure enough, if I was quick enough with a bow I could get multiple events raised until a point in the EnderDragon death sequence eg. public class HandlerLivingDeathEvent { @SubscribeEvent public void onLivingDeathEvent(
  14. So TileEntity::validate did the trick. First try it got called on both the server and the client - which created a very impressive stack overflow. Limiting that to the server - which is where I needed to do it - allowed me to walk to the master. One initial concern was the algorithm I use to walk to the master was travelling over other TEs in the same chunk which had not yet had their validate methods called yet. However as I only use their position to determine the path and never try to access them, I don't think that is an issue. I'm now horribly emba
  15. I currently have a working multiblock with a mixture of ticking and non-ticking TEs. The main block (heart/master) is a ticking TE with a public method interruptStructure which basically tells it to do a scan of the multiblock. All the other blocks are non-ticking TEs which when block.onBlockAdded is called, find the nearest reachable heart and call master.interruptStructure. They do something similar for when the block/te is invalidated. So I've got a way to say hello-block.onBlockAdded and goodbye-te.invalidate This seems to work nicely until someone builds the mul
  16. I'm going to stick with the enchantment name solution, rather than trying a NBTPredicate solution. I'll mark this as solved and update the title to something more appropriate. Mainly so nobody thinks that the solution shows partial NBT matching.
  17. That was me using vanilla enchantments and thinking it would always work Thanks, I'll swap over to using the registry name instead. Github commit
  18. So I gave Choonster's pointers a go and I think I have something working. I added a new factory with my new type that allowed me to specify an enchant id and enchant level. The factory then parsed those json entries and applies them as the enchantment to the itemstack so it shows up in the recipe tooltips. The factory then created a new IngredientEnchantedBook object with the itemstack, enchantment id and enchantment level. The IngredientEnchantedBook apply method then uses EnchantmentHelper to pull the enchantments off the input stack and looks for the stored enchan
  19. I've had a bug report raised to me where my crafting recipes using enchanted books were not matching anymore. The issue came down to me testing with cheated in or enchantment table books and the user creating them with the anvil. The anvil added an extra nbt tag "RepairCost" that caused the book to no longer match in the recipe. So I'm guessing that the ingredient type "minecraft:item_nbt" has to match exactly and have no other nbt tags present. Does anyone have any pointers as to how to handle this situation of extra, unwanted nbt tags being present on
  20. So I think I've solved this, because my upgrade to Forge 14.23.1.2554 didn't fully refresh the dev environment. Now that I'm definitely running with the latest forge, it looks like my recipe issues are not happening anymore and I've getting unique items. So I'll pass on my apologies for wasting peoples time. (No matter how much you check, you always miss the obvious!)
  21. I had upgraded my mod to use the json recipes as part of the 1.12.X port and I believe they were working find when I first tested them. I used to use a custom recipe handler in the pre-1.12 versions. However I've recently retested due to a bug report (StoredEnchandments needing to use shorts in the nbt) and seem to be getting the same output item for all the recipes that have the all the same ingredients, apart from a different enchanted book. These recipes all use vanilla enchanted books as an ingredient. JEI shows the correct output for the input ingredients, but the vanilla c
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.