Leaderboard

They are crowdsourced names, nothing to do with us. https://github.com/ModCoderPack/MCPBot-Issues

The event is only thrown when you are in third person or when a other player looks at you. Is that the problem. I hope because it all looks fine!

All you need to get rid of the portal is to override placeEntity and return an application of repositionEntity with the parameter being false.

How do you register your message? nvm you sent a packet here but with empty value (no value passed into the constructor

in encode() you can write your variables got from the message into the buffer. in decode() you had already returned a new instance of the message, you can pass the variable read from the buffer to the new instance of the message through the constructor. in handle() you should be able to access the field from the message. Just from my experience, might be some mistakes, please point them out if find any.

A friend of mine said "In 1.12 it was done alot differently. It has to do with forge not having as much features now because of the updates to 1.13 and 1.14 they had to remake it from the ground up It's impssible to do it in 1.14 because it's hardcoded into the game. We would have to remake the fluids from the ground up in the mod" But maybe you guys know more?

Just a thought (I haven't done any packet sending myself yet), you're sending the packet in the server start event, but are there even any clients connected at that point? Who is it sending the packet to? I'd check into that first!

Well, you can start with this New Fluid Test class, and stumble on from there. Taking a peek at the vanilla Water implementation would not lead you too far astray either. At first glance, it looks pretty straightforward. It's the second and third glances that make the room start to swim, followed by the need for a little lie down. As such, take the following as the confused mumblings of a man who has spent too many hours bumbling in the dark, trying to get it to work. The Forge dynamic bucket seems to be gone. Instead, you create your own bucket item via new BucketItem. As a plus, you can provide your own empty container and stack size, so creating some alternate fluid container, say, a squirt-gun, is pretty easy. Blocks have Block.Properties. Items have Item.Properties. Fluids have Attributes. Attributes hold all the mod goodness for the Fluid. Temperature, Colour, etc, go here. The fluid needs a block. It is created via new FlowingFluidBlock, and has a blockstate and model like any other block. Seems to have 'level' as a variant, so one could probably point to different models based on the fluid level, should one want to. I have not tried. The fluid itself is registered in its own registry. It looks like there are two distinct fluid objects created per custom fluid. A "source" version (what you would see if you place the fluid in the ground, surrounded by eight blocks to ensure it doesn't try to wander off), and a "flowing" version (what you would see if you broke one of those eight blocks and let the fluid spread). Naming may or may not be important. But then it gets a bit unpleasant. Fluids are registered after blocks, but the FlowingFluidBlock needs a Fluid object. The BucketItem also requires the Fluid. The custom fluid class ( MyFlowingFluid, in the example above, extending from vanilla's FlowingFluid ) in turn contains references to the bucket, the attributes, the block, and, indeed, to itself. The Test class creates the Fluids from the Block registry event, which is the kind of thing that makes people itch. I'm hoping there is a better solution. -- And that's the summary of my understanding. It may contain errors. If those that know better which to correct my egregious missteps, they are invited and encouraged to do so. -- Edit One: I'm seeing code to the effect of ModelDynBucket, so there may be dynamic buckets after all.

Please read the EAQ and post log.