ChampionAsh5357

Not trying to be rude, but you clearly don't understand Java enough to do this. You're trying to understand programming through modding by following exact along with whatever script is written out. We are over 100 posts in and you're asking questions that can be solved just by hovering over and reading the error. You don't even seem to be trying to understand what is going on. That teaches you absolutely nothing other than how to fail. If you can't adapt your knowledge and problem solve, you won't be able to learn anything. So, for the time being, I will request that you stop modding and spend the next portion of your time learning Java up to the point where you don't need to ask a question relating to generics or constructors or anything that is well known Java. If you go about understanding multithreading as well, it becomes a much added bonus. Until you can answer the problem above on your own (as it's quite simple if you understood what generics are), then please take the time to learn. This forum is made to help people specifically with issues in Forge itself and not those brought about by a lack of understanding in Java. Note: you don't have to listen to me and just call me a rude and curse me out. I'm also not stopping anyone else from helping you solve this problem. I'm just requesting that you actually spend some time on your own to understand what you're writing. Calling yourself a programmer is being able to use your knowledge to adapt to whatever program you are currently using/modifying. Without that knowledge, it will be nothing more than repeating the same questions over and over again.

Placements are broken up into multiple parts. If you wanted to do use an old placement, you'll probably need a combination of at least two placements to be able to do that. Which ones you choose are up to you.

If you're talking about the background ambience, then that is still hardcoded in 1.15.2. A PR to forge is needed to expose the necessary fields to set the values.

Yes, since the event is synchronous, it should dispatch the event to the mods in the order they were loaded. If a mod has to be loaded after another, then the registry objects should be present when they are loaded into the registries. Just make sure your objects are deferred correctly else there will be errors when trying to construct the data.

I feel like you're asking a different question for something else's logic (maybe use item keybind), but it would be relatively difficult. You would need to use some sort of JVM witchery (reflection, AT, etc.) to manually set a value in MouseHelper.

That commit is over 6 years old, so I will have to ask what version is this for. Also, this makes little sense to me. Are you trying to stop a mob from spawning, grab it's drops, and immediately push to a hopper? If so, there is an event for that in latest called LivingSpawnEvent#CheckSpawn which has a result that you can prevent it from.

You're not returning an instance, you're returning a holder to that instance. For that, you need to create a holder that references your instance. You'll need to use LazyOptional::of and pass the instance in and then cast it within the method. Note that you should always return the super of the method in case something else decides to override it.

That's not how biomes are handled anymore. You need to apply it via BiomeLoadingEvent. Also, the register to WorldGenRegistries is a bit pointless as you are attaching it to the biome directly after it has been created.

I know how linear interpolation works, but you seem to have not read my entire post. If the movement of the entity is global, then the lerping should will happen already from the entity movement. However, if it's happening relative to the model, then that's where you would need to do you own manual interpolation. Else, you are just interpolating what's already has been interpolated. You can view this within BoatRenderer. There is no interpolation for the movement, just the rotation of the model pieces.

I'm going to break a few things down so you can correct it. As a person who's spread bad modding practices in the past, I don't want your videos to follow a similar path. 1) The build.gradle needs to be updated in a few ways. - The 'eclipse' plugin is not relevant since you are using IntelliJ, change it to 'idea'. - Update the version, group, archivesBaseName to your valid information. - All instances of 'examplemod' should be replaced with your mod id. - Fill out the jar manifest (this is not a requirement, but it makes your mod look more professional). 2) Update the pack.mcmeta to reflect the current information (again not necessary, but it makes it look more professional). 3) Careful how you hardcode parameters in Main as you should just store a single instance of the event bus and pass it around. However, that's most likely once you do your next object. 4) It's a waste of an object to only use it to hardcode a parameter. Doing it to use the double colon operator is worthless and just a waste of space. Your item (since nothing has changed) should just pass in a supplier with a new instance of the base item class. If you wanted to have all your items use the same properties, it's better to create a method that does it. Do note: be careful how that is done as you could end up making a deferred instance not deferred at all. 5) Use data providers to create your json files. Handwriting them is mainly just a waste of time and can be circumvented now.

Unfortunately, 1.7.10 is no longer supported. Please update to at least LTS 1.15.2 to receive support.

So imagine it like this. Technically, with a packet to synchronize it to the client, the client doesn't know anything about a slot either. What it does is send the container, slot id, and item stack. The container holds the window id (which should be the same on both the client and server version). The slot id holds the current slot it's in (once again synchronized by the client and server each creating their own version). Finally all that's left is the item stack sent. Once it puts all three of these together, it compares the open container window id with the packet version. If equal, it gets the client slot and pushes the stack to it. Your implementation of this would be similar. Any time you detect a change in the slot, you will send a packet to the client with the container window id and the current fluid stack. If you have more than one fluid, you can handle it similarly to a slot by creating a list and grabbing it from that. If you only have one, you can create a public getter and push the value to yours. Once you get this working, I will review the other problems you have. It's best to solve one problem at a time.

Are you sending the information from an entity/player or something that doesn't have a specified identifier (like a developer, console, server)? Each is specific for its use. Also, just edit the title of the forum, no way to specifically mark it. For extra reference, only use TranslationTextComponent. It allows localization.

Unfortunately, 1.14.4 is no longer supported on this forum as of the recent 1.16.3 RB. Update to at least LTS 1.15.2 to receive support.

That's not how you write java. # is used to specify that the following is either a field or a non-static method in most cases. It can also specify a static method however those are usually formatted with ::.

Make sure the code is isolated only on the physical client. And yes, it does need a UUID to specify which player its coming from or Util#DUMMY_UUID if it's coming from no player.

So your frame is of blue ice: so fix this https://github.com/mcDandy/Winks-mod/blob/master/src/main/java/cz/mcDandy/winksmod/Teleporters/OmegaTeleporter.java#L204. And the other one too. I'm pretty sure this: https://github.com/mcDandy/Winks-mod/blob/1703f1ec689c927b55679d656271813d38dcc107/src/main/java/cz/mcDandy/winksmod/Blocks/OmegaPortalBlock.java#L66 can't be used either since it specifically uses the vanilla teleporter. Also, register your own POI then and use it instead.

I feel like if I look at your Teleporter class, that would be easily answered in about three lines of code. That's what you get for copy-pasting. As for a custom POI, that's a registry. Although, that only matters if you are trying to link two portals together that are at different coordinates.

Isn't this already handled by LivingDamageEvent in some capacity? All you are doing is negating fire damage on the specific entity. My issues is that it's called every frame which would be already handled in some capacity by LivingUpdateEvent. Technically, I could just check if the entity is on fire and if it's daylight during this event and remove the fire effect. This negates the whole purpose of creating this event as otherwise it's just more processing time for the calls to go through synchronously. Also, if the event were to be called, it would be handled by ZombieEntity#shouldBurnInDay or an extra condition in PhantomEntity#livingTick for example.

Yes, that's the use of a packet through the network. But that should only be sent as needed as otherwise you just bottleneck the network creating more issues. No, that should be used in your registry instance for your ContainerType. Imagine it like this. You have two instances, a server and the client. The server creates a container with a specific window id. The client creates a container with the same window id and a screen that can get information from the container. The server container sends default information to the client container which is read by the screen. A client screen clicks something, which gets sent as a packet to the server container, which updates the client container, which updates the screen. Note that the client creates a new instance of the container on open so the information needs to be synced. By default, only slots and tracked integers are synced. If you want to handle something else, you need to send it yourself.

That still makes no sense. You're just bottlenecking the network. The data doesn't change until you send it. Also, the button shouldn't be the one doing it. It should be handled on the server once again. NOTHING should be handled on the client itself. It all gets synchronized via the gui. Only thing that doesn't is the string which should be what you send on button click. You missed the part where I said IForgeContainerType. Doesn't matter if their registered. If it's not using the correct type it won't send the packet. Not being rude, the original theory is wrong. The client doesn't hold data from the server. It will be reinitialized since it's pulling information from the empty client container.

You are using IInventory. Go and fix that and properly attach it with capabilities. But I won't be so stingy since you have been trying and cooperating so apologies for my agressiveness. As a precursor, try to avoid using Server or Client in your names, it confuses everyone. You're writing the carrier name twice? You're doing this every tick, only send it when the button is pressed. This should not really be handled on the client once again. This is not necessary if you send the information to the server. You will need to resync the values anyways whenever the inventory is opened regardless. Finally, if your container is not registered using IForgeContainerType, then the packet information will never be sent to the client. You should also store the block pos and not the te itself. That's rather pointless to do as all it's used for sending the position back to the server. The tile entity will still not store the position anyways.

Yes. Synchronization the wrong direction. Always good. I doubt you need to synchronize from the client->server as this probably just uses a standard inventory and primitives. In that case, you only need to sync from server->client. Which, you are still neglecting to listen and do. Please show your entire tile entity, block, container, and screen code. I am curious on what you're doing and how you're doing it since I'm pretty sure it's some variation of vanilla code which will not work in most cases.

This looks like copy and paste of an IInventory class, use the IItemHandler instead. You should not use the vanilla method to create your inventory. Ah yes, synchronization on block update. Something completely unnecessary when it comes to GUI. Those are synced through slots. This should only be used if you have a TER present. Then you fell into a trap of confirmation bias. Just because you get the same result doesn't mean it was synced correctly. It just means you probably executed the same code on both sides when it should only be on one and then synced.

It's like there are two sides of the game that need to be synchronized, hmmmmmmmmmmmmm. The client and server will not be synchronized under normal conditions, you must specify which variable you would like to sync and when (most likely in your container).