[Compat] LSO default temperature values
sfiomn opened this issue · 93 comments
mod: LegendarySurvivalOverhaul
url: https://www.curseforge.com/minecraft/mc-mods/legendary-survival-overhaul
version: latest
description：
Hello hello,
First thank you for the compatibility already made for LSO !
I'd like to know if it would be possible to have the same default values as LSO ?
https://github.com/sfiomn/LegendarySurvivalOverhaul/blob/d6fd315c4e22a7fe62fe7298c6014f54ce2c8858/src/main/java/sfiomn/legendarysurvivaloverhaul/config/Config.java#L593
I meant as default values.
I'd like player installing both LSO and ecliptic to have the same gameplay feeling with season temperatures
i just wrote
ecliptic season has different season style from serene season. so we shouldn't use the same config. but if the author of LSO has the willing to do it, we can remove the codes written.
now it seems that maybe I should talk to you about my plan, which is just a temporary solution at the moment. If you don't mind, I'll reply to you later.
Yeah no problem
In fact, we're thinking of switching from Serene to Ecliptic for our modpack also
https://www.curseforge.com/minecraft/modpacks/minecraft-legendary-edition
So I'm checking a bit what's configurable and all
Feel free to join our discord if you want more in depth discussions
Regarding LSO, there is actually a new plan: as we refine the climate zone settings, temperature will be provided based on a combination of biome and season. The current thought is to implement this through a data pack.
On the other hand, one key difference is that I want the seasonal temperature changes in Ecliptic Seasons to be relatively mild. Under the default configuration, in plains-type regions, the changes will be gentler compared to the settings used for Serene Seasons.
And I also apologize for using Mixins to achieve this compatibility. There have been many requests for such thing. When I previously left a comment on CurseForge, it seems you didn’t see it lol. Therefore, I had no choice but to go with this approach.
I was responding to issues using my phone, and GitHub Mobile is inevitably a bit inconvenient to use.
I'm glad to hear that there's a possibility of using Ecliptic Seasons. We've been working hard to improve the development of this mod and are committed to continuing its progress, aiming to bring a deeper sense of seasonal immersion.
And I may not be able to check Discord messages for the next few days due to some new work commitments, so I'll have to rely on GitHub for now. (I probably have some other messages waiting, but I don't have the time to handle them promptly at the moment while GitHub would notify me of new issue updates via email.)
Sorry for missing your comment on CurseForge, I'm more active on Discord as it's easier to navigate through older topics there
To add a modifier to LSO, isn't it easier to just register it on the MODIFIERS register instead of using mixins ?
I'm wondering if it wouldn't be easier for the players to centralize all temperature related configs in the LSO common config file though
About the temperature impact of the seasons, LSO is already calculating biome temperature, so the "ecliptic temperature modifier" should just return the season part of it, but you can use futher calculations in your code for snow behavior for example
Also, what you could do, is retrieve the temp calculated by LSO for your temperature behavior. Like checking the block temp to melt the snow around blocks that provide heat for example.
I noticed some limitations in the mechanism, though it might also be due to a misunderstanding or memory lapse. It seemed that only modifiers registered via DeferredRegister MODIFIERS would be applied before. One special case is WeatherModifier — I noticed that LSO calls seasonal calculations there.
Regarding whether it rains or snows, Ecliptic Seasons has a system about Local Biome Weather, so the rain-related checks must be adjusted accordingly. If Solar Weather is not disabled in the configuration, then different biomes will experience different weather.
Regarding the impact of heat on snow-covered blocks, we must have a highly efficient query function; otherwise, chunk update lag is inevitable. Currently, my expectation for the newly added condition is that it should support with a total execution time under 100–200 milliseconds by ten millions of calls.
When it comes to biomes and temperature, some players actually expect that tropical regions will show little to no seasonal variation. While I understand that perspective, I personally feel that if one chooses to live in the tropics and expects minimal change, it somewhat defeats the purpose of adding seasons in the first place.
Lot of topics mentioned, I'll try to cover them all haha
So about the weather checking the season temperature, the reason behind it is because I want to apply the shade modifier only for "hot biomes combined with seasons".
There are 2 type of modifiers registry, the default one that will just take into account all basic parameters, and the dynamic modifier that will react based on the temperature already calculated (for example to adjust the temperature based on resistance).
If you provide a deeper weather system, we can see to adjust the weather already in place
About the tropical seasons, that was a feature implemented in serene seasons that we choose to ignore. Lot of players were confused by the change of temperature due to the tropical seasons. That's the reason why we reimplemented a calendar, and have the config option to ignore tropical seasons on LSO side.
So about what we need for the modpack
We expect from a season mod just to provide an API that will mention what's the current season, having 4 seasons, can be subdivided in 3 (all of that is already covered by ecliptic so that's perfect)
The seasons must be global (not biome related) to avoid player confusion, and adapt block colors accodingly
A plus is what you already do, having crop related growth based on seasons (and biome is a plus as well). For example, a certain crop could only grow in swamps and in spring / summer
Your greenhouse management is great as well
If you have a weather system that enhance the one from Minecraft, that's a plus as well, but we have to be careful that it fits with the current mod we already have that improves the weather visually. Just having an API returning the current weather / weather intensity is great then.
For all the temperature calculation, I think the best would be to centralize it on LSO side (at least for the compat with LSO I mean) as the player experience LSO is giving is quite important (even outside of the modpack). And this experience is expected by the players as well.
If you can tell me why you need temperature on your side, we can adapt each other's code to best fit together.
The performances of ecliptic seaons is really promising to fit our modpack by the way, great job on that !
Actually, there's no real temperature involved — maybe I said something earlier that gave you the wrong impression. I was merely discussing how the temperature blocks cause snow to melt. (Currently, only block IDs can be blacklisted; there’s no extended check system yet — in fact, only one block’s light level is being checked at the moment.)
Ecliptic Seasons doesn't implement actual snowfall (although it can be enabled via config). The snow cover during winter is actually based on some real-time calculations (which have been specifically optimized to avoid affecting rendering). There are two main reasons for using real-time calculations: compatibility with DH’s LOD system and to avoid attaching too much data to a chunk — especially now that the Y-axis height can be very large.Therefore, if new variables or plugin systems are introduced, query performance optimization is very important.
Regarding temperature itself, our general approach is to avoid talking about it. We aim to focus purely on seasons — temperature is overly complex and shouldn't be our range. While biome temperature might occasionally be referenced — for example, in humidity calculations — the main variable affecting humidity is actually the biome’s raindown level. Actually, Ecliptic Seasons also includes a rain gauge and a thermometer. To avoid confusion, both of them are hidden and can only be obtained via commands. The final design only requires players to craft a hygrometer.
As for global seasons, I actually agree that it’s quite necessary. Personally, I’ve been indecisive on this point, since some players may want seasonal variation across different biomes — though I feel it doesn’t add much meaning. That said, in Ecliptic Seasons, it is configurable: simply tag the biome as seasonal and standard seasonal changes to foliage and grass colors will apply. Just remember to override and remove some other conflicting tags using replace, due to Minecraft's poorly prioritized tag system.
Regarding biome-specific weather, it can actually be turned on or off (under Weather → Solar Weather). This setting was created with the expectation that different biomes could have varying precipitation patterns. If enabled, it's best to query using Ecliptic Seasons’ API (or alternatively use level.isRainingAt). If disabled, then the game will follow vanilla behavior.
Oh ok, I thought you wanted some temperature calculation done on your side as well, sorry for the misunderstanding.
What does the solar weather ? If I want a good compat' with you for LSO (even outside the modpack), might want to adapt my weather temperature part to this as well.
For the seasonal biomes, I'll follow the same logic as with serene seasons, having a config option to calculate the temperature season anyway, so that you can still "not apply" the foliage changes but it wouldn't interfere with temperatures
Also, I noticed that the light level of a block can be quite ressource intensive (used it for the block temperature on LSO side), I suggest you a cache system for it, if not already the case
Are you ok that I put the temp compat of seasons on LSO side ?
Such as what we do for serene seasons, it centralize the temperature settings in one place. I'll use your API to check which season we are in, and how far we are to change the season (as you already did I think)
I think implementing seasonal temperature compatibility on the LSO side is a great idea — in fact, we're already struggling with too many compatibility environments, lol. My development environment is a bit overwhelmed and often shows classes from mods I really don't want to see, such as create and touhou little maid (they takes lots of classes with common names).
As for block light level checks, the actual overhead is quite low on our side, since we don’t recalculate it and apply several preconditions. Especially in chunk rendering, it doesn’t load the chunk, so the lookup is even faster than querying a hashmap once.
Regarding another matter — although the config is named solar weather, it's really just a naming combination. It should be understood as Local Biome Weather.
The key feature of this weather system is that biome weather is not synchronized. For example, forest biomes may experience rainy weather more frequently than plains biomes.Therefore, if players don't like rainy weather, they might consider moving to a drier area.
Regarding checking whether it's raining at a specific block position, you can consider using:
EclipticSeasonsApi.getInstance().isRainOrSnowAt(world, pos)
If you want to query for a specific biome area , you can use:
com.teamtea.eclipticseasons.common.core.biome.WeatherManager.isRainingOrSnowAtBiome(Level level, Biome biome)
btw the later is not officially part of the API yet — though I’ll do my best to ensure its method name remains unchanged across version updates.
Regarding seasonal temperature compatibility — once you're ready, please let me know, and I can comment out the related parts on my side to avoid conflicts.
As for block light level checks, the actual overhead is quite low on our side, since we don’t recalculate it and apply several preconditions. Especially in chunk rendering, it doesn’t load the chunk, so the lookup is even faster than querying a hashmap once.
Oh I might take a look how it's done, I do check the sky light level to detect if we're outside or inside a structure, but checking it for a lot of blocks is quite heavy in the end
I see you made custom day time, those it then changes the dawn time and all ?
To know how adapt the temperature time modifier :)
Yes, if it's winter, it will be completely dark in the morning. But if it's summer, it will be very bright.
For now, this part is hardcoded and configurable, but I plan to make it data-driven when I have time later.
The underlying logic is to adjust the return value of this.
level.getTimeOfDay(1f)
then affect the sun angle and other things.
How currently reacts the sun with the custom daytime of solar terms ?
Like the time between midnight and dawn, and sunset and midnight is the same ?
To know if I can just adjust the time modifier by just adjusting the length of the sinusoidale
Like here:
https://github.com/sfiomn/LegendarySurvivalOverhaul/blob/1.20.1/src/main/java/sfiomn/legendarysurvivaloverhaul/common/temperature/TimeModifier.java
float timeTemperature = (float) Math.sin ((time * Math.PI) / 12000.0f) * (float) Config.Baked.timeModifier;
12000 -> custom length day
You can use solarterm.getDayTime() to get the current daytime value.
The time periods are basically symmetrical, except for one day — the day when the solar term changes.
Starting from tick 18000, the daylight length of the next solar term is applied. Otherwise, it would cause inconsistency.
From the player's perspective, if the solar term change does not start exactly at tick 18000, the sun’s position would suddenly jump, even if only by a small amount. Starting the change at tick 18000 ensures a smooth transition.
ok ok, not a big deal as at 18000, the sun is already set
If I understand correctly, days still last 24000 ticks, just you make the sun rise / set earlier or later depending on solarterm.getDayTime() right ?
I added a small method to retrieve the time in version 0.11-pre7. Prepare for data-driven or config.
(24000 - dayTime) / 2 is basically usable, but here there are some modifications. The change might not be linear, so if you want to exactly match the sunrise time, ...
You can try this: for example, the first image shows the sun at 750 ticks during the Beginning of Spring, and the second image shows the sun at 0 ticks during the Spring Equinox. The difference in their daylight duration is 1500 ticks.
(int) (6000 + (dayTime/ 2));
Sunset time can be obtained like this.
Note that dayTime may be greater than 12000, so segmentation is needed if check sunrise time.
getDayTime(level) would be different than level.getLevelData().getDayTime() ?
Ah I was wrong, time = 0 is sunrise in Minecraft, so might be harder to get the sun rise
Once I have the sun rise, guess the sun set is sun rise + dayTime 😊
This version is solely intended to serve as the API version of solarterm.getDayTime to accommodate potential future modifications.
So in your second image, about Spring equinox subseason, what tick is the sunrise ?
Also, if a player tries to use bonemeal on a plant that shouldn't be allowed to grow, do you cancel the use of the bonemeal + display a client message informing this plant can't growduringthis season ?
Ok, I reach this calculation for the time:
public static long getSunRiseTime(Level level) {
SolarTerm solarTerm = EclipticUtil.getNowSolarTerm(level);
return (30000L - (solarTerm.getDayTime() / 2L)) % 24000;
}
long sunRiseTime = EclipticSeasonsUtil.getSunRiseTime(level);
int dayDuration = EclipticSeasonsUtil.getDayDuration(level);
long sunSetTime = sunRiseTime + dayDuration;
if (time > sunRiseTime && time < sunSetTime % 24000) {
timeAngle = (Math.PI / dayDuration) * ((time - sunRiseTime) % 24000);
} else {
timeAngle = -(Math.PI / (24000 - dayDuration)) * ((time - sunSetTime) % 24000);
}
Pretty happy with the result
Might not be 100% natural, but as I want to keep a config specifying the max value of the temperature given at noon, and the one a midnight being its opposite, that's the best I can do
there's actually no strict limitation on the use of bone meal. By default, it's unrestricted, but it can be modified via datapacks and override. the default success rate is 1.0 — meaning 100% success.
If it fails, the only thing the player will notice is that the bone meal has no effect, even though green particles still appear.
Well, I would guess bonemeal success rate should be dependent of the growth speed of a plant
If the growth speed = 0 (not correct season ?), the bonemeal shouldn't have any effect (= not consumed) and a message should probably be send to the player
That's how I would see it at least, what do you think ?
The success rate of bone meal can be configured, and with the default settings, it's relatively easy to progress.
As for the second, if bone meal isn't consumed, there will be no visible reaction from the player's right hand, nor any particle effects. I feel this wouldn't provide a good user experience.
After all, bone meal isn't particularly valuable.
I just made a config option that can be used to toggle this behavior.
Common->Crop->BoneMealConsumeWhenFailure
Wait, the name of the config looks weird
In essence, bonemeal has a success chance, so why wouldn't be consumed when failed ?
My point was just to provide a user feedback when the bonemeal can't be applied to a crop, due to really bad growth conditions (resulting like 0% chance of growth when bone meal is applied)
Like in your image above 😊
Haha yeah, I admit it's a bit weird — just went for matching initials.
have changed it to BoneMealConsumeOnFailure
its true in default
If I understand this correctly :
https://github.com/joe-vettek/Ecliptic-Seasons/blob/forge-1.20.1-opt/src/generated/resources/data/eclipticseasons/eclipticseasons/crop/seasons/autumn.json
If I'm in autumn and a plant should grow in greater cold, it checks:
"greater_cold": {
"grow_chance": 0.0,
"death_chance": 0.0,
"fertile_chance": 1.0
}
-> fertile_chance being the usage of bone meal -> 100% chance of growth using bonemeal (by default)
What will be done for the modpack, is to prevent the use of bonemeals when season not matching (at least the major season, like spring, autumn, etc ...)
So the fertile chance would be 0 (for example, when player in autumn for a winter crop) -> On failure, no consumption of bonemeal + client message to warn the player why the bonemeal use is cancelled (already feasible in your code)
But now, imagine we put 0.5 for the subseasons around the one matching for the crop (for example, a crop growing during heavy_snow, and the player being in light snow)
-> In this case, On Failure, bonemeal is consumed + no client message (just as a normal bonemeal would do, just with less chance of growing)
Ah, I have a small question as well, I see every solstice being followed by a lesser then a greater, isn't it a bit counter-intuitive ?
Like you have winter solstice, then lesser cold, then greater cold
Shouldn't it be colder just after the solstice ?
Same for summer solstice followed by lesser heat then greater heat.
I would have expected the heat to be stronger after the solstice
Regarding the first issue, you can go ahead and set it up that way. I think your idea is great — in fact, I had considered this before but haven't implemented it yet. Maybe I should add an additional setting: to suppress the warning message when bonemeal isn't absolutely ineffective.
It won't affect the current JSON structure.
Regarding the second question, I think it might help to take a look at this (please also note the issue of how the terms are translated — of course, the order itself won’t be changed):
https://www.chinahighlights.com/festivals/the-24-solar-terms.htm
A long time ago, I planned to write a dedicated page to explain these things, but I ended up forgetting about it.
This is because these are actually terms from a traditional calendar system. Also, as for why “Cold” doesn’t come before the Winter Solstice — that’s because the solstice itself is based on astronomy, whereas the coldest period doesn’t come right after it. It actually arrives just before the thaw, not when it starts snowing.
Solar terms are really fascinating. In terms of seasons, their peak often comes near the end, while the beginning of a season marks a transition.
This might be conceptually different from Serene Seasons.
As the old saying goes: “When things reach an extreme, they begin to reverse.”
About an option to suppress the warning if chance > 0, that might not be completely the solution, because as chance = 0 means no consumption, chance > 0 should consume, even on failure
I think the best here would just be to remove the different config, and just hard code :
If chance = 0 -> no consumption + warning to explain why
As soon as chance > 0 -> consume as normal
In fact, in general, the fertile chance should be proportional to growth chance, so that when you check with your item, the growth factor, player wil have a hint about how effective bonemeal will be
If I may suggest a refactor of the bone meal usage, I would follow a simpler concept :
Basically, the bonemeal would just be able to instantly trigger the growth chance upon use on a plant (so that player won't have to wait the next growth tick to check wether the plant will grow or not)
That would follow the original Minecraft design of the bonemeal, so players won't be confused
If you want a config to be able to follow the current behaviour you have, I would just add "AreBonemealAlwaysEffective"
To check whether the bonemeal care or not about the growth chance to make the plant grow
I'm not sure if a lot of players have already customise the fertile chance and all, but I've the feeling this might just be too much to configure in the end
Also, thanks a lot for the solar terms explanation, I'll adapt the default LSO temperature then 😊
Duplicating values can be handled with a small script, so that’s not really a big issue. However, I still think fertile_chance is worth keeping — mainly to reduce difficulty, so that players who try to play the mod on its own rather than in a modpack don’t struggle to get enough food. In fact, I’ve already received quite a bit of feedback about this.
A common situation is that the default settings are now adjusted to the Spring Equinox, so players quickly enter summer. However, in plains biomes, the default humidity for summer is usually dry, which significantly reduces the growth rate of crops. If they don’t build a greenhouse, obtaining crops will become a hassle.
About the second, perhaps we could use some default values instead of removing the options entirely. It's worth mentioning that these three values can all be omitted, so there's no need to write them explicitly. The question is just about which approach to take — whether to add a new config to force all growth to use growth_chance, or to fall back to growth_chance when the values are omitted in the JSON.
Also, when using a bonemeal, it calls "int getBonemealAgeIncrease() " (within CropBlock class definition)
And this getBonemealAgeIncrease() uses by default a randomInt(0, 1) (can be overload by crops to increase the randomness)
Meaning that even if the bonemeal is applied, the crop growth isn't assured
Is the fertile chance a new layer of randomness above the bonemeal randomness ?
Or maybe you completely cancel the bone meal event upon firing, and manage yourself the growth of the crop based on fertile chance ?
I initially thought about the second option, but I prefer asking to be sure, as the CropGrowthHandler of Ecliptic is quite big :)
The added value of keeping the default behavior of the bonemeal, is that each dev introducing crops have already defined how efficient bonemeal is for each crop
So in the end, seasons would just define whether the bonemeal can be applied or not
in 1.20.1 and 1.21.1
the code of mojang is
protected int getBonemealAgeIncrease(Level pLevel) {
return Mth.nextInt(pLevel.random, 2, 5);
}
The bone meal behavior here is actually based on Forge's event system — you can take a look at Forge’s patch code. Within this framework, if we aim for minimal modification, there are three possible outcomes: normal use, bone meal is consumed but has no effect, or bone meal may be consumed but has no effect. Our current implementation follows this logic. All of this is handled purely through Forge’s event system.
So in that sense, yes — we only add a seasonal and humidity filter on top of the vanilla behavior, rather than replacing it entirely.
That's crazy how hard it seems to understand each other haha
Let's try with an example
Let's imagine we have a wheat, with config:
beginning of spring: {
growth chance 1, fertile chance 1
}
rain water: {
growth chance 0.5, fertile chance 0.5
}
insect awakening: {
growth chance 0, fertile chance 0
}
The wheat has "getBonemealincrease()" overload with "return (int) (randomInt(0, 3) / 3.0)" -> 1/3 chance to increase of 1
Does it work like this when I apply bonemeal on wheat ?
If we are in rain water
-> fertile chance 0.5 -> success -> bonemeal consumed -> bonemealIncrease chance 0.3 -> success -> crop increase of 1
-> fertile chance 0.5 -> success -> bonemeal consumed -> bonemealIncrease chance 0.3 -> failure -> crop don't increase
-> fertile chance 0.5 -> failure -> bonemeal consumed
If we are in insect awakening
-> fertile chance 0.0 -> failure (obvio) -> bonemeal not consumed + client message
If it works like this, then I'm not a fan of the fertile chance (because of the randomness still rolling behind it)
But that's not a big deal, we'll just stick with fertile chance being either 0 or 1 then
I'll just need to be able to have this behavior :
-> fertile chance 1.0 -> success -> bonemeal consumed -> bonemealIncrease chance 0.3 -> success -> crop increase of 1
-> fertile chance 0.0 -> failure (obvio) -> bonemeal not consumed + client message
Actually, you can already achieve the behavior you want just by using an override data pack with higher priority to replace the mod-provided one.
Also, as of now, the getBonemealAgeIncrease() method almost always guarantees success—the main difference lies in how much the crop grows.
I'm not quite sure which version of the code you were looking at, but from what I see, it doesn’t usually return zero growth.
If fertile_chance = 0, the bone meal use is blocked entirely: consumption, and a warning is shown.
If fertile_chance = 1, use the default crop logic (like getBonemealAgeIncrease()) takes over.
And with your latest change:
If fertile_chance = 0, the bone meal use is blocked entirely: no consumption, and a warning is shown.
Is possible right ?
Yes, just set Common -> Crop -> BoneMealConsumeOnFailure to false.
By default, it is set to consume bone meal on failure.
Ah indeed, the default is from 2 to 5, just the beetroot for example, do /3, so there is a slight chance to not grow anyway
Considering the behavior for the beetroot, I think it's expected from getBonemealIncrease() to be a random value that can also make the bonemeal fail to increase the crop
That depends on how other developers design their crops — Mojang doesn’t provide JavaDocs for reference.
Besides, the effect of bonemeal isn’t limited to CropBlock only. I don’t think it really matters that much.
As for compatibility, the best approach is not to interfere with downstream behavior. Otherwise, it would require a large number of Mixins.
Nowadays, even the Forge conventions aren’t reliable anymore, since connector mods and cross-platform mods have emerged — they mostly only care about whether things run or not.
Starting this week, I'll be a bit busy and might not be able to reply promptly, especially when it comes to code-related details.
Oh, I just realized I missed your message earlier.
Anyway, the probabilities — 0 or 1 — can be configured directly in the JSON. You can simply override the file.
If you want to make bonemeal non-consumable on failure, just set BoneMealConsumeOnFailure to false in the config — that will prevent it from being consumed.
The warning message is enabled by default; there's no need to explicitly set it to true.
Ok, my verison with ecliptic season compat' is uploaded on github:
https://github.com/sfiomn/LegendarySurvivalOverhaul/tree/1.20.1
version 2.3.13
Will be on curseforge later, but you can already make a version check >=2.3.13 when you'll remove the compat' on your side
And I'll do the same once I'll know which version on your side will remove the compat'
Yeah no problem, your settings are enough for the behavior we want to have
Sorry for my suggestions earlier, I'll let you deal with your mod
Let me know the ecliptic seasons mod version you'll have the LSO compat' removed, I'll add it in the mods.toml, otherwise each compat' will stack up their temperature
I just uploaded version 0.11.0-pre8, which should be the starting point.
Because there is still an issue with the custom multipart model's render type setting, I haven't released the 0.11 version yet. The main goal of this version is to expand the customization scope.
However, I'm a bit confused about the LSO version number. I thought it was 2.3.13, but looking at the latest jar file, it shows 1.20.1-1.20.1-2.3.11.3.
It starts from [0.11.0-pre8,), but that version carries an incorrect version number requirement for LSO. Perhaps we can start from 0.11.0-z instead.
I'll update the version number on my side to be 1.20.1-2.3.13
The new version will be uploaded today, it's under testing before its upload on CF
i'll put 0.11.0-z as pre-requisite then
Okay, I have also updated the new requirements to prevent players from using the wrong version.
However, this issue seems a bit too long.
I think we can close it for now and continue the discussion if any new case arise.
Someone told me that there is currently an issue with wetness in LSO. After checking, the reason seems to be that the latest version of LSO uses EclipticSeasonsApi.getInstance().getPrecipitationAt to get the biome's precipitation.
However, there is a small problem: the function WorldUtil.getPrecipitationAt appears to return the actual precipitation at the current moment, while getPrecipitationAt is actually designed for stable calculation — meaning if it’s possibly raining during that period, it will keep returning rain.
Therefore, in the old API situation, it is necessary to use EclipticSeasonsApi.getInstance().getPrecipitationAt together with isRainingOrSnowing.
To speed up computation, I added getCurrentPrecipitationAt in version 0.11.2.1.1 to obtain the real-time precipitation.
Just to be sure getCurrentPrecipitationAt() actually does check whether it's raining or not then ?
While getPrecipitationAt() just return whether it should rain or snow based on temperature ?
yes, getCurrentPrecipitationAt would check the current.
if it rains, return RAIN/SNOW. if not return NONE
getPrecipitationAt only checks whether the biome is in a cold period. it would not check if it rains.
Hello hello,
Is there a method to return whether it's raining or not, but not for a specific position (under a tree for example), just in general, in the current biome ?
Equivalent to level.isRaining()
@sfiomn Sorry, I've been quite busy lately, so I only checked the open issues. This problem can be solved by using the method isRainingOrSnowing method.
If you only want to provide the biome, please be aware of biome transition issues—especially with rivers, which are split between the biomes on both sides.
This is why the API does not directly provide a method that only takes the biome as a parameter.
if (EclipticSeasonsApi.getInstance().hasLocalWeather(level))
return EclipticUtil.getRainOrSnow(level, biome, pos) != Biome.Precipitation.NONE;
return level.isRaining();
Hello hello joe,
Just a small question, why when doing the command /time add 24000t, it doesn't increment the day within the solar term from EclipticSeasonsApi.getInstance().getTimeInTerm(level) by one ?
It doesn't affect the LSO compat' anyway, as I'm totally relying on data from ecliptic, it was more out of the curiosity.
I had the impression that adding 24000 * 7 ticks on time increased the day within solar term by 1
public void updateTicks(ServerLevel world) {
solarTermsTicks++;
int dayTime = Math.toIntExact(world.getDayTime() % 24000);
if (solarTermsTicks > dayTime + 100) {
setSolarTermsDay((getSolarTermsDay() + 1));
sendAndUpdate(world);
}
solarTermsTicks = dayTime;
}This mod has its own independent day counter. It tries to line up with Minecraft's day count, but it’s not exactly the same.
The idea is to decouple Minecraft days from our internal days, so you could have something like Minecraft day 0 displayed as year 998.
This logic has been around since before the mod, and it generally works fine.
If you want, you can also advance the day manually with vanilla commands:
/time add 20000
or with our mod command:
/ecliptic solar add 1
Hello hello, back again with a small question :)
I was wondering if there was a way to disable by default the heat stroke effect of Ecliptic ?
I fear a bit the confusion between the heat stroke effect from LSO
Also, what's the impact of the Ecliptic heat stroke effect ?
Actually, this is just a simple visual blur effect, since in our original design we didn’t intend for it to have any major impact on gameplay.
I think you can either call the API to set it to False, or disable it in the modpack files.
Hello hello
Which method in your API allows the deactivation of the heat stroke effect on Ecliptic Seasons side ?