Jump to content
View in the app

A better way to browse. Learn more.

Forge Forums

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Featured Replies

Posted

So right I did hear about the rework for fluids but is it usable in its current state? And if so where could I begin in creating a custom fluid, everything I find seems to be a bit outdated.

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.

Edited by Ommina

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

Important Information

By using this site, you agree to our Terms of Use.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.