ChampionAsh5357

That would make sense as they are the same value. It doesn't always return null. It will do this when the world and/or chunk initially loads since the logical client doesn't exist until it is loaded on the server. However, after the initial startup it should be on both logical sides. I haven't tested it as much so I'm not completely sure this is the case all the time.

Combine the two models into a single model. Create some parameter that checks whether the entity is moving. A simple DataParameter<Boolean> should do the trick nicely. You could also check the velocity of the entity depending on if the entity Set the value to true whenever the entity is moving and false when it is not. Override preRenderCallBack in your EntityRenderer and have your ModelRenderer#showModel value switch whenever the player is moving or not. You should probably keep a cached value inside the renderer so that you do not call the change every frame as that would be redundant.

Assuming you mean when the player strafes left and right, there are KeyBinding for those values in GameSettings. If not, create KeyBindings for those values. That's probably the easiest way as KeyBinding has a boolean method that checks if the key is down (for continuous querying) for if the key is pressed (for the initial press of the key). Also, whenever you handle any input from the keyboard, there should be a KeyBinding assuming that its a feature within the modification you are creating.

Then you're gonna have a lot of problems. The workbench is programmed so simply that if you copied the workbench exactly (provided you updated the way of handling containers), you would only need to change a single line of code within the container.

I am wondering if it is reasonable to expand FurnaceFuelBurnTimeEvent to include an instance or some indicator whether it's being executed in a standard Furnace, Smoker, etc. I am writing a simple listener that allows fuels to be mapped by datapacks based on the associated tile entity. I was thinking of something that has a bit more variability and customization compared to each abstract furnace instance all having the same fuel input. If this is reasonable, I can program the small changes to make it so.

I mean sure. It might just be easier to create another stat or capability on the player that increments every time a block is broken. It would increase the speed by a factor of n.

GuiOpenEvent is called before the gui is open. You can cancel the event making it apparent that it doesn't load data yet. Use something like GuiContainerEvent on one of the layers to get the client information since the gui will have been initialized to be open.

There are three constructors in Explosion, two of which are client side only.

Signs are rendered through TileEntityRenderer. You cannot change the model. The most you can do is change the texture. If you really want to change the model, create a new block.

Assuming that the values are loaded when you call bakeCommonConfig, call it directly afterwards. Make sure to check that you are on the logical server and not the client. If you cannot check if its the logical server, use one of the FMLServerStarting events to do it instead.

I do not know of any for 1.15. However, the process isn't quite difficult from what I remember. Just create a final instance of the KeyBinding by using its constructor and then register using ClientRegistry#registerKeyBinding during the FMLClientSetupEvent. Remember that this is client-side only so any data received must be sent via packet to the server.

Ok then. For quick reference though, KeyInputEvent is client side, so calling a packet to be sent to the client side from the server side on the client side doesn't actually make sense.

You might wanna get a blockstate for that.

NETWORK_INSTANCE.send(PacketDistributor.ALL.noArg(), NEW_PACKET_INSTANCE);

From an event since they could be subject to change whenever the config is reloaded.

It's the same way you create a block model. Either go pure json or use one of the many modeling softwares there are to write the json for you. One of popular ones is Blockbench.

Note: InputEvent is client side only. So, your client config takes precedent. Use a packet to send over the server value and store it in a variable.

I think you just have to add the damage code to the event. I'm not sure whether the code in the overrided method would execute in the interact event. However, you could always test and make sure.

That would make sense. Right clicking an entity triggers the Entity#processInitialInteract method or eventually MobEntity#processInteract. I would recommend using the event PlayerInteractEvent#EntityInteract to program in the damage of the offhand item for easy access.

Assuming that what you want to check is accessible on both the logical client and server yes.

Client, Common, and Server I think is being misinterpreted between logical and physical. The configs refer to the logical side. When deciding between common and server configs on the physical side, the Common/Server configs take precedent on the physical server while client configs will take precedent on the physical client only. In your case, configs are world save specific on physical servers since only one config is available for any one physical server. Physical clients will have one config for many worlds since its all hosted on one device.

Yes, a library/dependency file is read only. Editing a single instance of a file would not make any difference in other version of that file. If you wanted to do that, use reflection within your code. However, why would you need to edit the client side only for what block the player is hitting?

First, use a key binding. Second, using KeyInputEvent allows you to get the key action (pressed, held, released).

Within Effect and EffectInstance, there is an interface implementation that allows the user to set whether a potion effect should render the effect on screen or has a curative item. The issue with these methods is that they only have use for user added Effects and not vanilla Effects. The implementation on EffectInstance cannot even be extended or modified since ClientPlayNetHandler#handleEntityEffect creates a new instance of EffectInstance. Is there another way to hook these methods on vanilla effects? Any help is appreciated.

You probably would need to create a KeyBinding for your own configurable key and then use a packet to execute what you want to do on the server.