[1.19.2] preInit & postInit

[Kosh]

Hello. I'm trying to update my mod from from 1.12.2 to 1.19.2.

Could someone please explain how can I do the same things as "preInit(FMLPreInitializationEvent event)" and "postInit(FMLPostInitializationEvent event)" methods did in 1.12.2

1) I need something like preInit, or any other way to load mod configs before any Items/Blocks/Entities initialization.

As for example I need to set custom value for entity attribute. When I tried to use it from configuration file I got

IllegalStateException: Cannot get config value before config is loaded.

Here is a link on my mod class https://github.com/NightKosh/Sophisticated-wolves/blob/1.19.2/src/main/java/sophisticated_wolves/SophisticatedWolvesMod.java

2) I need something like postInit to update some data which my mod's API should provide

[warjort]

https://forge.gemwire.uk/wiki/Stages_of_Modloading

You can't use configurations at registration time. You couldn't really do it in previous versions either.

If you tried, it would just give the default value not the value in the config file.

Now it gives an error so you know you are doing it incorrectly.

 

The usual pattern is to pass a java.util.Supplier of the configuration to your registered objects instead of the value directly.

Then the object does supplier.get() when it needs the value at runtime.

This also means the data updates dynamically, e.g. if the config changes when it comes from the server you are logged into.

e.g. new MyObject(myConfig::getValue) short for new MyObject(() -> myConfig.getValue()) instead of new MyObject(myConfig.getValue())

Or you can just have the objects reference the config directly when they actually need it.

 

There are many questions about different use cases in this forum.

Although a lot are about the "anti-pattern" of injecting config file data into datapack data.

 

 

Edited November 2, 2022 by warjort

[Kosh]

1 hour ago, warjort said:

You couldn't really do it in previous versions either.

In 1.12.2 I did it in different events FMLPreInitializationEvent, FMLInitializationEvent and FMLPostInitializationEvent. Also some of configs were used after initialization, but now it looks like it can't be used in such way.

Here is a description of the problem, I mentioned in the previouse post:

I have an entity with configurable Maximum health amount.

This is a method which provides AttributeSupplier (commented line crashed)

    public static AttributeSupplier createAttributeSupplier() {
        return Mob.createMobAttributes()
                .add(Attributes.MOVEMENT_SPEED, 0.4)
                //TODO IllegalStateException: Cannot get config value before config is loaded.
                //.add(Attributes.MAX_HEALTH, SWConfiguration.wolvesHealthWild.get())
                .add(Attributes.ATTACK_DAMAGE, 2)
                .build();
    }

This is an event with attribute supplier registration:

    @SubscribeEvent
    public static void registerEntityAttributes(EntityAttributeCreationEvent event) {
        event.put(getSophisticatedWolfType(), SophisticatedWolf.createAttributeSupplier());
    }

 

Also another one case is Villagers registration

Is it possible to use configs to disable it registration, like in 1.12.2? Or may be it can be done in other way?

 

In case you'll need to look at sources:

Mod: https://github.com/NightKosh/Sophisticated-wolves/tree/feature/1.19.2_update

Entity: https://github.com/NightKosh/Sophisticated-wolves/blob/feature/1.19.2_update/src/main/java/sophisticated_wolves/entity/SophisticatedWolf.java

Entity registration: https://github.com/NightKosh/Sophisticated-wolves/blob/feature/1.19.2_update/src/main/java/sophisticated_wolves/core/SWEntities.java

 

 

[warjort]

I can confirm the EntityAttributeCreationEvent is fired during registration before the configs are loaded.

But you don't have to code it that way. You can set a default max health in that code.

Then in your entity constructor you can apply a permanent attribute modifier from your configuration.

 

I am the wrong person to talk about this stuff. I generally avoid config files like the plague.

They are just a way for users to break things. 🙂  And only multiply the amount of testing you have to do with different combinations of config options.

Edited November 2, 2022 by warjort