- Moved mod metadata files to common module - This should make classtweakers apply for users relying on the common module in Loom

- Moved mod metadata files to common module - This should make classtweakers apply for users relying on the common module in Loom

# Thermoo 10.1.4 - Publish MDG-compatible AT/Interface injections via NeoLoom - Updated Argentine Spanish translations

# Thermoo 10.1.4 - Publish MDG-compatible AT/Interface injections via NeoLoom - Updated Argentine Spanish translations

- Fixed crash with Polymer patch

- Fixed crash with Polymer patch

# Thermoo 10.1: Multiloaderification Thermoo now fully supports both Fabric and Neoforge for Minecraft 26.1.x. The Neoforge version of Thermoo no longer requires Forgified Fabric API, but it does require the Yumi Minecraft Foundation library (which is bundled with the mod). This release should also be fully compatible with 10.0.x. There are should be no breaking changes for users of this mod. However, as Thermoo now ships a common module, some things may change for developers consuming this mod. Changelog: - Ported Thermoo to a multi-loader architecture based on Neo-Loom. - Thermoo now ships `thermoo-common`, `thermoo-fabric`, and `thermoo-neoforge` jars. - Added support for Neoforge. - Added a new `ThermooDataComponentMapBuilder` interface to support what the `FabricDataComponentMapBuilder` interface does, but in a loader-agnostic way. 10.1.1 changelog: - Fixed javadoc jar not generating any data - Fixed the patch list url and removed the option from the default config

# Thermoo 10.1: Multiloaderification Thermoo now fully supports both Fabric and Neoforge for Minecraft 26.1.x. The Neoforge version of Thermoo no longer requires Forgified Fabric API, but it does require the Yumi Minecraft Foundation library (which is bundled with the mod). This release should also be fully compatible with 10.0.x. There are should be no breaking changes for users of this mod. However, as Thermoo now ships a common module, some things may change for developers consuming this mod. Changelog: - Ported Thermoo to a multi-loader architecture based on Neo-Loom. - Thermoo now ships `thermoo-common`, `thermoo-fabric`, and `thermoo-neoforge` jars. - Added support for Neoforge. - Added a new `ThermooDataComponentMapBuilder` interface to support what the `FabricDataComponentMapBuilder` interface does, but in a loader-agnostic way. 10.1.1 changelog: - Fixed javadoc jar not generating any data - Fixed the patch list url and removed the option from the default config

* Fixed attribute modifier temperature status effect removing itself wrongly

# Thermoo 10.0.0 for Minecraft 26.1.x The full release of Thermoo 10 for Minecraft 26.1.x. Thermoo 10 is now considered stable and no further breaking changes are planned. Documentation has now also been updated. New from 10.0.0-beta.4: * Added a `IS_COLD_ENOUGH_TO_SNOW` event to the `ThermooSeasonEvents` class. * This provides a way to check if a seasons mod believes that an area should be snowy without relying on multiple redundant or inconsistent vanilla checks. * A convenience method to invoke this event has been added in `ThermooSeason`. * Introduced a more fool-proof way of registering attributes to entities to avoid invalid data from other mods prematurely cancelling `createLivingAttributes`. Full changelog from 9.x: * Updated to Minecraft 26.1.x * Replaced API exposure of Fabric API with Yumi classes. * For example: * `net.fabricmc.fabric.api.event.Event` -> `dev.yumi.commons.event.Event`, * `net.fabricmc.fabric.api.util.TriState` -> `dev.yumi.commons.TriState` * Usage of Yumi events is essentially identical to Fabric API events, but it does not tie Thermoo's API to another Minecraft mod. * This is primarily intended to make a future non-FFAPI based Neoforge port of Thermoo possible. * I will not be making FFAPI-free ports of Frostiful. * Replaced the Temperature Effect API with the Temperature Status API ([#104](https://github.com/TheDeathlyCow/thermoo/pull/104)). * Added Temperature Status Tags ([#106](https://github.com/TheDeathlyCow/thermoo/pull/106)). * Replaced `HeatingMode` with a data-driven temperature sources API ([#109](https://github.com/TheDeathlyCow/thermoo/pull/109)). * Added F3 debug screen entries for temperature, soaking, and environment providers. * Added a new event: `TemperatureStatusEvents#ALLOW_TEMPERATURE_STATUS` that allows for finer grained control over temperature statuses than the enable/disable API. * The command `/thermoo temperature status` now permits `enable` or `disable` syntax as an alternative to `set_enabled`. * Removed previously deprecated usage of `/thermoo environment relativehumidity`, users must now use `/thermoo environment relative_humidity`. * Added version numbers to API packages. * For example: * `com.github.thedeathlycow.thermoo.api.command` -> `com.github.thedeathlycow.thermoo.api.command.v1` * `com.github.thedeathlycow.thermoo.api.temperature.effect` -> `com.github.thedeathlycow.thermoo.api.temperature.status.v2` * `com.github.thedeathlycow.thermoo.api.environment.*` -> `com.github.thedeathlycow.thermoo.api.environment.v2.*` * `com.github.thedeathlycow.thermoo.api.item.*` -> `com.github.thedeathlycow.thermoo.api.item.v2.*` * `com.github.thedeathlycow.thermoo.api.season.*` -> `com.github.thedeathlycow.thermoo.api.season.v2.*` * `com.github.thedeathlycow.thermoo.api.util.*` -> `com.github.thedeathlycow.thermoo.api.util.v1.*` (these classes may still be split up to more specific packages) * `com.github.thedeathlycow.thermoo.api.client.*` -> `com.github.thedeathlycow.thermoo.api.client.v1.*` * Removed command definition classes from API. * These are now implementation classes. * Renamed `*ArgumentType` classes to `*Argument` in the command API. * Moved the `ThermooRegistries` and `ThermooRegistryKeys` classes to a `registry` package in the core API * Moved the `predicate` package and `ThermooAttributes` class to a new entity API package: `com.github.thedeathlycow.thermoo.api.entity.v1` * Split the `Item` and `EntityType` tags in `ThermooTags` into classes in the entity API (`ThermooEntityTypeTags`) and item API (`ThermooItemTags`), respectively * Removed `ThermooTags`. * Usage of `GuiGraphics` in `StatusBarOverlayRenderEvents` was replaced with `GuiGraphicsExtractor` * Moved all classes previously under the `util` package to the `core.v2` package. * Renamed `TemperatureRecord#add(TemperatureRecord)` to `TemperatureRecord#shift(TemperatureRecord)`, and deprecated the `add` method. * Added convenience methods for creating instances of `TemperatureChange` to `BuiltinTemperatureSources`. * Refactored the `TemperatureLootCondition` and `SoakedLootCondition` classes to no longer be records. * Replaced the `EnvironmentProviderType` class and its usage with direct registration of `MapCodec`s. * Established a more uniform and consistent naming scheme for the builtin implementations of `EnvironmentProvider`. Classes were renamed as follows: * `ConstantEnvironmentProvider` -> `ConstantProvider` * `ModifyEnvironmentProvider` -> `ModifyProvider` * `TemperatureShiftEnvironmentProvider` -> `ShiftTemperatureProvider` * `SetTemperatureFromPressure` -> `SetTemperatureFromPressureProvider` * `SetPressureFromAltitude` -> `SetPressureFromAltitudeProvider` * `TemperateSeasonEnvironmentProvider` -> `TemperateSeasonSelector` * `TropicalSeasonEnvironmentProvider` -> `TropicalSeasonSelector` * `LightThresholdLightProvider` -> `LightThresholdSelector` * `WeatherStateEnvironmentProvider` -> `WeatherStateSelector` * `BiomePrecipitationTypeEnvironmentProvider` -> `PrecipitationTypeSelector` * Renamed Thermoo registry classes to match Mojmap: * `ThermooRegistries` -> `ThermooBuiltInRegistries` * `ThermooRegistryKeys` -> `ThermooRegistries` ## Data-driven Temperature Sources * Moved all classes and packages under `com.github.thedeathlycow.thermoo.api.temperature.*` EXCEPT for the `status` package to `com.github.thedeathlycow.thermoo.api.core.v2`. * Removed the `HeatingMode` and `HeatingModes` classes. * The method `TemperatureAware#thermoo$addTemperature(int, HeatingMode)` was converted to `TemperatureAware#thermoo$addTemperature(int, TemperatureChange)`. * `TemperatureChange` now stores information about the context of individual temperature changes, including source, cause, direct cause, and position, and this data is now passed to various temperature change related events. * Added a new `ThermooLevel` interface that is injected onto all `Level` instances by mixin. * `ThermooLevel` provides access to a set of shared instances of `TemperatureChange`. * The `ALLOW_X_UPDATE` and `ALLOW_X_CHANGE` events in `LivingEntityTemperatureTickEvents` were removed and replaced with more general events in `TemperatureChangeEvents`. * The `GET_X_CHANGE` event in `LivingEntityTemperatureTickEvents` is now a source-key mapped event returned by `getTemperatureChange` that allows for the same sort of event to apply to any temperature source - except absolute and environment sources. * The `/thermoo temperature (add|remove)` sub-commands now provide more ability to specify context about a temperature change with `at` and `by` syntax, essentially to provide the data for the `TemperatureChange` class. ### Example Migration A simple migration of adding temperature: ```diff void foo(LivingEntity e) { - e.thermoo$addTemperature(10, HeatingModes.ACTIVE); + e.thermoo$addTemperature(10, e.level().thermoo$temperatureSources().active()); } ``` ## Temperature Status API The Temperature Effect API was rewritten and renamed to the Temperature Status API to better distinguish between the JSON files (statuses) and the effect types that actually do the work. The API largely does the same thing, but here is a summary of the changes: - Replaced the `thermoo/temperature_effect` registry with `thermoo/temperature_status` registry - The new status registry is now an actual registry, which supports tags, synchronisation, and `Holder`s, and all that. - Replaced `config` objects with a direct `effects` list entry. - Moved type delegation to entries of the effects, rather than at the root of the registry object. - Merged the `attribute_modifier` and `scaling_attribute_modifier` into a single type, differentiated with a field. - Removed the `empty` and `sequence` types, they are no longer needed. - Added a way to define the application order of statuses with the `thermoo:application_order` temperature status tag. This also removed some functionality: - Temperature statuses can no longer be "hot reloaded"; you must restart the server to reload them. - There is no longer a `loading_priority` field. The intended functionality behind this was to allow Thermoo Patches to override the effects from Frostiful/Scorchful with a check for Origin. This was superseded by the enable API. It is not known if anyone else used this for any particular functionality that was actually necessary, so it is being removed. ### Example migration Old effect ```json { "type": "thermoo:damage", "temperature_scale_range": { "max": -0.99 }, "config": { "amount": 1, "damage_interval": 20, "damage_type": "minecraft:freeze" } } ``` New status ```json { "temperature_scale_range": { "max": -0.99 }, "interval": 20, "effects": [ { "type": "thermoo:damage", "amount": 1, "damage_type": "minecraft:freeze" } ] } ```