ChampionAsh5357

Don't necro an old thread. Create your own topic with your own question and source so that users may help.

Yes, the method should be static though. You won't see any issues in a standalone, but with other mods it will bottleneck other features from generating due to how codecs are handled with unregistered objects.

You need to register the dispenser behavior using DispenserBlock::registerDispenseBehavior.

You still need to register it but yes, that's exactly how you would do it. Take a look at the Features class for the registry method to copy and use. Since it returns the object itself, you can just modify as needed.

No, that will create the ConfiguredFeature every single time the event is called, which is too many times. This is not to mention you are no longer registering the ConfiguredFeature. Create a global field and initialize it within the common setup.

This is more or less a guess, but try checking the output of ProjectileItemEntity#getItem and where the entity is initially placed. It's either due to the fact that the position of the entity spawn is too low so it dies immediately or the item is not synchronized to the client for rendering.

Initialize the variable within the method event.

That would happen if you do not register the item using your extended item class.

Pixelmon has been taken down per request as of 2017, and any remake or addon for it is of questionable intention corresponding with the copyright held by the Pokemon Company. Also, 1.12.2 is not supported on this form, please see the above banner for the currently supported versions.

Yes, I would still like to verify that you deferred initialization and registry of the ConfiguredFeature to the common setup event.

Code Style 6. OnlyIn is used as a stripper to create the forge universal and server jars from one repository. Using it is more or less declaring that you didn't make sure your logic was only available to a certain physical side. In this case, it is completely unnecessary.

No, that's not what I said. I said the feature registry is irrelevant, you're not using it. The ConfiguredFeature should be initialized and registered during common setup.

You can override certain methods to disable light passthrough. Specifically, setting Block#propagatesSkylightDown to false will disable light passing through the block iirc. None that I would recommend. You can still use old tutorials like those of McJty with a little bit of care, but most of them should still be relevant. You can read this to get a small rundown of some changes:

The configured feature should be deferred and registered during common setup. In most cases, this would throw an NPE as the registries would not have been populated yet. You're technically cheating by lazily loading the class using a register method for a deferred registry. They should always be attached within the constructor. Just simply register normally in common setup instead of lazily loading a class in a potential error way. Since you're also not creating a feature, it makes no sense to attach the register. This creates a configured feature using the standard ore algorithm feature which replaces anything within the stone tag (BASE_STONE_OVERWORLD) with silver ore in up to veins of 9. Reading inward, the feature is placed 20 times (func_242731_b) based on a random x/z position in the chunk (square) from 0 - 64. If the block the placement lands on is not valid, it will not generate the ore in that location.

It does have the same behavior as the normal crossbow, you're just assuming it doesn't because you cannot visually see the change. For that, you would need to add some properties using ItemModelProperties and handle the arm pose within PlayerRenderer using the RenderHandEvent and client setup.

You should post your repo so that we don't have to guess. If I had to, you're probably create static final variables without considering loading order for the configured feature. In which case, they need to be registered during common setup or at least after placements. BiomeLoadingEvent holds methods. Read the javadoc and look through the method to find which one is used to add a configured feature.

Using SoundEngine or SoundHandler inside the event will not do anything as the sound hasn't started playing yet. Can you debug with a breakpoint to check whether the result is actually being set to null or not?

The minecart tickable sound should be able to be set to null within PlaySoundEvent with no issues at least from my testing. How are you checking what sounds are being played and which ones to mute, and is this after they begin playing the sound or before the sound is initially loaded? Where are you calling the SoundEngine and SoundHandler methods as well?

1. Create a ConfiguredFeature and register it (look at the Features class for examples). 2. Attach it via BiomeLoadingEvent (read the javadocs on the event as applicable to your situation).

Look at vanilla jsons that support the sort of face mapping you want, there is one that handles the sides, top, and bottom. On the other hand, use a block state data provider to do this for you.

To create a custom entity, it needs to be specified with a custom type. Otherwise, vanilla packets will take a semi-precedent when synchronizing data which can be problematic in a lot of cases. In the case of a projectile entity, it only needs the attached renderer and the registry entry.

The issue with reflection normally is that methods and fields have different names depending on their mappings. Forge in a universal environment will use the srg names (field_123456_a_) while a dev environment will use the mapping names (example). How do we fix this? In comes ObfuscationReflectionHelper where it will take a srg name string and map it to its current mapping environment as needed. So, the field/method being specified must be the srg qualified name. You can find these names using '!mcpf <field_name>' or '!mcpm <method_name>' via dming the forge-bot over on the forge discord.

Specify a modded Item instance instead of a vanilla Item instance within the first argument of the ItemStack.

Well then, if you're saving data via the logical server, you can check FmlEnvironment#dist to see if you're on the physical client or physical server.

But why not save the data on the player regardless? A singleplayer world still has as associated integrated server that others can join.