Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Alpvax

Members
  • Content Count

    240
  • Joined

  • Last visited

  • Days Won

    2

Alpvax last won the day on June 24 2020

Alpvax had the most liked content!

Community Reputation

39 Excellent

About Alpvax

  • Rank
    Creeper Killer

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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). I meant that you should just save the offset, as poopoodice suggested
  3. 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 SleepFinished
  4. Why? What are you trying to achieve? I'm fairly sure your mod is already a resource pack, the only thing is that you can't disable it in the GUI.
  5. It sounds like there is a difference between the NBT data of the different stacks. You should be able to use the vanilla /data command: https://minecraft.gamepedia.com/Commands/data to find any differences. It might be a bit of work trawling through the data (I would recommend only having the 2 stacks in an empty inventory).
  6. Please don't use a white font. Not all of us use a dark theme, and it looked like a blank post at first.
  7. Maybe post an image during the day so the armour can actually be seen? Also, we will need your rendering code to be able to debug it.
  8. 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
  9. You're missing part of the item name in 6 of the last 7 entries in your loot table
  10. You're trying to create a new instance, but not calling a constructor. Get rid of the "new" keyword.
  11. Is this now preferred to using ObjectHolder? Or has this approach superceded ObjectHolder?
  12. 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 updatePostPlacemen
  13. You've commented out the event listener (ModelBakeEvent) which actually instantiates your custom model (in BlocksMod.java).
  14. Check out TheGreyGhost's MBE04: Dynamic_block_models. It does almost exactly what you want (make sure you understand, not just copy-paste).
  15. 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 Privacy Policy.