-
Notifications
You must be signed in to change notification settings - Fork 1
v2.0 migrations and changes
Added Functions | Removed Functions | The Configuration System
The migration needed to use this new version is to start using the new version of forge (as of the time of writing is still in beta). I will not explain the new way of creating mods for forge since this is not a tutorial but a migration guide. The new @Mod annotation takes a mod id only so no more setting the language provider in that space. You will now have to set the modLoader property in the mods.toml file to boxlin and set the loaderVersion to 1 or higher ([1,)).
modLoader="boxlin"
loaderVersion="[1,)"In this new way of loading mods I have been able to make it possible to load a mod from a function with the io.opencubes.boxlin.adapter.FunctionalMod. It works like the normal @Mod annotation but only with functions.
@Mod("modid")
object MyMod {
val logger = LogManager.getLogger()
init {
KotlinModContext.get().on<FMLCommonSetupEvent> {
logger.info("Hello, Forge!")
}
}
}val logger = LogManager.getLogger()
@FunctionalMod("modid")
fun mymod() {
KotlinModContext.get().on<FMLCommonSetupEvent> {
logger.info("Hello, Forge!")
}
}This is a property that gets the translation value for the string used on.
The logger function has been removed as it has become easy to create your own with the examples above.
There is a new utility in forge called DistExecutor that has these capabilities. When loading proxies use the DistExecutor as well and instead of logging in the below example instantiate your proxies.
The DistExecutor functions has should make it so that client side code does not get loaded on the server side and the reverse.
DistExecutor.runForDist(
Supplier { Supplier { logger.info("I am on the client side") } },
Supplier { Supplier { logger.info("I am on the server side") } }
)
DistExecutor.callWhenOn(Dist.CLIENT) { Callable {
logger.info("I am on the client side")
}}
DistExecutor.callWhenOn(Dist.DEDICATED_SERVER) { Callable {
logger.info("I am on the server side")
}}This is now integrated in the new config system so this should not be here taking up space.
This is not needed as there are not one client side and one server side. And this is almost like the using the I18n class anyway.
As of yet there are no config screens as it looks now. Might make it back in.
Removed as the is not mainly a library as of the sort that makes everything just "easier". The World.isServer and World.isClient is not removed as they exist to make it more clear to read.
The configuration system has gone through a rework as have the underlying forge system. The new ConfigurationHandler works great with delegates. As it is the primary way I have designed it to be. I do have to give credit to the new forge configuration as it has improved. Here is a little example.
object MyConfig : ConfigurationHandler() {
val myBooleanProperty: Boolean by property
.translation("config.myBooleanProperty")
.comment("This is my comment")
.define("myBooleanProperty", true)
object MyCategory {
init {
property
.comment("My comment for the category")
.push("mycategory")
}
val test: Test by property
.define("test", Test.VAL1)
.also { property.pop() }
enum class Test { VAL1, VAL2 }
}
}Great, how do I use it? You use it by registering it with your mod in the mod context.
KotlinModContext.get().registerConfig(TestConfig) // COMMON by default
// KotlinModContext.get().registerConfig(TestConfig, type = ModConfig.Type.COMMON)
// KotlinModContext.get().registerConfig(TestConfig, type = ModConfig.Type.CLIENT)
// KotlinModContext.get().registerConfig(TestConfig, type = ModConfig.Type.SERVER)
// All of these also have a fileName parameter
// KotlinModContext.get().registerConfig(TestConfig, fileName = "...", type = ModConfig.Type.COMMON)
// KotlinModContext.get().registerConfig(TestConfig, fileName = "...", type = ModConfig.Type.CLIENT)
// KotlinModContext.get().registerConfig(TestConfig, fileName = "...", type = ModConfig.Type.SERVER)