Jump to content

Recommended Posts

Posted (edited)

I currently have a working multiblock with a mixture of ticking and non-ticking TEs.

The main block (heart/master) is a ticking TE with a public method interruptStructure which basically tells it to do a scan of the multiblock.

All the other blocks are non-ticking TEs which when block.onBlockAdded is called, find the nearest reachable heart and call master.interruptStructure. They do something similar for when the block/te is invalidated.

So I've got a way to say hello-block.onBlockAdded and goodbye-te.invalidate

 

This seems to work nicely until someone builds the multiblock over a chunk boundary :(

 

The problems occurs when the player moves away from the multiblock and returns.

When the first chunk loads and it contains the heart, then the heart does an initial scan and fails since some of the multiblock is in the unloaded chunk.

The player moves further forward, the next chunk loads and then the rest of the multiblock is loaded, but cannot say hello because there is no block.onBlockAdded for a chunk load.

 

My solution - which I don't like - is to make them all tickable, then on the first tick of the non-heart blocks, find the master and poke it. All subsequent ticks for that TE are then no-ops.

But of course I've just registered possibly 60 new ticking TEs per multiblock - which doesn't seem right.

 

So does anyone have any suggestions of a way to fix this that doesn't involve making them all ITickable?

 

Possible alternative: Keep track of which chunks have heart TEs and then when a neighbouring chunk loads, use that list to force the heart to rescan.

 

Thanks

Ipsis

Edited by Ipsissimus418
Change title to solved
Posted

So TileEntity::validate did the trick.

 

First try it got called on both the server and the client - which created a very impressive stack overflow.

Limiting that to the server - which is where I needed to do it - allowed me to walk to the master.

 

One initial concern was the algorithm I use to walk to the master was travelling over other TEs in the same chunk which had not yet had their validate methods called yet. However as I only use their position to determine the path and never try to access them, I don't think that is an issue.

 

I'm now horribly embarrassed for investigating every other method in block and TE and completely overlooking the "validate" one.

 

Thanks diesieben07

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...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • @Tsuk1 Also, new note, you can use blockbench to make the custom item model for when it is not on the head.   EDIT: Funny story, I am making a mod similar to yours! Mine is called NorseMC.
    • @Nood_dev Could you send a screenshot of your weapon code? Here is the one I made (for a dagger): The specific UUID does not matter, just that it is the same every time, which is why UUID#randomUUID does not work public class DaggerItem extends TieredItem implements Vanishable { protected static final double REACH_MODIFIER = -1.5D; protected final Multimap<Attribute, AttributeModifier> defaultModifiers; protected final UUID BASE_ATTACK_REACH_UUID = UUID.fromString("6fe75b5c-9d1b-4e83-9eea-a1d5a94e8dd5") public DaggerItem(Tier pTier, int pAttackDamageModifier, float pAttackSpeedModifier, Properties pProperties) { super(pTier, pAttackDamageModifier, pAttackSpeedModifier, pProperties); this.attackDamage = (float) pAttackDamageModifier + pTier.getAttackDamageBonus(); ImmutableMultimap.Builder<Attribute, AttributeModifier> builder = ImmutableMultimap.builder(); builder.put(Attributes.ATTACK_DAMAGE, new AttributeModifier(BASE_ATTACK_DAMAGE_UUID, "Weapon modifier", this.attackDamage, AttributeModifier.Operation.ADDITION)); builder.put(Attributes.ATTACK_SPEED, new AttributeModifier(BASE_ATTACK_SPEED_UUID, "Weapon modifier", pAttackSpeedModifier, AttributeModifier.Operation.ADDITION)); // THE ONE YOU WANT: builder.put(ForgeMod.ENTITY_REACH.get(), new AttributeModifier(BASE_ATTACK_REACH_UUID, "Weapon modifier", REACH_MODIFIER, AttributeModifier.Operation.ADDITION)); this.defaultModifiers = builder.build(); } @Override public Multimap<Attribute, AttributeModifier> getDefaultAttributeModifiers(EquipmentSlot pEquipmentSlot) { return pEquipmentSlot == EquipmentSlot.MAINHAND ? this.defaultModifiers : super.getDefaultAttributeModifiers(pEquipmentSlot); } }
    • https://images.app.goo.gl/1PxFKdxByTgkxvSu6
    • That's what we'll try out. I could never figure out how to recreate the crash, so I'll just have to wait and see.
    • Ok, I updated to the latest version and now the models are visible, the problem now is that the glowing eyes are not rendered nor any texture I render there when using shaders, even using the default Minecraft eyes RenderType, I use entityTranslucent and entityCutout, but it still won't render. Something I noticed when using shaders is that a texture, instead of appearing at the world position, would appear somewhere on the screen, following a curved path, it was strange, I haven't been able to reproduce it again. I thought it could be that since I render the texture in the AFTER ENTITIES stage which is posted after the batches used for entity rendering are finished, maybe that was the reason why the render types were not being drawn correctly, so I tried injecting code before finishing the batches but it still didn't work, plus the model was invisible when using shaders, there was a bug where if I look at the model from above it is visible but if I look at it from below it is invisible. So in summary, models are now visible but glowing eyes and textures are not rendered, that hasn't changed.
  • Topics

  • Who's Online (See full list)

    • There are no registered users currently online
×
×
  • Create New...

Important Information

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