Nether & End Biome Sky/Fog Colours #3342
No reviewers
Labels
No Label
#P1 CRITICAL
#P2: HIGH
#P3: elevated
#P4 priority: medium
#P6: low
#Review
annoying
API
bug
code quality
combat
commands
compatibility
configurability
contribution inside
controls
core feature
creative mode
delayed for engine release
documentation
duplicate
enhancement
environment
feature request
gameplay
graphics
ground content conflict
GUI/HUD
help wanted
incomplete feature
invalid / won't fix
items
looking for contributor
mapgen
meta
mineclone2+
Minecraft >= 1.13
Minecraft >= 1.17
missing feature
mobile
mobs
mod support
model needed
multiplayer
Needs adoption
needs discussion
needs engine change
needs more information
needs research
nodes
non-mob entities
performance
player
possible close
redstone
release notes
schematics
Skyblock
sounds
Testing / Retest
tools
translation
unconfirmed
mcl5
mcla
Media missing
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: VoxeLibre/VoxeLibre#3342
Loading…
Reference in New Issue
No description provided.
Delete Branch "biome_skycolor_otherworlds"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This pull request finally allows for the Nether & the End to have biome specific sky colours and/or fog colours.
Previously, it was only the overworld biomes that had this feature fully implemented.
The code looks like an improvement, but after testing, I'm not sure if I can see any difference. I'm not too good with look and feel changes. Does this change anything?
Well, all it does is make the biomes in the Nether & the End use the sky colours and fog colours system that the overworld currently uses.
The biomes in the Nether & End already had sky and/or fog colours, but they weren't given via the biome sky and/or fog colour API. Now they are.
Ok, thanks for explaining. The code is an improvement, so that's a good thing. I've tested it and I have not seen any issues. I usually prefer to see changes that add to the gameplay/look and feel in PR's. "Code quality" changes on their own just feel like creating risk without the benefit to users to justify it. I don't usually refactor code unless I'm going to add something extra in the area and it justifies it to do it at that point (ideally in separate commits, of course).
Hopefully, you have something in mind.