pkmnfrk

Today I decided to look at starting to port some of my mods to 1.13.2, and I have a question about the state of Fluids in Forge at the moment. In 1.12.2, it was easy: Fluids all derived from net.minecraftforge.fluids.Fluid, you could make FluidStacks from them, look them up in the FluidRegistry, etc. However, in 1.13.2, it seems like Fluids are broken. FluidRegistry is missing getFluid, FluidStacks have their getFluid lookups commented out, there are now two Fluid classes (the new one in net.minecraft.fluid). It seems like it's all very in flux. Is this a correct assessment? Or, is there a whole other new system that I'm missing?

Consider this model: I would like to animate this such that each orange piece rotates 60 or so degrees, but attached to the previous pieces, such that the cumulative rotation for the last one is 180 degrees. However, based on the documentation and Animefan8888's tutorial (which I used to successfully animate another thing), it seems like that might be beyond the capabilities of the built in animation. Is this assumption correct? Has anyone animated something this complicated? (I think that I could probably calculate the rotation of each piece manually and feed in the positions via variables, but it would be nice if there was a way to do it directly.)

I removed the transformations which I suspect/know did nothing, and put the quoted code in the defaults section. I just pushed the commit, so you can see it here: https://github.com/pkmnfrk/factorycraft/blob/1.12.2/src/main/resources/assets/factorycraft/blockstates/iron_boulder.json

Ok, the only thing you have that I don't is: "transform": "forge:default-block", "gui3d": true Which doesn't seem to change anything when I put it into my block state. To be clear, what I'm expecting is for the rotation in each model to be applied when the model is composited. I'm pretty sure the fact that it doesn't work (but it does if I reference a model directly) is a bug.

The rotation specified in the blockstate json was copied out of the model in a half-baked attempt to apply rotation to the entire model. I forgot to remove it before comitting. Or, if you're referring to the model rotations, I'm going strictly by the Model format (https://minecraft.gamepedia.com/Model) and what the editor I'm using shows (https://blockbench.net/) which has so far been correct when I'm not using submodels. I'll be honest, I don't know what a quaternion is, but I will look at your example and see if I can make sense of it.

I have a block that has 5 variants, each of which is a meant to be layered on top of the final block, depending on a BlockState property. In the actual world, this block works A-OK. However, there is a slight issue with the block when in your inventory. As you can see, the block is being rendered directly from the side, which is undesirable. Also, you can't see it in this screen shot, but the in-hand model is being rendered behind me. I added display options to each composite model to rotate them, and if I put a single model in an item directly, it rotates correctly. Am I doing something wrong, or is this a bug? One of the models: https://github.com/pkmnfrk/factorycraft/blob/1.12.2/src/main/resources/assets/factorycraft/models/block/boulder/0.json The main blockstate json: https://github.com/pkmnfrk/factorycraft/blob/1.12.2/src/main/resources/assets/factorycraft/blockstates/iron_boulder.json The test item in the second screen shot: https://github.com/pkmnfrk/factorycraft/blob/1.12.2/src/main/resources/assets/factorycraft/blockstates/test.json In that last file, if you change the "inventory" variant to be the same as the "normal" variant, it breaks the same way (doesn't rotate) Edit: Thinking about it, this would not be too difficult to avoid using sub models for (I could just make 5 models that roll up the different pieces), but I can foresee issues in the future for more complicated blocks that would make this a pain, so I would really like to understand this issue

Have you looked at your logs?

Thank you both for reporting this properly, I would have created a real thread had I been able to capture some video showing it.

I'm not sure if this is related, but when I install 2762 (even into my dev world, which only has a handful of mods), I get awful stuttering when I move around. I suspect that's why it's not released properly. Edit: I tried capturing a video, but it doesn't seem to show as bad on the video. But, it's pretty bad.

I can't stress this enough; I looked at ItemStackHandler, and I need literally 0% of that code. I promise. I have no interest in actually storing any items, they turn directly into EMC at the threshold.

I understand what you're saying, but in this case, it would be far more effort to synchronize the non-virtual inventory of the ItemStackHandler with the actually virtual data that I'm presenting. Some background: I'm creating an addon for ProjectE that exposes a player's transmutation data as an inventory for automation purposes. If you're not familiar with ProjectE, it allows you to convert items to/from a currency called EMC. Eg, a piece of cobble is worth 1 EMC, while a furnace is worth 8 (because it's crafted from 8 cobble). You can sell the furnace to get 8 cobble back, or another furnace, or any other 8 EMC worth of items. So, what I'm doing is taking the player's knowledge (which is a list of every Item they've put into this system), and their current EMC, and exposing how many of each you can make at the moment. So, if you have 64 EMC and knowledge of Cobble and Furnaces, then I expose 64 Cobble and 8 Furnaces. If one of these items is withdrawn, I deduct the EMC, and update the book keeping internally. Similarly, if you insert an item, I basically void the item stack and credit you the EMC. Therefore, there's two tricky parts that ItemStackHandler wouldn't really help with: 1. These virtual slots change quantity based on how much EMC you have, not based on how many items you have. 2. The idea of slots is very nebulous. You can't move items arbitrarily, and the size of the container depends on how many items you know about, since this list is coming straight from an external data source (ProjectE's api) I agree that it would be possible to overcome this, but I suspect that I'd have to override every single method with implementations that look very similar to what I have, plus some extra code to sync with ItemStackHandler's idea of inventory. The only part I wouldn't have to touch is the NBT serialization, and that's because I don't need to save this inventory at all (because it doesn't really exist) TL;DR: I did think about it Edit: My implementation is complete, and is part of the repo I mentioned in the OP. The one thing I did poorly that I'll probably refactor today is that I implemented it as part of the TileEntity, and I should probably have made it it's own class. I just need to think about how to do that properly, but that's a different matter

Hm... I guess I'm struggling to see why that would be necessary. I guess I didn't mention explicitly, but there's no way for the player to directly interact with this inventory; it's strictly meant for automation purposes. So, there should be no circumstance when the client is trying to view it... *tries things* Oh, actually it turns out that I'm just an idiot, the crash was happening on the server side because I forgot to create the hash map. It has nothing to do anything. ?

I have a block that acts as a storage provider based on an ephemeral inventory; it doesn't use ItemStackHandler or anything because the inventory is virtual. So, I'm implementing IItemHandlerModifiable manually. However, I'm getting a crash on the client side because the data that I use to calculate the ephemeral storage is on the server, not the client*. I'm not looking for help diagnosing the specific issue, but for help in understanding where it is expected that these capabilities should run properly. Should I be wrapping getSlots(), etc in if(!world.isRemote) ? Or is it expected that this should all work correctly on the client side too? Or (and this is the most likely scenario) am I completely misunderstanding how this all works? My code, if it helps, is here: https://github.com/pkmnfrk/equivalentintegrations. If it helps, the crash happens here, because the cachedKnowledge List isn't populated, because the client never gets to load the data it would need to do this. * - Unimportant background: I'm extending ProjectE and hooking into transmutation data. Technically this is in fact synced to the client, but I'm adding the possibility to use other player's data, which obviously would not be synced. So, I'm try to assume that this is server-side only.

Wow, that was easy, thanks!

Hi, this might be a dumb question, but is there any way to not use a random player when debugging? Aside from packaging the mod and running it in release mode, that is. Google isn't helping much; the only topic I could find on the subject was this one from 2012, where the answer was "just use Start.java". I don't necessarily care about using a real account, I'd just like for the player's UUID to stop changing every time.