Ommina

Answering without actually checking first -- but I want to say that "US" should be lower-case.

OK. In 1.14.4. I have a block model that is 3x3 actual blocks in size. It will place in the world just fine, and I can change the "this is the block you are targeting" outline through getShape. Unsurprisingly, though, only the centre block actually exists as far as the game in concerned. Entities can walk though, and blocks can be placed in, the remaining 26 spaces. I know this has been done many times by many people in the past, so I'd like to turn to the wisdom of others before trying my own solution. As I see it, there's a couple of options. 1) Keep it as one block, but fill in the missing blocks with transparent filler blocks on placement. I like this one, but I don't see a really convenient way to indicate to the player that "this block needs a 3x3 space to place. Oh, and make sure there are no entities in that space either". 2) Go the more traditional controller+extra blocks that are placed individually, that vanish and turn into the model when the last block is placed, presumably by the central controller block continually scanning the other 26. In this case, I do not have any capabilities attached to the block. (But it DOES have to respond to redstone). But I'd be interested in hearing how either approach (or any other) works better for capabilities. So, my question. What's a good way forward here? Are there other options that I have not considered? Which is least likely to come back and bite me later?

In 1.14.4, ForgeChunkManager no longer seems to be a thing. There's plenty of mentions of it, but they are all commented out, and net.minecraftforge.common.ForgeChunkManager just isn't there. Is there a viable replacement for it that I simply have not found? I believe I can do it myself via ServerWorld, but that strikes me as less than ideal. Tks!

Much of that kind of behaviour (sounds when jumping into/out of, entity push, drowning, fall damage negation, likely others), is enabled simply by adding the fluid to vanilla's water.json tag. Likewise, burning can be enabled by adding to the lava.json tag. But, I've not done much research into if this enables too much (spawning freshwater fish into a mod's brine, for example).

You can use TextureStitchEvent.pre to add your textures, instead of creating a block or item. This may or may not also affect issue two. (I've not seen any texture problems, so far) That said, gigaherz has made further changes to the Fluid API that will remove the need for the manual texture stitching entirely. Keep an eye on Forge PR #6110 for details there.

Well, you can start with this New Fluid Test class, and stumble on from there. Taking a peek at the vanilla Water implementation would not lead you too far astray either. At first glance, it looks pretty straightforward. It's the second and third glances that make the room start to swim, followed by the need for a little lie down. As such, take the following as the confused mumblings of a man who has spent too many hours bumbling in the dark, trying to get it to work. The Forge dynamic bucket seems to be gone. Instead, you create your own bucket item via new BucketItem. As a plus, you can provide your own empty container and stack size, so creating some alternate fluid container, say, a squirt-gun, is pretty easy. Blocks have Block.Properties. Items have Item.Properties. Fluids have Attributes. Attributes hold all the mod goodness for the Fluid. Temperature, Colour, etc, go here. The fluid needs a block. It is created via new FlowingFluidBlock, and has a blockstate and model like any other block. Seems to have 'level' as a variant, so one could probably point to different models based on the fluid level, should one want to. I have not tried. The fluid itself is registered in its own registry. It looks like there are two distinct fluid objects created per custom fluid. A "source" version (what you would see if you place the fluid in the ground, surrounded by eight blocks to ensure it doesn't try to wander off), and a "flowing" version (what you would see if you broke one of those eight blocks and let the fluid spread). Naming may or may not be important. But then it gets a bit unpleasant. Fluids are registered after blocks, but the FlowingFluidBlock needs a Fluid object. The BucketItem also requires the Fluid. The custom fluid class ( MyFlowingFluid, in the example above, extending from vanilla's FlowingFluid ) in turn contains references to the bucket, the attributes, the block, and, indeed, to itself. The Test class creates the Fluids from the Block registry event, which is the kind of thing that makes people itch. I'm hoping there is a better solution. -- And that's the summary of my understanding. It may contain errors. If those that know better which to correct my egregious missteps, they are invited and encouraged to do so. -- Edit One: I'm seeing code to the effect of ModelDynBucket, so there may be dynamic buckets after all.

As for the rendering explosion, post the updated code and I'll give it a go locally. I've got a block to port from 1.12 that has pretty much identical rendering, so I'll work on that and see where it leads.

Hm. Well, you want a horizontal plane, so I'd try something to the effect of: buffer.pos(0.06, 0.5, 0.06).color(1,1,1,1).tex(u1, v1).endVertex(); buffer.pos(0.06, 0.5, 0.93).color(1,1,1,1).tex(u2, v1).endVertex(); buffer.pos(0.93, 0.5, 0.93).color(1,1,1,1).tex(u2, v2).endVertex(); buffer.pos(0.93, 0.5, 0.06).color(1,1,1,1).tex(u1, v2).endVertex(); and see if it explodes.

When you see stuff rendering all over the place like that, the values bring provided to the .pos() function need to be prodded. 4 is too large. Also, pay attention to the order. It counts. As an aside, when testing the renderer, start with just one instance of the TE in your test world. It's a lot easier to see the effects of a change when you can be confident that you're not seeing overlap from nearby tiles.

I think there's two things going on here. First, you're not giving it a texture of what to render. If you look at the pnc-repressurized example you linked, you'll note the TextureAtlasSprite still = Minecraft.getMinecraft().getTextureMapBlocks().getAtlasSprite(f.getStill().toString()); code, along with the inclusion of .tex() in each of the buffer calls. You'll want to include something quite similar. (My suspicion is that this it the step that is needed to bring the rest together for you.) The values you are providing to .color() may or may not need to be fiddled with, depending on the colour of your original texture. Second, the values you are passing to each buffer() call. "1" is "one block", so the fours used are, well, four blocks. To keep the fluid in your bucket, you'll want some fractions in there. I wholly agree that you only need to render the 'top' of the fluid. As an aside, this is in the context of 1.12.2 -- but I very much doubt it has changed any for 1.14.2.

Chunk Loading Does Forge still provide a means of force loading chunks? ForgeChunkManager no longer appears to be a thing (or if it is, I'm not able to find it). There seems to be vanilla alternative that looks promising, but before I start chasing down unknown rabbits, I'd like to ensure that I'm not doing so pointlessly. World Gen Again, a confirmation to ensure my current understanding is correct. As I take it, world gen (in my case, large fluid spheres) is now handled by vanilla Features, instead of IWorldGenerator. However, a given feature is limited to a single chunk. (I'm really trying to avoid making a "that's not a bug, it's a Feature" joke here). I can deal with it if so, but as I'm mostly just stumbling my way through the vanilla code, I'm hoping somebody with more experience can confirm or deny the "one chunk feature" conclusion. As always, thanks very much.

I would like to respond to the mouse wheel being scrolled (with a modifier to avoid interrupting scrolling between items on the hotbar). But I'm struggling to find an event that works. InputEvent.MouseInputEvent has 'button', 'action', and 'mods', but nothing for scrolling. There is a GuiScreenEvent.MouseScrollEvent, but this only fires when a GUI is open (logically enough). I'm only interested in the event when a GUI is not open. In 1.12.2 there is a MouseEvent, but this is now missing -- presumably replaced with the InputEvent above. Am I merely missing seeing its replacement? If not, is there some other means of responding to the mouse scroll wheel? Thanks!

This is not a rant about JSON. -- In an effort to ease myself into 1.14, I've taken up the task of updating a 1.10 decorative mod with a largish (2000+) number of blocks. I'm about to create the loot tables for them, which, it appears, means an additional .json file each. This is fine -- automating their creation will take upwards of a few minutes. BUT -- is there a Better Way? This is a task that, at first glance, seems to be better done in code. But I also acknowledge the move toward data packs, which the code solution precludes. So, if creating all those .json is the Right and Good Way, then super! I'll do so and get on with my day. If not, well, that's good to know too. Second. I would like to organize these myriad of files into sub-directories because, well, because it feels better to have them organized. I can do so by including a \path at the start of the registry name. "foo\mynewblock" will happily let me use \models\block\foo\mynewblock.json, etc. Which is what I want, but it feels weird. Recipes, /give, and whatever else that needs the block name now have to deal with the 'foo\' prefix, which I've never seen done before. As such, I'm interested in opinions and/or alternate solutions here. Keep the prefix and have the files organized, or just dump them into a single directory and move on? Or other? As always, thanks for your thoughts.

Before even looking at the source, there is a couple of stumbling blocks. There is no license attached to the GitHub repo. The license listed on the CurseForge page is "All Rights Reserved". While there is a comment from the author that he would 'like to see it ported', the licensing, as it stands, suggests "complete rewrite from zero, using ideas but no code". (IANAL, etc, etc.)

As I see it, you've got three options: Wait for the mod author to fix the issue. This may happen tomorrow; this may happen never. Try to edit the offending entity (or entities, I guess) out with an nbt editor. May take some poking about, but since you know your friend's location via the log file, you should be able to narrow it down to the correct region. Remove the mod entirely.

Looks to be this issue with Wizardry. Beyond that, I've not got much to offer. It doesn't appear to be an update method, so I'm unsure if setting forge's removeErroringEntities option to true will do any good.

OK. I have a greyscale texture, and an RGB value. At startup, I would like to create an item with the texture recoloured with the RGB value. It is a pretty simple item otherwise. Not armor, not a tool, no durability. Right now I'm using IItemColor, and it's working just fine. BUT, I'm feeling a lot of guilt over using it, as it is called every frame, and the colour really is fixed at startup. It is not dynamic based on conditions (biome, phase of the moon, whatever). If it is blue now, it's going to be blue later too. As such, I'd really like to colour the item once, at startup, and be done with it, all without feeling like I am contributing to a drop in framerate -- however slight -- unnecessarily. The closest I've found to achieve this is the forge dynamic bucket, but that seems to be well more than what I'm looking for. Maybe I'm mistaken here. I COULD just recolour it manually in an image editor and get on with my day, but I'd very much like to be able to tweak the RGB values without manually recolouring the textures each time I do so. Any suggestions? Is there a simpler example than the forge bucket that I can use to light my way? Thanks.

Yay! Er, well, yes, I get that. I'm quite content with what is is. I was more interested in knowing if the cause (in the OP's case) was the notifyNeighborsOfStateChange call. As @Matryoshika has got it working to his satisfaction now, I'll happily move on.

I could be reading it wrong (and I'd appreciate the correction if I am), but I am suspicious that the cascading generation is happening when your right on the edge of the generated chunk. While you're checking that the BlockPos is within the selected chunk, the call to world.setBlockState subsequently does a notifyNeighborsOfStateChange which prods at the six blocks surrounding your selected BlockPos. If you're right on the edge, one of the adjacent blocks horizontally will be in the next chunk. At least, that's my take as somebody who is pretty new at this. If it turns out I'm way off-base, I should probably go back to lurking.