Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Alpvax

  1. 7 minutes ago, zlappedx3 said:

    Should I make StatusProvider an instance?

    What? You use StatusProvider exactly the same way you did before (attaching it in the AttachCapabilitiesEvent). The only thing you change is in your StatusProvider, you move the old code from your CapabilityRegistry.register(cap_class, storage, default_factory) and put the code from the storage class inside your StatusProvider save/load methods, and the code from your default_factory inside your LazyOptional.

    Literally just getting rid of the stuff that no longer exists and calling it directly, instead of through the capability.

  2. You don't create an instance of the `Capability` class, that is still handled behind the scenes (and the `@CapabilityInject` annotation still works as before).

    Where you called `Capability#getDefaultInstance()` before, just create your new instance (of your Capability type, i.e. `new Status()`).

    Where you called your Storage class methods (from your Capability Provider), just move your saving/loading stuff directly into those methods of your `StatusProvider`.

  3. I'm assuming that it is just a vanilla book with custom NBT, not your own custom item?

    If that is the case you could listen to the use item event (sorry, I can't remember the name of it off the top of my head), check for the book being used (opened) and sync the data with the item.

  4. On 9/17/2021 at 11:41 PM, FireTamer81 said:

    While chugging along making the JSONs by hand (to get an idea of how they need to be generated for each type of block), I cam up with a possibly brilliant idea.

    Could I somehow make template JSONs and when a new block of a certain type is being generated it will just pull the template and replace certain keywords like "NAME" and "COLOR" instead of all of this getVariantBuilder stuff

    Make a method which has the parameters that change (name, colour etc.) and perform the datagen logic inside that method. You can even have a method which generates each of the blocks (regular cube, wall, stairs etc.) for a single name.

    Unfortunately I don't have a good example of datagen as the mod I am working on using it for uses either simple cubes or a custom model loader. When I was learning how to use the datagen I spent a lot of time looking through the source and IIRC Tropicraft was my starting point, although I cannot remember what that was like. 

  5. The book is still rendered in a BlockEntityRenderer, not a json model. That means that the only thing you can change is the texture, which you can find in the minecraft.jar file at the path "assets/minecraft/textures/entity/enchanting_table_book.png" (use any program that handles .zip files to open the jar and extract the texture).

  6. You could look into how commands handle finding and filtering entities, and either use the same method, or call the required methods.

    The class which handles it is net.minecraft.command.arguments.EntitySelector

  7. On 7/16/2021 at 3:00 PM, Anrza said:


    Thanks for your answers!

    For the record, I'm not listening for any sleep events. Since AFAIK it's not fired if time is set by a command, I'm using a more general approach.


    Thanks for your reply! I am indeed looking to use an offset variable. It's a good point that I shouldn't have to store any other time variable, and I'll look into that.

    The `dayTime` value is set by the command, so you could listen for the command event, check the daytime before, subtract it from the daytime after (wait 1 tick to get the "after" time) and add that difference to your offset if you wanted. It depends how accurate you want to be.

    Alternatively, when your offset changes, you could check the difference between `gameTime` and `dayTime` (you would then have to track a second offset to check when it changes, but it might give you a bit more accuracy).


    On 7/15/2021 at 3:26 PM, Alpvax said:

    offset between gametime and your gametime + sleeptime

    I meant that you should just save the offset, as poopoodice suggested

  8. 1,2: It depends exactly what you are after. I would recommend using WorldTickEvent, and saving the time in a capability attached to the world. If you want to track each dimension independently, use the specific world#getGameTime, otherwise just use the overworld (using specific worlds the time will only increment when the world is loaded).

    1&2: I would suggest listening to ServerTickEvent (with Phase END), and keeping the data attached to a capability attached to the Overworld. you can get the time using overworld#getGameTime. To keep track of time sleeping, subscribe to SleepFinishedTimeEvent (at EventPriority.LOWEST to run after all other listeners) and add the time difference.

    3: packets, it depends what you need on the client. If it is just for rendering in a GUI, you could use a containerscreen to sync it, otherwise I believe you will need packets (sent whenever the offset between gametime and your gametime + sleeptime changes.

    4: Yes, but the sleep event is only fired on the server, so you will have to manually sync your offset.

    5: Yes, all worlds other than the Overworld use a DerivedWorldInfo, which just passes both times through from the overworld info. (I didn't realise this until I just looked).

  9. On 2/11/2021 at 1:30 PM, BerryHeyy said:

    So I'm using ColorHandlerEvent right now to color my items, but I'm not getting the desired effect. Is there any way of shifting a texture's hue instead of just applying a flat color to it?

    Please don't use a white font. Not all of us use a dark theme, and it looked like a blank post at first.

  10. I would rather not use "decorative_blocks" because that doesn't really say what they are, and people may start adding other "decorative" blocks into the tag.

    Maybe "small_storage_blocks" or "storage_blocks_2x2" or something similar would be better.

    As for the actual blocks, there are more than just quartz and copper which would fall into the 2x2 tag:

    • Glowstone
    • Clay
    • Snow
    • Honeycomb
    • Honey (reversible, but requires 4 glass bottles)
    • Magma Cream
    • Quartz
    • Copper (reversible, but I think only if the block isn't weathered?)
    • Amethyst
    • Sandstone (possibly? It's a bit different being block -> block, but follows the same irreversible principle).
    • Prismarine (has both a 3x3 "prismarine_bricks" and a 2x2 "prismarine" recipe. Both are irreversible).
    • Purpur (probably not, the recipe produces 4 blocks, so more of a conversion like the various stone types).
    • Like 1
  11. There are 3 methods which sound like they do something very similar, overridden by various different blocks:


    • updatePostPlacement is used to make connections with adjacent blocks (fences/walls).
    * Update the provided state given the provided neighbor facing and neighbor state, returning a new state.
    * For example, fences make their connections to the passed in state if possible, and wet concrete powder immediately
    * returns its solidified counterpart.
    * Note that this method should ideally consider only the specific face passed in.
    public BlockState updatePostPlacement(BlockState stateIn, Direction facing, BlockState facingState, IWorld worldIn, BlockPos currentPos, BlockPos facingPos)
    • neighborChanged appears to be used for detecting redstone changes (or water in the case of sponge)
    // No Javadoc
    public void neighborChanged(BlockState state, World worldIn, BlockPos pos, Block blockIn, BlockPos fromPos, boolean isMoving)
    • And the forge-added onNeighborChange is called from World#updateComparatorOutputLevel:
    * Called when a tile entity on a side of this block changes is created or is destroyed.
    * @param world The world
    * @param pos Block position in world
    * @param neighbor Block position of neighbor
    default void onNeighborChange(BlockState state, IWorldReader world, BlockPos pos, BlockPos neighbor)

    My question is which method should be overridden for what purpose, as many of the call paths are similar. I have spent quite a bit of time trying to trace the call paths and have become lost multiple times.

    I was using neighborChanged, but switched to using updatePostPlacement (as that already supplies the direction, and sounds more like what I needed (making connections between blocks)). The effect in-game did not change, so I am wondering when I should be using each of these methods.


    There is also the following forge-added method, which doesn't appear to be overridden anywhere, and is only called by the blockstate method of the same name, which is itself not called:

    * Called on an Observer block whenever an update for an Observer is received.
    * @param observerState The Observer block's state.
    * @param world The current world.
    * @param observerPos The Observer block's position.
    * @param changedBlock The updated block.
    * @param changedBlockPos The updated block's position.
    default void observedNeighborChange(BlockState observerState, World world, BlockPos observerPos, Block changedBlock, BlockPos changedBlockPos)


  12. That is the only way. All blockstates are calculated on registration, so there is no way to save that to a single blockstate.

    If there are that many, you may need to rethink your approach.

    You could maybe store a chunk capability with a map of blockpos -> blockstate, but I'm not sure that would save you much (after all, that is what the world saves). And you'd have a much harder time sorting out the rendering.

  • Create New...

Important Information

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