HappyKiller1O1

He's probably a very "bold" person.

Hm, I will be using the tick handler, but would there be any way of disabling the key input for a time? I feel like if you could, it might save some processing power from constantly setting the state of the key. I may be wrong though, so thanks.

Your constructor is "protected", which means it can only be accessed by a class extending that one. Change it to public, and you should be good to go.

You need to check if the connection is local when running a singleplayer world. To do this, do something like this: @SubscribeEvent public void onJoin(ClientConnectedToServerEvent event) { if(event.isLocal) { System.out.println("Local Connection"); }else { System.out.println("Server Connection"); } } As you can see, I check if the client is on a local server, and print in the console accordingly. When you do not check if it is local, you need to run a server within forge, and join it from the client. When you do, it will print out whatever you'd like in the server console.

Gotcha. Although, couldn't I just disable the key once, and re-enable it when the player is not over-encumbered? Or does it need to be disabled every tick?

Hm, I might honestly just keep the FOV change as it is not too much of a bother. And, should I do that in my LivingUpdateEvent, or in a client side tick handler?

You have to talk to the server to send something back to the player.

Well, for starters, you would have to retrieve the player that sent the text "Bot, hi". Then, send a message to that player.

Hm, I decided, considering I will not be changing how slow you are when you're overencumbered; I would just use the double that is set for the speed after the modifier. Here is what I have: @SubscribeEvent public void onFOVChanged(FOVUpdateEvent event) { if(event.entity != null) { EntityPlayer player = event.entity; ExtendedPlayer props = ExtendedPlayer.get(player); if(props.isOverEncumbered() && player.getActivePotionEffects().isEmpty()) { IAttributeInstance iai = player.getEntityAttribute(SharedMonsterAttributes.movementSpeed); double speed = iai.getAttributeValue(); //System.out.println("Speed: " + speed); //System.out.println("Compared Speed: " + 0.06000000089406967); if(speed == 0.06000000089406967) { System.out.println("SPEED IS KEY"); event.newfov = 1.0F; } } } } Although, this does help A LOT with my code and such. This does not help me stop the player from sprinting entirely.

Hm, so I figured that if I check my ExtendedPlayer for the method "isOverEncumbered", I can basically tell the event when I am changing the speed. Should I just make the new FOV, the FOV setting the player may have set? (Just in case they changed their default FOV)

So, I should get the player's current speed, and subtract my modified speed from it to reset the FOV?

I got that to work pretty flawlessly. But, I hate how the FOV changes when I lower the speed. I know there is an FOVUpdateEvent, but how will it know when not to change the FOV?

Thanks for the help. Will help me a lot throughout my current mod creation.

Ah yes, I read through some older threads while waiting for your reply. So, you can simply use any randomly generated UUID to store your AttributeModifier?

I'll get to that, but what is so different between setting the player walk speed in PlayerCapabilities, and setting it in AttributeModifier?

Alright so, I'm curious on how exactly someone puts their stuff in another person's DataWatcher?

Alright, so I need to stop the player from accessing the sprint option while certain things are true. I can modify the players walk speed quite fine. But, when attempting to stop the player from sprinting, it works for double tapping the forward key, and pressing the sprint key. But, holding the sprint key down allows them to sprint. Any way to prevent this? Here's where I do the changing of movement speed: @SubscribeEvent public void onLivingUpdate(LivingUpdateEvent event) { if(event.entity instanceof EntityPlayer) { EntityPlayer player = (EntityPlayer)event.entity; ExtendedPlayer props = ExtendedPlayer.get(player); if(props.get(player) != null) { if(props.isOverEncumbered()) { System.out.println("Player is Overencumbered! Changing walk speed..."); player.capabilities.setPlayerWalkSpeed(0.05F); player.setSprinting(false); }else { if(player.capabilities.getWalkSpeed() != 0.1F) { player.capabilities.setPlayerWalkSpeed(0.1F); } } } } }

I'm pretty sure they would only conflict if two separate entities from two different mods are trying to send an update at the same time on the same ID. Although, diesieben07 would know more on that. I prefer using a manual packet system to avoid any conflicts.

Yes, I went through some Java docs online to figure it out after hearing I should use it. Basically, if we have an interface called "IVehicle", and our class "Car" implements it, if a method requires a class from IVehicle as a param, you can give it the Car class and it works, correct?

DataWatcher is just Minecraft's easy way of updating the client. The reason it has such a limited number of IDs (31) is because, I believe all the data gets sent in one byte to update everything. Anyway, the way to do this manually, and honestly be way safer in the sense of compatibility with other mods, is packets. In 1.8, packet handling is done using SimpleImpl. When you need to update the client, you just send a packet to the player with the info to update. It's that easy.

Packets are your best friend. When the tab is clicked, it will be run on client side only. So, in order to inform the server the the container update needs to run, you'll need to send a packet containing what the new selected tab number is. So, you click the tab, update the gui, send the packet, update the container.

Oh, yes he could! My mistake, I haven't worked much with the vanilla stat code.

My God, all this time and effort to realize I was registering all three items with the ItemSmallBackpack class. Thank you for showing me an easier way of modifying weight limits, sorry for my idiocy!

Also, remember that Minecraft#getMinecraft() IS CLIENT SIDE ONLY. So, you can never use it in the container class, because that class only runs on the server side.

No, it is a waste to make multiple GuiContainers for each tab. If the bottom part (the player inventory) never changes throughout the tab changes, there is only a need to update the part of the container that changes when a certain tab is selected. Let's say you have three tabs, tab0, tab1, and tab2. In your container, tell the game "if tab0 is selected, add these slots to the inventory, if tab1 is selected, add these instead" etc. Only ever change what you need to change. So, again, if the player inventory slots never change when switching tabs, you don't have to update any slot positions for the player inventory.