Thermoo 10.0.0 Beta 3 for Minecraft 26.1
Another beta build for Thermoo 10 for Minecraft 26.1, this time targeting the full release. While this is targeting the release version, further breaking changes are still possible.. Documentation has not yet been updated either, but it will be soon.
Beta 4
- Fixed Yumi libraries not loading correctly, causing a start-up crash.
Beta 3
- Updated to release 26.1
- Updated Polymer integration
- Breaking change: Renamed Thermoo registry classes to match Mojmap:
ThermooRegistries->ThermooBuiltInRegistriesThermooRegistryKeys->ThermooRegistries
Beta 2
- Replaced usage of
net.fabricmc.fabric.api.util.TriStatein the public API withdev.yumi.commons.TriState - Added a new event:
TemperatureStatusEvents#ALLOW_TEMPERATURE_STATUSthat allows for finer grained control over temperature statuses than the enable/disable API. - Added F3 debug screen entries for temperature and soaking.
- The command
/thermoo temperature statusnow permitsenableordisablesyntax as an alternative toset_enabled. - Removed previously deprecated usage of
/thermoo environment relativehumidity, users must now use/thermoo environment relative_humidity.
Beta 1
- Bumped the version of the
corepackage tov2to align with the general vibe of changes 26.1 is introducing. - Moved all classes previously under the
util.v1package to thecore.v2package. - Renamed
TemperatureRecord#add(TemperatureRecord)toTemperatureRecord#shift(TemperatureRecord), and deprecated theaddmethod. - Added convenience methods for creating instances of
TemperatureChangetoBuiltinTemperatureSources. - Replaced API exposure of Fabric API with Yumi Commons by LambdAurora.
- Replaced all usage of Fabric API event classes (
net.fabricmc.fabric.api.event.Event) with Yumi event classes (dev.yumi.commons.event.Event).- 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.
- Refactored the
TemperatureLootConditionandSoakedLootConditionclasses to no longer be records. - Replaced the
EnvironmentProviderTypeclass and its usage with direct registration ofMapCodecs. - Established a more uniform and consistent naming scheme for the builtin implementations of
EnvironmentProvider. Classes were renamed as follows:ConstantEnvironmentProvider->ConstantProviderModifyEnvironmentProvider->ModifyProviderTemperatureShiftEnvironmentProvider->ShiftTemperatureProviderSetTemperatureFromPressure->SetTemperatureFromPressureProviderSetPressureFromAltitude->SetPressureFromAltitudeProviderTemperateSeasonEnvironmentProvider->TemperateSeasonSelectorTropicalSeasonEnvironmentProvider->TropicalSeasonSelectorLightThresholdLightProvider->LightThresholdSelectorWeatherStateEnvironmentProvider->WeatherStateSelectorBiomePrecipitationTypeEnvironmentProvider->PrecipitationTypeSelector
Alpha 2
- Replaced
HeatingModewith a data-driven temperature sources API (#109). - Moved all remaining API packages to versioned packages, as follows:
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.*
- Moved the
ThermooRegistriesandThermooRegistryKeysclasses to aregistrypackage in the core API - Moved the
predicatepackage andThermooAttributesclass to a new entity API package:com.github.thedeathlycow.thermoo.api.entity.v1 - Split the
ItemandEntityTypetags inThermooTagsinto classes in the entity API (ThermooEntityTypeTags) and item API (ThermooItemTags), respectively - Removed
ThermooTags. - Usage of
GuiGraphicsinStatusBarOverlayRenderEventswas replaced withGuiGraphicsExtractor
Data-driven Temperature Sources
- Moved all classes and packages under
com.github.thedeathlycow.thermoo.api.temperature.*EXCEPT for thestatuspackage tocom.github.thedeathlycow.thermoo.api.core.v2. - Removed the
HeatingModeandHeatingModesclasses. - The method
TemperatureAware#thermoo$addTemperature(int, HeatingMode)was converted toTemperatureAware#thermoo$addTemperature(int, TemperatureChange). TemperatureChangenow 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
ThermooLevelinterface that is injected onto allLevelinstances by mixin.ThermooLevelprovides access to a set of shared instances ofTemperatureChange.
- The
ALLOW_X_UPDATEandALLOW_X_CHANGEevents inLivingEntityTemperatureTickEventswere removed and replaced with more general events inTemperatureChangeEvents. - The
GET_X_CHANGEevent inLivingEntityTemperatureTickEventsis now a source-key mapped event returned bygetTemperatureChangethat 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 withatandbysyntax, essentially to provide the data for theTemperatureChangeclass.
Alpha 1
- Begun adding version numbers to API packages.
- So far this has impacted the following packages:
com.github.thedeathlycow.thermoo.api.command->com.github.thedeathlycow.thermoo.api.command.v1com.github.thedeathlycow.thermoo.api.temperature.effect->com.github.thedeathlycow.thermoo.api.temperature.status.v2
- More packages will be moved before the full 26.1 release.
- So far this has impacted the following packages:
- Removed command definition classes from API.
- These are now implementation classes.
- Renamed
*ArgumentTypeclasses to*Argumentin the command API. - Replaced the Temperature Effect API with the Temperature Status API (#104).
- Added Temperature Status Tags (#106).
Example Migration
A simple migration of adding temperature:
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_effectregistry withthermoo/temperature_statusregistry - The new status registry is now an actual registry, which supports tags, synchronisation, and
Holders, and all that. - Replaced
configobjects with a directeffectslist entry. - Moved type delegation to entries of the effects, rather than at the root of the registry object.
- Merged the
attribute_modifierandscaling_attribute_modifierinto a single type, differentiated with a field. - Removed the
emptyandsequencetypes, they are no longer needed. - Added a way to define the application order of statuses with the
thermoo:application_ordertemperature 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_priorityfield. 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
{
"type": "thermoo:damage",
"temperature_scale_range": {
"max": -0.99
},
"config": {
"amount": 1,
"damage_interval": 20,
"damage_type": "minecraft:freeze"
}
}
New status
{
"temperature_scale_range": {
"max": -0.99
},
"interval": 20,
"effects": [
{
"type": "thermoo:damage",
"amount": 1,
"damage_type": "minecraft:freeze"
}
]
}
Thermoo 10.0.0 Beta 3 for Minecraft 26.1
Another beta build for Thermoo 10 for Minecraft 26.1, this time targeting the full release. While this is targeting the release version, further breaking changes are still possible.. Documentation has not yet been updated either, but it will be soon.
Beta 3
- Updated to release 26.1
- Updated Polymer integration
- Breaking change: Renamed Thermoo registry classes to match Mojmap:
ThermooRegistries->ThermooBuiltInRegistriesThermooRegistryKeys->ThermooRegistries
Beta 2
- Replaced usage of
net.fabricmc.fabric.api.util.TriStatein the public API withdev.yumi.commons.TriState - Added a new event:
TemperatureStatusEvents#ALLOW_TEMPERATURE_STATUSthat allows for finer grained control over temperature statuses than the enable/disable API. - Added F3 debug screen entries for temperature and soaking.
- The command
/thermoo temperature statusnow permitsenableordisablesyntax as an alternative toset_enabled. - Removed previously deprecated usage of
/thermoo environment relativehumidity, users must now use/thermoo environment relative_humidity.
Beta 1
- Bumped the version of the
corepackage tov2to align with the general vibe of changes 26.1 is introducing. - Moved all classes previously under the
util.v1package to thecore.v2package. - Renamed
TemperatureRecord#add(TemperatureRecord)toTemperatureRecord#shift(TemperatureRecord), and deprecated theaddmethod. - Added convenience methods for creating instances of
TemperatureChangetoBuiltinTemperatureSources. - Replaced API exposure of Fabric API with Yumi Commons by LambdAurora.
- Replaced all usage of Fabric API event classes (
net.fabricmc.fabric.api.event.Event) with Yumi event classes (dev.yumi.commons.event.Event).- 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.
- Refactored the
TemperatureLootConditionandSoakedLootConditionclasses to no longer be records. - Replaced the
EnvironmentProviderTypeclass and its usage with direct registration ofMapCodecs. - Established a more uniform and consistent naming scheme for the builtin implementations of
EnvironmentProvider. Classes were renamed as follows:ConstantEnvironmentProvider->ConstantProviderModifyEnvironmentProvider->ModifyProviderTemperatureShiftEnvironmentProvider->ShiftTemperatureProviderSetTemperatureFromPressure->SetTemperatureFromPressureProviderSetPressureFromAltitude->SetPressureFromAltitudeProviderTemperateSeasonEnvironmentProvider->TemperateSeasonSelectorTropicalSeasonEnvironmentProvider->TropicalSeasonSelectorLightThresholdLightProvider->LightThresholdSelectorWeatherStateEnvironmentProvider->WeatherStateSelectorBiomePrecipitationTypeEnvironmentProvider->PrecipitationTypeSelector
Alpha 2
- Replaced
HeatingModewith a data-driven temperature sources API (#109). - Moved all remaining API packages to versioned packages, as follows:
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.*
- Moved the
ThermooRegistriesandThermooRegistryKeysclasses to aregistrypackage in the core API - Moved the
predicatepackage andThermooAttributesclass to a new entity API package:com.github.thedeathlycow.thermoo.api.entity.v1 - Split the
ItemandEntityTypetags inThermooTagsinto classes in the entity API (ThermooEntityTypeTags) and item API (ThermooItemTags), respectively - Removed
ThermooTags. - Usage of
GuiGraphicsinStatusBarOverlayRenderEventswas replaced withGuiGraphicsExtractor
Data-driven Temperature Sources
- Moved all classes and packages under
com.github.thedeathlycow.thermoo.api.temperature.*EXCEPT for thestatuspackage tocom.github.thedeathlycow.thermoo.api.core.v2. - Removed the
HeatingModeandHeatingModesclasses. - The method
TemperatureAware#thermoo$addTemperature(int, HeatingMode)was converted toTemperatureAware#thermoo$addTemperature(int, TemperatureChange). TemperatureChangenow 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
ThermooLevelinterface that is injected onto allLevelinstances by mixin.ThermooLevelprovides access to a set of shared instances ofTemperatureChange.
- The
ALLOW_X_UPDATEandALLOW_X_CHANGEevents inLivingEntityTemperatureTickEventswere removed and replaced with more general events inTemperatureChangeEvents. - The
GET_X_CHANGEevent inLivingEntityTemperatureTickEventsis now a source-key mapped event returned bygetTemperatureChangethat 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 withatandbysyntax, essentially to provide the data for theTemperatureChangeclass.
Alpha 1
- Begun adding version numbers to API packages.
- So far this has impacted the following packages:
com.github.thedeathlycow.thermoo.api.command->com.github.thedeathlycow.thermoo.api.command.v1com.github.thedeathlycow.thermoo.api.temperature.effect->com.github.thedeathlycow.thermoo.api.temperature.status.v2
- More packages will be moved before the full 26.1 release.
- So far this has impacted the following packages:
- Removed command definition classes from API.
- These are now implementation classes.
- Renamed
*ArgumentTypeclasses to*Argumentin the command API. - Replaced the Temperature Effect API with the Temperature Status API (#104).
- Added Temperature Status Tags (#106).
Example Migration
A simple migration of adding temperature:
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_effectregistry withthermoo/temperature_statusregistry - The new status registry is now an actual registry, which supports tags, synchronisation, and
Holders, and all that. - Replaced
configobjects with a directeffectslist entry. - Moved type delegation to entries of the effects, rather than at the root of the registry object.
- Merged the
attribute_modifierandscaling_attribute_modifierinto a single type, differentiated with a field. - Removed the
emptyandsequencetypes, they are no longer needed. - Added a way to define the application order of statuses with the
thermoo:application_ordertemperature 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_priorityfield. 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
{
"type": "thermoo:damage",
"temperature_scale_range": {
"max": -0.99
},
"config": {
"amount": 1,
"damage_interval": 20,
"damage_type": "minecraft:freeze"
}
}
New status
{
"temperature_scale_range": {
"max": -0.99
},
"interval": 20,
"effects": [
{
"type": "thermoo:damage",
"amount": 1,
"damage_type": "minecraft:freeze"
}
]
}
Thermoo 10.0.0 Beta 1 for Minecraft 26.1-pre-2
A beta build for Thermoo 10 for Minecraft 26.1. At this time, I have implemented all the features I plan to release for 26.1. However, further breaking changes are still possible. Because of this, the documentation has also not yet been updated! The Thermoo Docs will be fully updated when the API changes are finalized for 26.1.
Beta 2
- Replaced usage of
net.fabricmc.fabric.api.util.TriStatein the public API withdev.yumi.commons.TriState - Added a new event:
TemperatureStatusEvents#ALLOW_TEMPERATURE_STATUSthat allows for finer grained control over temperature statuses than the enable/disable API. - Added F3 debug screen entries for temperature and soaking.
- The command
/thermoo temperature statusnow permitsenableordisablesyntax as an alternative toset_enabled. - Removed previously deprecated usage of
/thermoo environment relativehumidity, users must now use/thermoo environment relative_humidity.
Beta 1
- Bumped the version of the
corepackage tov2to align with the general vibe of changes 26.1 is introducing. - Moved all classes previously under the
util.v1package to thecore.v2package. - Renamed
TemperatureRecord#add(TemperatureRecord)toTemperatureRecord#shift(TemperatureRecord), and deprecated theaddmethod. - Added convenience methods for creating instances of
TemperatureChangetoBuiltinTemperatureSources. - Replaced API exposure of Fabric API with Yumi Commons by LambdAurora.
- Replaced all usage of Fabric API event classes (
net.fabricmc.fabric.api.event.Event) with Yumi event classes (dev.yumi.commons.event.Event).- 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.
- Refactored the
TemperatureLootConditionandSoakedLootConditionclasses to no longer be records. - Replaced the
EnvironmentProviderTypeclass and its usage with direct registration ofMapCodecs. - Established a more uniform and consistent naming scheme for the builtin implementations of
EnvironmentProvider. Classes were renamed as follows:ConstantEnvironmentProvider->ConstantProviderModifyEnvironmentProvider->ModifyProviderTemperatureShiftEnvironmentProvider->ShiftTemperatureProviderSetTemperatureFromPressure->SetTemperatureFromPressureProviderSetPressureFromAltitude->SetPressureFromAltitudeProviderTemperateSeasonEnvironmentProvider->TemperateSeasonSelectorTropicalSeasonEnvironmentProvider->TropicalSeasonSelectorLightThresholdLightProvider->LightThresholdSelectorWeatherStateEnvironmentProvider->WeatherStateSelectorBiomePrecipitationTypeEnvironmentProvider->PrecipitationTypeSelector
Alpha 2
- Replaced
HeatingModewith a data-driven temperature sources API (#109). - Moved all remaining API packages to versioned packages, as follows:
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.*
- Moved the
ThermooRegistriesandThermooRegistryKeysclasses to aregistrypackage in the core API - Moved the
predicatepackage andThermooAttributesclass to a new entity API package:com.github.thedeathlycow.thermoo.api.entity.v1 - Split the
ItemandEntityTypetags inThermooTagsinto classes in the entity API (ThermooEntityTypeTags) and item API (ThermooItemTags), respectively - Removed
ThermooTags. - Usage of
GuiGraphicsinStatusBarOverlayRenderEventswas replaced withGuiGraphicsExtractor
Data-driven Temperature Sources
- Moved all classes and packages under
com.github.thedeathlycow.thermoo.api.temperature.*EXCEPT for thestatuspackage tocom.github.thedeathlycow.thermoo.api.core.v2. - Removed the
HeatingModeandHeatingModesclasses. - The method
TemperatureAware#thermoo$addTemperature(int, HeatingMode)was converted toTemperatureAware#thermoo$addTemperature(int, TemperatureChange). TemperatureChangenow 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
ThermooLevelinterface that is injected onto allLevelinstances by mixin.ThermooLevelprovides access to a set of shared instances ofTemperatureChange.
- The
ALLOW_X_UPDATEandALLOW_X_CHANGEevents inLivingEntityTemperatureTickEventswere removed and replaced with more general events inTemperatureChangeEvents. - The
GET_X_CHANGEevent inLivingEntityTemperatureTickEventsis now a source-key mapped event returned bygetTemperatureChangethat 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 withatandbysyntax, essentially to provide the data for theTemperatureChangeclass.
Alpha 1
- Begun adding version numbers to API packages.
- So far this has impacted the following packages:
com.github.thedeathlycow.thermoo.api.command->com.github.thedeathlycow.thermoo.api.command.v1com.github.thedeathlycow.thermoo.api.temperature.effect->com.github.thedeathlycow.thermoo.api.temperature.status.v2
- More packages will be moved before the full 26.1 release.
- So far this has impacted the following packages:
- Removed command definition classes from API.
- These are now implementation classes.
- Renamed
*ArgumentTypeclasses to*Argumentin the command API. - Replaced the Temperature Effect API with the Temperature Status API (#104).
- Added Temperature Status Tags (#106).
Example Migration
A simple migration of adding temperature:
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_effectregistry withthermoo/temperature_statusregistry - The new status registry is now an actual registry, which supports tags, synchronisation, and
Holders, and all that. - Replaced
configobjects with a directeffectslist entry. - Moved type delegation to entries of the effects, rather than at the root of the registry object.
- Merged the
attribute_modifierandscaling_attribute_modifierinto a single type, differentiated with a field. - Removed the
emptyandsequencetypes, they are no longer needed. - Added a way to define the application order of statuses with the
thermoo:application_ordertemperature 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_priorityfield. 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
{
"type": "thermoo:damage",
"temperature_scale_range": {
"max": -0.99
},
"config": {
"amount": 1,
"damage_interval": 20,
"damage_type": "minecraft:freeze"
}
}
New status
{
"temperature_scale_range": {
"max": -0.99
},
"interval": 20,
"effects": [
{
"type": "thermoo:damage",
"amount": 1,
"damage_type": "minecraft:freeze"
}
]
}
Thermoo 10.0.0 Beta 1 for Minecraft 26.1-pre-2
A beta build for Thermoo 10 for Minecraft 26.1. At this time, I have implemented all the features I plan to release for 26.1. However, further breaking changes are still possible. Because of this, the documentation has also not yet been updated! The Thermoo Docs will be fully updated when the API changes are finalized for 26.1.
Beta 1
- Bumped the version of the
corepackage tov2to align with the general vibe of changes 26.1 is introducing. - Moved all classes previously under the
util.v1package to thecore.v2package. - Renamed
TemperatureRecord#add(TemperatureRecord)toTemperatureRecord#shift(TemperatureRecord), and deprecated theaddmethod. - Added convenience methods for creating instances of
TemperatureChangetoBuiltinTemperatureSources. - Replaced API exposure of Fabric API with Yumi Commons by LambdAurora.
- Replaced all usage of Fabric API event classes (
net.fabricmc.fabric.api.event.Event) with Yumi event classes (dev.yumi.commons.event.Event).- 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.
- Refactored the
TemperatureLootConditionandSoakedLootConditionclasses to no longer be records. - Replaced the
EnvironmentProviderTypeclass and its usage with direct registration ofMapCodecs. - Established a more uniform and consistent naming scheme for the builtin implementations of
EnvironmentProvider. Classes were renamed as follows:ConstantEnvironmentProvider->ConstantProviderModifyEnvironmentProvider->ModifyProviderTemperatureShiftEnvironmentProvider->ShiftTemperatureProviderSetTemperatureFromPressure->SetTemperatureFromPressureProviderSetPressureFromAltitude->SetPressureFromAltitudeProviderTemperateSeasonEnvironmentProvider->TemperateSeasonSelectorTropicalSeasonEnvironmentProvider->TropicalSeasonSelectorLightThresholdLightProvider->LightThresholdSelectorWeatherStateEnvironmentProvider->WeatherStateSelectorBiomePrecipitationTypeEnvironmentProvider->PrecipitationTypeSelector
Alpha 2
- Replaced
HeatingModewith a data-driven temperature sources API (#109). - Moved all remaining API packages to versioned packages, as follows:
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.*
- Moved the
ThermooRegistriesandThermooRegistryKeysclasses to aregistrypackage in the core API - Moved the
predicatepackage andThermooAttributesclass to a new entity API package:com.github.thedeathlycow.thermoo.api.entity.v1 - Split the
ItemandEntityTypetags inThermooTagsinto classes in the entity API (ThermooEntityTypeTags) and item API (ThermooItemTags), respectively - Removed
ThermooTags. - Usage of
GuiGraphicsinStatusBarOverlayRenderEventswas replaced withGuiGraphicsExtractor
Data-driven Temperature Sources
- Moved all classes and packages under
com.github.thedeathlycow.thermoo.api.temperature.*EXCEPT for thestatuspackage tocom.github.thedeathlycow.thermoo.api.core.v2. - Removed the
HeatingModeandHeatingModesclasses. - The method
TemperatureAware#thermoo$addTemperature(int, HeatingMode)was converted toTemperatureAware#thermoo$addTemperature(int, TemperatureChange). TemperatureChangenow 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
ThermooLevelinterface that is injected onto allLevelinstances by mixin.ThermooLevelprovides access to a set of shared instances ofTemperatureChange.
- The
ALLOW_X_UPDATEandALLOW_X_CHANGEevents inLivingEntityTemperatureTickEventswere removed and replaced with more general events inTemperatureChangeEvents. - The
GET_X_CHANGEevent inLivingEntityTemperatureTickEventsis now a source-key mapped event returned bygetTemperatureChangethat 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 withatandbysyntax, essentially to provide the data for theTemperatureChangeclass.
Alpha 1
- Begun adding version numbers to API packages.
- So far this has impacted the following packages:
com.github.thedeathlycow.thermoo.api.command->com.github.thedeathlycow.thermoo.api.command.v1com.github.thedeathlycow.thermoo.api.temperature.effect->com.github.thedeathlycow.thermoo.api.temperature.status.v2
- More packages will be moved before the full 26.1 release.
- So far this has impacted the following packages:
- Removed command definition classes from API.
- These are now implementation classes.
- Renamed
*ArgumentTypeclasses to*Argumentin the command API. - Replaced the Temperature Effect API with the Temperature Status API (#104).
- Added Temperature Status Tags (#106).
Example Migration
A simple migration of adding temperature:
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_effectregistry withthermoo/temperature_statusregistry - The new status registry is now an actual registry, which supports tags, synchronisation, and
Holders, and all that. - Replaced
configobjects with a directeffectslist entry. - Moved type delegation to entries of the effects, rather than at the root of the registry object.
- Merged the
attribute_modifierandscaling_attribute_modifierinto a single type, differentiated with a field. - Removed the
emptyandsequencetypes, they are no longer needed. - Added a way to define the application order of statuses with the
thermoo:application_ordertemperature 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_priorityfield. 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
{
"type": "thermoo:damage",
"temperature_scale_range": {
"max": -0.99
},
"config": {
"amount": 1,
"damage_interval": 20,
"damage_type": "minecraft:freeze"
}
}
New status
{
"temperature_scale_range": {
"max": -0.99
},
"interval": 20,
"effects": [
{
"type": "thermoo:damage",
"amount": 1,
"damage_type": "minecraft:freeze"
}
]
}
Thermoo 10.0.0 Alpha 2 for Minecraft 26.1-snapshot-11
A second pre-release build for Thermoo 10 for Minecraft 26.1. This is an alpha version, and the API remains extremely unstable as further breaking changes are planned. Because of this, the documentation has also not yet been updated! The Thermoo Docs will be fully updated when the API changes are finalized for 26.1.
This release is primarily intended for me to get a head start on updating Frostiful and Scorchful, and also to open Thermoo up to public bugtesting from whomever wants to do that.
Alpha 1
- Begun adding version numbers to API packages.
- So far this has impacted the following packages:
com.github.thedeathlycow.thermoo.api.command->com.github.thedeathlycow.thermoo.api.command.v1com.github.thedeathlycow.thermoo.api.temperature.effect->com.github.thedeathlycow.thermoo.api.temperature.status.v2
- More packages will be moved before the full 26.1 release.
- So far this has impacted the following packages:
- Removed command definition classes from API.
- These are now implementation classes.
- Renamed
*ArgumentTypeclasses to*Argumentin the command API. - Replaced the Temperature Effect API with the Temperature Status API (#104).
- Added Temperature Status Tags (#106).
Alpha 2
- Replaced
HeatingModewith a data-driven temperature sources API (#109). - Moved all remaining API packages to versioned packages, as follows:
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.*
- Moved the
ThermooRegistriesandThermooRegistryKeysclasses to aregistrypackage in the core API - Moved the
predicatepackage andThermooAttributesclass to a new entity API package:com.github.thedeathlycow.thermoo.api.entity.v1 - Split the
ItemandEntityTypetags inThermooTagsinto classes in the entity API (ThermooEntityTypeTags) and item API (ThermooItemTags), respectively - Removed
ThermooTags. - Usage of
GuiGraphicsinStatusBarOverlayRenderEventswas replaced withGuiGraphicsExtractor
Data-driven Temperature Sources
- Moved all classes and packages under
com.github.thedeathlycow.thermoo.api.temperature.*EXCEPT for thestatuspackage tocom.github.thedeathlycow.thermoo.api.core.v1. - Removed the
HeatingModeandHeatingModesclasses. - The method
TemperatureAware#thermoo$addTemperature(int, HeatingMode)was converted toTemperatureAware#thermoo$addTemperature(int, TemperatureChange). TemperatureChangenow 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
ThermooLevelinterface that is injected onto allLevelinstances by mixin.ThermooLevelprovides access to a set of shared instances ofTemperatureChange.
- The
ALLOW_X_UPDATEandALLOW_X_CHANGEevents inLivingEntityTemperatureTickEventswere removed and replaced with more general events inTemperatureChangeEvents. - The
GET_X_CHANGEevent inLivingEntityTemperatureTickEventsis now a source-key mapped event returned bygetTemperatureChangethat 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 withatandbysyntax, essentially to provide the data for theTemperatureChangeclass.
Example Migration
A simple migration of adding temperature:
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_effectregistry withthermoo/temperature_statusregistry - The new status registry is now an actual registry, which supports tags, synchronisation, and
Holders, and all that. - Replaced
configobjects with a directeffectslist entry. - Moved type delegation to entries of the effects, rather than at the root of the registry object.
- Merged the
attribute_modifierandscaling_attribute_modifierinto a single type, differentiated with a field. - Removed the
emptyandsequencetypes, they are no longer needed. - Added a way to define the application order of statuses with the
thermoo:application_ordertemperature 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_priorityfield. 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
{
"type": "thermoo:damage",
"temperature_scale_range": {
"max": -0.99
},
"config": {
"amount": 1,
"damage_interval": 20,
"damage_type": "minecraft:freeze"
}
}
New status
{
"temperature_scale_range": {
"max": -0.99
},
"interval": 20,
"effects": [
{
"type": "thermoo:damage",
"amount": 1,
"damage_type": "minecraft:freeze"
}
]
}
Thermoo 4.8.1 for Minecraft 1.21.1
- Added ability to dynamically toggle temperature effects on and off on a per-entity basis using the command
/thermoo temperature effect set_enabled. - Fixed some temperature effects not being properly removed.
- Hotfix 4.8.1: publish interface injection data as a classified artifact
Thermoo 4.8.0 for Minecraft 1.21.1
- Added ability to dynamically toggle temperature effects on and off on a per-entity basis using the command
/thermoo temperature effect set_enabled. - Fixed some temperature effects not being properly removed.
Thermoo 10.0.0 Alpha 1 for Minecraft 26.1-snapshot-11
A first pre-release build for Thermoo 10 for Minecraft 26.1. This is an alpha version, and the API remains extremely unstable as further breaking changes are planned. Because of this, the documentation has also not yet been updated! The Thermoo Docs will be fully updated when the API changes are finalized for 26.1.
This release is primarily intended for me to get a head start on updating Frostiful and Scorchful, and also to open Thermoo up to public bugtesting from whomever wants to do that.
- Begun adding version numbers to API packages.
- So far this has impacted the following packages:
com.github.thedeathlycow.thermoo.api.command->com.github.thedeathlycow.thermoo.api.command.v1com.github.thedeathlycow.thermoo.api.temperature.effect->com.github.thedeathlycow.thermoo.api.temperature.status.v2
- More packages will be moved before the full 26.1 release.
- So far this has impacted the following packages:
- Removed command definition classes from API.
- These are now implementation classes.
- Renamed
*ArgumentTypeclasses to*Argumentin the command API. - Replaced the Temperature Effect API with the Temperature Status API (#104).
- Added Temperature Status Tags (#106).
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_effectregistry withthermoo/temperature_statusregistry - The new status registry is now an actual registry, which supports tags, synchronisation, and
Holders, and all that. - Replaced
configobjects with a directeffectslist entry. - Moved type delegation to entries of the effects, rather than at the root of the registry object.
- Merged the
attribute_modifierandscaling_attribute_modifierinto a single type, differentiated with a field. - Removed the
emptyandsequencetypes, they are no longer needed. - Added a way to define the application order of statuses with the
thermoo:application_ordertemperature 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_priorityfield. 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
{
"type": "thermoo:damage",
"temperature_scale_range": {
"max": -0.99
},
"config": {
"amount": 1,
"damage_interval": 20,
"damage_type": "minecraft:freeze"
}
}
New status
{
"temperature_scale_range": {
"max": -0.99
},
"interval": 20,
"effects": [
{
"type": "thermoo:damage",
"amount": 1,
"damage_type": "minecraft:freeze"
}
]
}
Thermoo 4.8.0 for Minecraft 1.21.1
- Added ability to dynamically toggle temperature effects on and off on a per-entity basis using the command
/thermoo temperature effect set_enabled. - Fixed some temperature effects not being properly removed.
Thermoo 9.1: Atmospheric Pressure
- Added ability to dynamically toggle temperature effects on and off on a per-entity basis using the command
/thermoo temperature effect set_enabled. - Added a Java API to dynamically toggle temperature effects on and off on a per-entity basis to the
ConfiguredTemperatureEffectclass. - Added Thermoo specific entries to the F3 debug screen, these are disabled by default.
- Added an atmospheric pressure environment component type.
- This component stores the local atmospheric pressure in millibars.
- Added an atmospheric pressure gameplay environment attribute.
- This attribute is used as the default value for the environment component map.
- Added a sub-command to
/thermoo environmentto get the atmospheric pressure value at a block position. - Added
thermoo:set_temperature_from_pressureenvironment provider type. - Added
thermoo:set_pressure_from_altitudeenvironment provider type. - The relative humidity can now be queried using
/thermoo environment relative_humidity.- The old usage of
/thermoo environment relativehumiditystill works but is now deprecated.
- The old usage of
Thermoo for Neoforge 1.21.1
Thermoo has now been ported to Neoforge 1.21.1, courtesy of Forgified Fabric API. This port may not be fully stable just yet and as such is released as an Alpha. However, it does not require Connector and as such should work a bit better.
Server owners should note that this port does not include the Polymer patch, as Polymer is a Fabric-only mod. If you want to use Thermoo server side with Polymer, you will still need to use the Fabric version of Thermoo via Connector.
I do not plan to update this port to any game version other than 1.21.1. FFAPI is currently not available for any later version, and I am just simply uninterested in 1.20.1 (not to mention that I would also need to translate Thermoo 1.20.1 to Mojmap). If/when FFAPI updates to a newer Minecraft version, I will remake the port for that version too.
Changes from Thermoo 4.7.0+neoforge:
- 4.7.1: Published interface injection data
Thermoo for Neoforge 1.21.1
Thermoo has now been ported to Neoforge 1.21.1, courtesy of Forgified Fabric API. This port may not be fully stable just yet and as such is released as an Alpha. However, it does not require Connector and as such should work a bit better.
Server owners should note that this port does not include the Polymer patch, as Polymer is a Fabric-only mod. If you want to use Thermoo server side with Polymer, you will still need to use the Fabric version of Thermoo via Connector.
I do not plan to update this port to any game version other than 1.21.1. FFAPI is currently not available for any later version, and I am just simply uninterested in 1.20.1 (not to mention that I would also need to translate Thermoo 1.20.1 to Mojmap). If/when FFAPI updates to a newer Minecraft version, I will remake the port for that version too.
Thermoo 9.0.0
This update brings Thermoo to Minecraft 1.21.11. Per the LTS policy, this release marks the end of support for Minecraft 1.21.9-10.
- Updated to Minecraft 1.21.11.
- Added new Environment Attributes to control seasons and temperature.
- Reworked the seasons API to better support the environment attribute integration. This is a major breaking change for anyone using the Java-side Seasons API. See below for details. The JSON API should remain exactly the same.
- Added a new
mildtropical season.
Environment Attributes
Thermoo now provides several new environment attributes that integrate this new vanilla system with seasons and temperature. These new attributes are documented on the Thermoo wiki.
Seasons API Rework
The Seasons API has been reworked with, broadly, two major changes to support better future extensibility: First, the
ThermooSeason enum was converted into an interface which is implemented by two separate enums for temperate and
tropical seasons, called TemperateSeason and TropicalSeason respectively. A mild tropical season was also added
with this change to represent transition periods from wet to dry.
Secondly, the type returned by the seasons events was changed from an optional season to an optional season state,
which includes not only the original season but also a new progress value. This captures the "state" of a season at
some particular point in time. The new progress value is a number in the range [0, 1] which represents how far the
season has progressed.
Here is a basic migration overview:
ThermooSeason.SPRING->TemperateSeason.SPRINGThermooSeason.AUTUMN->TemperateSeason.AUTUMNThermooSeason.SUMMER->TemperateSeason.SUMMERThermooSeason.WINTER->TemperateSeason.WINTERThermooSeason.TROPICAL_DRY->TropicalSeason.DRYThermooSeason.TROPICAL_WET->TropicalSeason.WET- Added
TropicalSeason.MILD ThermooSeason#getCurrentSeason(Level)->TemperateSeason#getCurrentState(Level, BlockPos)(note the addedBlockPosparameter)ThermooSeason#getCurrentTropicalSeason(Level, BlockPos)->TropicalSeason#getCurrentState(Level, BlockPos).map()
Examples:
-Optional<ThermooSeason> season = ThermooSeason#getCurrentSeason(level);
+Optional<TemperateSeason> season = TemperateSeason#getCurrentState(level, pos).map(ThermooSeasonState::season);
ThermooSeasonEvents.GET_CURRENT_TROPICAL_SEASON.register(
(level, pos) -> {
- return Optional.of(ThermooSeason.TROPICAL_WET);
+ return Optional.of(TropicalSeason.WET.createState());
}
);
Migration to Mojang Mappings
This is a backport of Thermoo 8.1.0 for Minecraft 1.21.10
Based Mojang's move towards removing obfuscation, and anticipating Fabric's move to MojMap, I have remapped Thermoo to MojMap. This was a big change code-side for Thermoo but, thanks to intermediary, this should not constitute any breaking changes to the public API. However, I may have messed something up, so this version will initially be released as a beta.
While no breaking changes are planned to be made at this time, a few fields and methods have been renamed to better conform to Official Mappings standards. These are as follows:
EnvironmentProvider.ENTRY_CODEC->EnvironmentProvider.HOLDER_CODECLightThresholdLightProvider#lightType->LightThresholdLightProvider#lightLayerAttributeModifierTemperatureEffect$Config#id->AttributeModifierTemperatureEffect$Config#locationScalingAttributeModifierTemperatureEffect$Config#id->ScalingAttributeModifierTemperatureEffect$Config#locationEnvironmentTickContext#world->EnvironmentTickContext#levelTemperatureEffects.STATUS_EFFECT->TemperatureEffects.MOB_EFFECT
The resource location of the temperature effect type thermoo:status_effect was changed to thermoo:mob_effect, however an alias has been added to allow existing datapacks to continue to work.
All old fields and methods have been deprecated and just redirect to the new ones, so there are no breaking changes.
When Minecraft fully moves over to using the unobfuscated jar (the update after Mounts of Mayhem), the old fields will be removed and other names, particularly class names, that could not be easily changed without breaking the public API will also be changed.
Migration to Mojang Mappings
Based Mojang's move towards removing obfuscation, and anticipating Fabric's likely inevitable move to MojMap, I have remapped Thermoo to MojMap. This was a big change code-side for Thermoo but, thanks to intermediary, this should not constitute any breaking changes to the public API. However, I may have messed something up, so this version will initially be released as a beta.
While no breaking changes are planned to be made at this time, a few fields and methods have been renamed to better conform to Official Mappings standards. These are as follows:
EnvironmentProvider.ENTRY_CODEC->EnvironmentProvider.HOLDER_CODECLightThresholdLightProvider#lightType->LightThresholdLightProvider#lightLayerAttributeModifierTemperatureEffect$Config#id->AttributeModifierTemperatureEffect$Config#locationScalingAttributeModifierTemperatureEffect$Config#id->ScalingAttributeModifierTemperatureEffect$Config#locationEnvironmentTickContext#world->EnvironmentTickContext#levelTemperatureEffects.STATUS_EFFECT->TemperatureEffects.MOB_EFFECT
The resource location of the temperature effect type thermoo:status_effect was changed to thermoo:mob_effect, however an alias has been added to allow existing datapacks to continue to work.
All old fields and methods have been deprecated and just redirect to the new ones, so there are no breaking changes.
When Minecraft fully moves over to using the unobfuscated jar (the update after Mounts of Mayhem), the old fields will be removed and other names, particularly class names, that could not be easily changed without breaking the public API will also be changed.
- Updated to run natively on Minecraft 1.21.10, this should still work on 1.21.9.
- Thermoo is now targeting 1.21.9 directly
- Mod metadata now requires at least 1.21.9 to load
Thermoo for MC 1.21.9
- Updated to 1.21.9-rc1, this will likely work with the full release of 1.21.9. Per the LTS policy, this release represents the end of support for 1.21.6-8.
- While there are no breaking changes in Thermoo itself, changes to the
Entity#getWorld()method in Minecraft means this release breaks binary compatibility with 1.21.6-8, so Thermoo is therefore getting a major version bump. - Updated Argentine Spanish translations (thanks Texaliuz!)
