Jump to content

Recommended Posts

Posted (edited)

I am currently working on a redstone block that implements logic gates in your world. For the block updates I currently use "neightbourChanged(IBlockState, World, BlockPos, Block, BlockPos)" method. But, because I have gates that, when self powered, should form a clock, throw a StackOverflow (doesn't crash the game though). So, I've tried to use the "updateTick(World, BlockPos, IBlockState, Random)" method. By debugging I found out that the method only gets called when the blocks should be activated, but never when they should be deactivated, wich is a problem. I tried to figure out why the method doesn't get called on deactivation, but the stacktrace didn't give me any clue. When looking at the example I used, the redstone comparator, "updateTick(...)" allways gets called, no matter if turned on or off.

Here's the method:

 

@Override
public void neighborChanged(IBlockState state, World worldIn, BlockPos pos, Block blockIn, BlockPos fromPos)
{
    boolean flag = this.shouldBePowered(worldIn, pos, state); //Is only important fo calculating whether the gate should give an output. 
                                                              //This is the only time the method gets called

    if(flag && !state.getValue(ACTIVE))
    {
        worldIn.setBlockState(pos, getPoweredState(state));
        worldIn.notifyNeighborsOfStateChange(pos, this, false);
    }
    else if(!flag && state.getValue(ACTIVE))
    {
        worldIn.setBlockState(pos, getUnpoweredState(state));
        worldIn.notifyNeighborsOfStateChange(pos, this, false);
    }
}

Disclaimer: I still use "neighbourChanged(...)", I only swaped out the method names and parameters. That's what I did originaly as well.

Forge version: 1.12.2-14.23.4.2705

Every gate is only one block, with the blockstate "ACTIVE" and "FACING", indicating whether the gate is active and which direction the block faces respectively.

 

If you need anything else, feel free to ask :)

Edited by Keheck
  • 2 weeks later...
Posted (edited)
On 2/9/2019 at 6:15 AM, Laike_Endaril said:

If you can link to a repo or post the full code of your class it will be easier to debug.

 

Also, if you're getting an error with a stacktrace, post that as well.

I uploaded my project to GitHub https://github.com/Keheck/Logicblox

I want every "neighbourChanged" method to be "updateTick"

Edited by Keheck
Posted

I just downloaded the source from your repo, but it's missing some critical components (which are part of the standard forge MDK setup), such as...
...all gradle-related files (root folder)

...all git-related files (root folder)

...the mcmod.info file (resources folder)

 

There should have been a .gitignore file included in the forge MDK which correctly handles your repo file filter, and should have included all these things in your repo

Posted
13 hours ago, Laike_Endaril said:

I just downloaded the source from your repo, but it's missing some critical components (which are part of the standard forge MDK setup), such as...
...all gradle-related files (root folder)

...all git-related files (root folder)

...the mcmod.info file (resources folder)

 

There should have been a .gitignore file included in the forge MDK which correctly handles your repo file filter, and should have included all these things in your repo

I uploaded the whole project in one folder. Btw, I deleted the "mcmod.info" file. The mod information is created during pre-init

Posted (edited)

Thanks for adding in the build file; it makes importing the project much easier.

After looking through your BlockClock and many related classes, I believe adding a TileEntity is the best approach for a clock.  You can probably make a clock without using a TE, but it might be tricky to preserve the internal timer state when the world unloads/reloads.  I suppose you might be able to get away with using a blockstate property as a timer, but I haven't tried this.

 

Consider taking a look at the BlockDaylightDetector class.  It may not be a clock in the way you're thinking, but some of its code could probably be useful here.  It uses a TileEntity as well.

 

That's about as far as my guesswork is going on this one.  If you still have trouble you'll need advice from someone with more related experience than I have.

Edited by Laike_Endaril

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

×
×
  • Create New...

Important Information

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