Jump to content

logalu

Members
  • Posts

    7
  • Joined

  • Last visited

logalu's Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. Thanks for the reply. Good to know I didn't cause this, not so good to know this is unavoidable, but it is what it is Marking as solved
  2. Hi there, I've implemented an Item with a 1-slot inventory using capabilities. The inventory is then accessible through a GUI on item right click. Everything seems to work fine, but I've observed that the `serializeNBT()` method is fired too often (every tick apparently) when the item is in the players' inventory, even though I do not fire at all such method manually (afaik...). Is this the expected behaviour of the capabilities system, or am I missing or wrongdoing something? Thanks in advance
  3. I'm trying to draw an overlay over one of the hotbar icons whenever a specific condition is met (e.g. you're holding a stick and you're pointing it to a block). So I'm listening to the RenderGameOverlayEvent.Post event, checking if the event type is HOTBAR, and then drawing the overlay if needed: However, the overlay gets drawn behind the hotbar, as it the hotbar was being rendered after it. Check this clip: https://imgur.com/a/HJCtrnM Using a different event type like ALL, which gets posted to the event bus later in time, seems to be a workaround in Forge 31.0.14, but in Forge 31.1.16 it still fails, though differently (the overlay renders correctly at first, but it eventually goes behind the hotbar item icon). This same piece of code works fine in MC 1.14.4, and checking briefly (and with my very limited knowledge) the ForgeIngameGui file, I don't see why this is failing. Am I missing anything, or is it a Forge bug? Thanks
  4. Simple and neat solution, working perfectly. Thank you very much!
  5. I've been refactoring and upgrading one of my mods, and one of the changes I wanted to make was to move from the old IInventory to the newer capabilities system. I must admit that I've been having a hard time grasping the new concepts, but I think I've managed to at least get the basics related to my use-case. That is, I have an entity which has an associated inventory, that can be accesed through a GUI when right-clicking such entity. Given this simple goal, I decided to use the provided ItemStackHandler implementation of IItemHandler, and I've sucessfully done the required changes for the core things/GUI to work (overridenhasCapability/getCapability, changed Slot to SlotItemHandler in the Container, persistency with NBT, ...). However, I'm now facing a problem. The entity's inventory is not a generic storage, but more of a group of specific slots. That is, slot # can only hold one kind of item, and the entity must update some of its variables depending on the slot being filled or not. In the IInventory version, I had the Entity class implement the IInventoryChangedListener, and then I performed the corresponding checks and updates in the onInventoryChanged() method whenever the IInventory was modified. Now with capabilities I'm unsure of the approach to take. The ItemStackHandler class does contain a onContentsChanged() method that gets called on inventory update, but overriding it doesn't make sense right now as I'd need to access the entity's update methods from the ItemStackHandler class, which does not have access to the entity (or does it somehow?) The possible solution I see right now would be to create my own implementation of IItemHandler, very similar to ItemStackHandler but taking the entity as an input parameter so I can then use it to call the entitiy's update methods in the onContentsChanged() call. But I feel this ain't the right approach, or is it? Is there any listener similar to IInventoryChangedListener in the new capability system, or am I missing anything else in general? Thanks in advance!
  6. I'd already seen that, my question was more in the sense of differences towards the better approach. I probably used the wrong words, so nevermind and let's just focus on the real issue. However, my question was motivated because the first alternative I tried was exactly to override the isSideInvisible() method, yet it doesn't seem to get called. This should prevent rendering of all adjacent sides, right? @Override @OnlyIn(Dist.CLIENT) public boolean isSideInvisible(BlockState state, BlockState adjacentBlockState, Direction side) { System.out.println("Test"); return true; } I might be doing something wrong, but I'm just overriding the method. So I was just trying to get a general answer about the issue, because maybe I was approaching it in the wrong way, and as I said I'm relative new to Forge modding. Are there maybe other related variables/methods I need to override too? Apart from that, there's no need to be hostile imho. Yet I once again apologize if my lack of knowledge is a problem...
  7. First of all, I'm relative new to modding so please bear with me if I make some dead wrong statement or mistake. I have a custom block, similar to a stained glass pane (i.e. not full block, translucent), and I want it to cull sides when two blocks of the kind are adjacent (to prevent rendering inside faces, basically what happens with glass blocks). In 1.12.2, I could override Block#shouldSideBeRendered and put my logic there. However, in 1.14.4 the method seems to be static now, so I can't obviously override it. What is the correct approach in this version? I'm having a hard time finding anything useful/working regarding this. Also, semi-related question: what's the difference between shouldSideBeRendered() and isSideInvisible()? Thank you in advance for your time ---- EDIT - SOLVED The function to use in 1.14.4 is indeed isSideInvisible(). The method wasn't getting called because I accidentally removed the cullface option in the corresponding .json file (don't ask me why, stupid unnoticed mistake that drove me crazy and made me questioned myself and my understanding of stuff...)
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.