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

IceMetalPunk

Members
  • Content Count

    398
  • Joined

  • Last visited

Community Reputation

22 Excellent

About IceMetalPunk

  • Rank
    Diamond Finder

Converted

  • Gender
    Male
  • Location
    Earth...I think.
  • Personal Text
    New to Java and modding, old to programming.

Recent Profile Visitors

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

  1. I suppose I could have the validate() method return either a triple or an optional pair to indicate isValid, tier, and range, rather than storing it in the block class's fields. That's definitely something I'll look into, thanks for the suggestion! I didn't realize the BabyEntitySpawnEvent fired before the baby was moved to the correct position, but looking at the breeding method now with that in mind, I see it. After adding a moveTo for the clones in the event handler, everything is working perfectly now! Thank you for all your help with everything! ❤️
  2. this.isValid and this.tier are (re)set in the validate() method, which is called right before they're used, so they're both definitely re-evaluated immediately before use. getRangeBB is only being used by operate() method overrides, which is called also in the code immediately following a (re)set in validate(). None of those variables are ever being used without first being re-evaluated getRenderLayer is only meant to indicate when a block doesn't use the default layer so it can be set accordingly. Is RenderType.SOLID the default? If so, I can make that the default return value instead.
  3. I fully understand how blocks work. This mod started as an exercise in making functional blocks without adding tile entities. It may look like the block is storing mutable state, but it's not *really* doing that; any variables that seem like they could differ between blocks in the world are only ever used by the same piece of code that sets them, and they're always reset/re-evaluated at the beginning of any such code. I understand that internally, this means the same instance is overwriting its values for every block that evaluates them, but as that was the motivation for making this mod, I'm
  4. Thank you! That will be very useful! I've updated the reflection name to the SRG name and that part seems to still be working. OK, I've just pushed up a repo: https://github.com/IceMetalPunk/psychic-altars When testing, you'll need to create a "telepathic altar" to trigger the breeding code; which is a multiblock listed in the Patchouli handbook already. It's a Telepathic Altar block on top of any inventory, with the inventory surrounded by 8 omen-matched blocks (that is, omenstone or one of the upgrade omen types). At least one of the cardinal direction omens should be an Efficie
  5. Yeah, I'm aware the error handling is terrible; this code is very much the prototyping, "just trying to make it work first, then I'll go back and clean it up later" kind of code. I made all of the changes you mentioned, except using the SRG name; how would I find that? I used to use MCPBot, but it seems that hasn't updated past 1.15 and loveCause isn't in those mappings. I checked in the .gradle folder and eventually found joined.tsrg, but that doesn't contain the deobfuscated names, so I'm not sure how to locate this particular field's SRG name in it. More importantly, I switched ov
  6. Taking your advice, I refactored it all. I made a FakePlayerHelper class that keeps track of all the fake players, constructing the UUIDs based on the name rather than being random, reusing GameProfiles for the same names when constructing different FakePlayers for different worlds, etc. Then I used reflection in the event handler to pull the UUID from the private field in AnimalEntity directly and look that up via the helper's maps. That solved the NPEs... but now, when a baby sheep is born and triggers the BabyEntitySpawnEvent handler code, the whole game slowly locks up. As in, all entities
  7. I hate having to ask so many questions here in such a short time, but I tried to figure this one out on my own and hit a wall. I have a FakePlayer that I create in the FMLServerStartingEvent, and I have a block that breeds animals using the FakePlayer as their "love cause" via AnimalEntity#setInLove. This is all working, and the animals are breeding fine. However, when a baby is born, I'm hooking into the BabyEntitySpawnEvent and trying to check whether either of the parents was bred by this FakePlayer, and if so, do some stuff (specifically, spawn a clone of the baby). This wasn't w
  8. 🤦‍♂️ It would be a misunderstanding like that... Thank you, it works perfectly now! You're becoming quite invaluable to my return to modding, and I fully appreciate all your help!
  9. In 1.12, it was easy to have things occur on a block at regular intervals without a block entity: just schedule a block tick, override the block's tick method, and everything worked. I'm trying that now in 1.16.5 and getting nowhere. I have this in my block's class: @Override public void setPlacedBy(World world, BlockPos pos, BlockState state, @Nullable LivingEntity player, ItemStack stack) { super.setPlacedBy(world, pos, state, player, stack); System.out.println("Placed block!"); world.getChunk(pos).getBlockTicks().scheduleTick(pos, this, 1); if (world.getChunk(pos).getB
  10. Ah! Using reflection to prevent crashing is the trick I needed to know! Thank you, I'll work on implementing it when I get a chance; hopefully it should go smoothly, if not, I'll ask more here with more details. EDIT Worked perfectly the first try 😁 Thank you for your help!
  11. I haven't made a working mod since 1.12, but I'm starting a new one for 1.16.5 and I'd like it to support the Curios API. I've gotten that working, but I realized that in order to register a Curios slot, I need to reference the Curios API SlotTypeMessage class. I was hoping I could make Curios support optional, i.e. register the slot if the Curios mod is installed, or just gracefully ignore it if not, but if I'm referencing SlotTypeMessage and someone installs my mod without including Curios, won't that just crash? Is there something special I need to do to make the support optional? Or am I t
  12. Client/server sync will be the death of me. I have a block with a tile entity, and a tile entity renderer bound to it. This tile entity has a single item stack as a pseudo-inventory and a fillLevel property. The renderer is supposed to render the item stack (if it's not empty) and then render another block inside this block with a state determined by the fillLevel. At one point, it was mostly working, except that after putting an item in, when the tick method would finish processing it and clear the item (set its item stack to an empty one), it would continue rendering the item. In my attempts
  13. Well, after hours of scratching my head and debugging, I figured it out. I was creating the tile entity type manually rather than using the builder, and apparently that caused all kinds of problems with how the generic parameters were being interpreted. I switched to using the builder and now everything works. Whoo!
  14. I'm trying to bind a simple TER to a tile entity of mine. Just as a test/learning exercise, I've created a blank TER that has an empty render method, and I'm trying to bind it to an existing tile entity in my mod. But Eclipse is complaining that the renderer type isn't correct. I have a tile entity called RedstoneVaporizerTileEntity, which extends the base TileEntity class. Then I have this TER (ignore the naming, as I said it's just a test): public class CompressorTileEntityRenderer extends TileEntityRenderer<RedstoneVaporizerTileEntity> { public CompressorTileE
  15. Yes! That was the missing piece, thank you so much! I could have sworn that method was related to movement, not rendering, probably because the field it clears is also cleared in the doesNotBlockMovement method... I guess it's just by default that things which don't block movement aren't considered to be solid renders, either. Anyway, thanks again, I'm glad this is finally solved
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.