TheMasterGabriel

You are a rare occurrence, as lots of people just try once, can't figure it out, and come back here in frustration. Thanks. As for that phrase, you don't need it. The Decorate event is not a cancelable event, so checking for receivedCanceled doesn't do anything.

You are playing on a recent version right? Duel wielding, no? As for client/server, this.

Oh, if you are doing something like that, then yes do what @diesieben07 suggested. Mind you should also check for invalid registry names and metadatas as well, if the file can be edited externally, just as an added measure.

That would probably hog resources, as you might unload/reload chunks several times. If they didn't unload, that would probably be worse, as your computer would be keeping multiple chunks loaded for 1 block in a completely different area. A solution might be to, if a world operation cascades into another chunk, stop and queue it for when that chunk loads. That way you wouldn't run into cascading chunk gen/loading, but rather have operations waiting to take place. I'm not sure about the feasibility of that, as I can already think of some instances where that wouldn't be ideal (like if you TE needs to check blockstates rather than set them), but I'm just throwing ideas out there for what could be a really useful PR.

When you set your item/block's registry names, make sure to add the modid as well. Not doing so will default the block to vanilla's json location (minecraft:block_banana), which you do not want. In your case, it would be 'examplemod:block_banana'. Forge usually flags mis-registered names as containing a dangerous prefix, so not sure why it didn't in your case.

What exactly do you mean by world gen functions? Like trees and stuff, or the physical terrain?

The easiest thing, in my opinion, to do is save the block state in a reasonable way, which would be serialized NBT data. Save the blockstates via NBTUtil#writeBlockState and write the NBT data to a file (I haven't looked into this whatsoever, but I can't image it would too difficult). Then when you want to compare them, for whatever reason you are doing, read the NBT data from file, deserialize it via NBTUtil.readBlockState, and compare them. Why are you doing this, anyway? Are you sure there isn't a better way achieving the functionality you desire?

You can also use this tool by @TheGreyGhost

DecorateBiomeEvent.Decorate gets called for all vanilla chunk decoration. You can listen to the event and cancel it if the EventType is TREE. Doing so will prevent all vanilla trees from spawning.

It would be helpful if you posted all your relevant code so we can see exactly what you're doing.

Use ModelLoader#setCustomModelResourceLocation, not the vanilla way.

It's also a good idea to, whenever generating stuff in the world, offset the gen position by 8 on the X/Z axes. If you don't, you could run into cascading chunk gen problems.

If could even look into Registries and Forge's RegistryBuilder, although it is probably not needed for your case. Something for future endeavours, perhaps.

Even if you could, however, it would probably cause chaos in the model system, as you could theoretically add a block property to a block after the model loads, which MC would not know what do with when it tries to render said block. So, I think you're restricted in terms of options: - Make the IProperty accessible via an API and have other mods use and implement it themselves, which you would need to check for whenever you wanted to do something with the block. (This doesn't help in editing vanilla blocks) - Abandon dynamic properties in place of something else - Manually add substitutions for all the vanilla blocks you want to change, via the GameRegistry#addSubstitutionAlias

If you were to implement something like that, you would need to ensure that the TE's world access is restricted to the chunk it is in. If you were to allow it to access block positions arbitrarily, then a modder could really easily overflow into an unloaded chunk, which would undoubtedly cause tons of problems. Edit: Also, did you try looking at ChunkEvent.Load? I didn't look into the load order that extensively, so you might run into the same problem. If not, however, you can probably use it, along with a list of TEs to be ticked, to get something that would work similar to your TE#onLoaded.

You can probably use an IItemPropertyGetter, which can be used to change item models based on certain criteria. They are used by bows to change the texture depending on how long you have been holding down right click, for example. You can see how to use them in ItemBow and its associated json files. Edit: Also this post if you want another example.

Yes. If you registered an itemblock with your door, that would mean you could place the top/bottom parts independently, which wouldn't make any sense. As you state, you can already do this. An ItemBlock is just an Item that places a block when right clicked. It is not a block. You are crashing because you are setting the registry name of your ItemBlock to the same registry name as your Door placer.

Hi, So I'm trying to figure out how to make my item do something unique whenever it is swapped from offhand to mainhand. Specifically, I want it to turn into another item. I tried looking, and it doesn't seem that there is a way to detect when a keybind is initially pressed? MC does it (or is at least supposed to do it) internally, but I can't seem to find a way of accessing that information. Does anyone know a method of doing so? Also, unless I'm reading the code wrong, it doesn't look like MC keybind functions are working correctly. Within the game loop (Minecraft#processKeyBinds), its made to seem like you should only be able to swap item hands when the key is initially pressed (and in fact, the comment on the method being used states that it is supposed to return true for initial key presses only). However, I can just hold down the key and the item I'm on will just rapidly switch between the left and right hands. Edit: It looks like there is an empty event called KeyInputEvent that gets fired whenever the keyboard it used. I presume I can do the initial check manually, but from the code it looks like KeyBinding#isPressed is already supposed to perform that logic? Another Edit: So I've realized it's kind of pointless to detect when the key is pressed, as it results in a packet being sent server-side to perform the logic. As I don't want my item to actually switch hands, I need to effectively cancel the hand swap. Any idea on how this would be done? Perhaps something to do with intercepting the packet between client and server and replacing it with my own packet?

You could probably make an entity that extends EntityMinecart that contains all your changes. Then you could listen for the EntityJoinWorldEvent event, cancel it if the spawning entity is a minecart, and spawn your entity instead.

Is it just the rendering that's the problem, or is the entity hitting your player when you throw it? If it's the latter, it might have something to do with MC-88491.

As I said, I haven't dug that deep into it. It looks like increasing the tracking frequency fixes it somewhat, but that might just be a side effect of some other problem. (Also, it doesn't seem to make sense to me why the update frequency would have different effects on your entity in comparison to the vanilla ones, which makes me believe its the latter of above).

Try making the update frequency larger. 3 might not be large enough for the fine movements you are trying to achieve. You will probably have to play around with the values a bit. I haven't looked into it much beyond EntityTracker, but you could always try Integer.MAX_VALUE, as it seems some vanilla entities use it.

You can access all of Forge's registries via ForgeRegistries. Note, however, that when you iterate over the registry, you will only be iterating over the things that have already been registered. If a mod loads after yours, it will not be in the list. Edit: This is assuming you are doing the iterating in preInit, as Draco said below. If not, ignore that second part.

Minecraft has no concept of what you've changed unless you explicitly code it to. When a chunk generates, it looks at what biome it is supposed to be, generates the height map (placing the biome-specific surface blocks as well), and then decorates it with ores, trees, structures, etc. Then that's it; it will not be generated/populated again. Once a chunk has been generated, it stays in that state forever (unless a mod regens the chunk manually, like Rejuvenation Missiles from ICBM). In your case, if a chunk generates before your ore is set to spawn, it will not spawn in that chunk. Any new world decorating you do (like fixing the spawn rate of your ore ) will only occur in freshly generated chunks. Edit: The fact that you were iterating over such a huge number of blocks also probably led you to think nothing was happening, when in fact it either crashed internally, was just taking a ridiculously long time, both, or something in between.

So it was VS? Yea, that's weird. I would consider that a bug, but can probably be fixed via runtime minification or some other cleverer method.