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


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Cadiboo

  1. You event subscribe methods herehere and here are not static but you register you class here with the annotation and here with the register class method.


    You might want to read the documentation on events again.

    You also register your RegistryEvents to the FORGE event bus here but also register it to the MOD event bus with the annotation here.

    You should only register your class once AND the RegistryEvents class only handles events that fire on the MOD event bus so registering it to the FORGE event bus is pointless.


    Other stuff I’ve noticed:

    - You don’t need a proxy but still use one

    - Registry#registerAll exists and can be used to register many objects at the same time more cleanly

    - Your mod would be better suited using DeferredRegister

  2. On 1/31/2020 at 7:00 PM, Cadiboo said:

    I don’t recommend it.

    In 1.12.2 it was very easy with RenderGlobal’s event listeners. However it now requires a coremod to modify the logic OR I think that when your block updates you can invoke a block update (World#notifyBlockUpdate) on blocks in early chunks form inside your own block’s onBreak code or something to fix this. As I said though, this is a vanilla bug and I would recommend against trying to fix it as there is a decent chance that you will cause a stack over flow from recursively updated chunks if two neighbouring chunks both contain your light.


    That being said, if I was doing this I would make a coremod that hooked into the markRangeForRenderUpdate method and extend it (or also update blocks at the pos offset in each direction) by oldState#lightValue.


    It might also be good to see if this bug occurs when placing new lights & if not investigate why the behaviour is different.

  3. 23 hours ago, DragonITA said:

    Does the first parameter, the entity parameter, have to be or all three parameters?

    You should pass in null as the entity type as you’re going to override the getType method to return your one

    23 hours ago, DragonITA said:

    I still have not understood how to override the function.

    Just override “getType” like any other method. You can use an anonymous subclass if you want.


    The only issue that I’ve found with this is that the spawn egg textures don’t get generated for your egg. I’m looking into this.

    • Thanks 1
  4. 13 hours ago, DragonITA said:

    I noticed that the DeferredRegister is not yet stable enough with the registration of the entities.

    This is not at all true. There is a small (easily fixable on your end) issue with SpawnEggItems. Not Entities.

    • Like 1
  5. 16 hours ago, Drachenbauer said:

    Why i should not use a method from the renderer there?

    Many reasons including

    On 1/29/2020 at 6:14 PM, Cadiboo said:

    There is only one renderer instance. This instance renders all of your entities one by one. So you need to get the data from your entity in your Renderer and act according to that data

    and that entities are common (exist on both client and server) and rendering is client only. 


    16 hours ago, Drachenbauer said:

    I also have a subclass called RenderFactory in my renderers.

    But i don´t see it for sample at the pufferfish.

    do i still need it?

    No. You can use a lambda/method reference. This has been the case since whenever Java 8 came out, any tutorial that still uses a seperate RenderFactory class is extremely outdated.

  6. 16 hours ago, DragonITA said:

    I find the whole thing with the Deferred Registers too difficult.

    The whole point of them is that they are dead simple. The only issue with them is the spawn egg thing which is easily fixed right now (pass null into the constructor + anonymous subclass that overrides getType) and is likely to be made even easier in the future.

  7. 4 minutes ago, diesieben07 said:

    Yeah, this is actually pretty easy to do by extending SpawnEggItem. Pass null to the constuctor and overide getType to use a supplier instead of the typeIn field.

    Any reason why Forge doesn’t patch in another constructor the way it does for fluids (or maybe it’s buckets?)

  8. 7 minutes ago, diesieben07 said:

    You either have to write your own spawn egg code which uses suppliers or use the traditional registry events.

    Either write your own better code or use the same hack that’s been used for ages of creating your entity type in the item event that is incompatible with dynamically reloading registries. I would definitely go with the former.

  9. 17 hours ago, Villfuk02 said:

    Great tutorial, however, I have a couple of questions:
    What is the specPair thing about?

    It just lets the method return both the spec and your configured instance. You need the spec for registration & baking checks later and you need the instance for getting/setting values.

    17 hours ago, Villfuk02 said:

    Is there any difference between CLIENT and SERVER configs in terms of setup?

    If by “setup” you mean “registration”, no. Server config is synced to the client so it needs to be registered on both sides. It is good practice to only register your client config on the client distribution but unless you interact with client-only code in your config (which is unlikely) it’s not necessary.

  10. 20 hours ago, Drachenbauer said:

    i want him to stay in place without movement,as long as he is inflated.

    I hadn’t considered that. Still you’ll probably want to change just the movement stuff rather than circumventing the entire tick method.


    20 hours ago, Drachenbauer said:

    How do i get the data, wich entity calls the method?

    The entity that is currently being rendered is passed into your renderer as one of the parameters.

    20 hours ago, Drachenbauer said:

    How do i call the method the non static way?

    Don’t call anything on your renderer from your entity.

  • Create New...

Important Information

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