Tags
Creators
Details
All versions
1.8.0
Release
Lucent v1.8.0last week 48
Compatibility
Minecraft: Java Edition
26.1.2
Platform
NeoForge
Supported environments
Client-side
Changes
26.1.2-v1.8.0
General Updates
- Improved performance with dynamic lighting
- Added a config screen
- Fixed dynamic lighting not working with Sodium
- Light interpolation does not work, and a one-time warning will pop up if Sodium is installed
LightLevelProvider
- Heavily refactored to remove generic typing and improve class structuring
getLightLevel(RegistryAccess, T)has been refactored togetLightLevel(Level, BlockPos, Object)Objectcan be safely cast to the required class if needed usingLightLevelProvider.Source.ITEM_STACK,LightLevelProvider.Source.ENTITY,LightLevelProvider.Source.DATA_COMPONENT_GETTER. Source validation is done during registry
- Some providers have been updated or renamed. The naming convention is as follows: light level providers that should take a value from the object in question, and then determine a light value from it through some calculation, should be prefixed with
map_. This signifies that the actual value on the object is in use. All other light level providers will simply return a value.if_nbt->nbt- No longer saves NBT as a String. Instead saved as a tag in the json.
- Now has a
required_componentslist. Only saves NBT to get the light level if all required data components are present.
match_nbt->map_nbt- Combined other
match_nbtsubtypes into this - Has a
source_typefield, accepting the following:number: Uses the number value directly (default)item: Obtains the item's default dynamic lightingblock: Obtains the block's light levelfluid: Obtains the fluid's light levelentity: Obtains the entity's default dynamic lighting
- Now has a
required_componentslist. Only saves NBT to get the light level if all required data components are present.
- Combined other
match_nbt_item-> Removedmatch_nbt_block-> Removedmatch_nbt_fluid-> Removedmatch_block->blockmatch_enchantment->map_enchantmentmatch_armor_trim->armor_trim- May now optionally include the trim pattern as
trim_pattern
- May now optionally include the trim pattern as
- New Providers
map_block_state- Takes the block state item component and extracts a light level from it. Data is entered as a map of property names and light levels
data_component- Uses the supplied
predicateto match the data components on the item or entity
- Uses the supplied
- Dynamic lighting can now be registered to tags of items and entities
- Formatted as
"id": "#c:rods/blaze"
- Formatted as
Emissive Textures
- Removed block emissive textures
- Emissive armor trim materials may now be defined with tags
Mod Support
- Added support for the following:
- Curios
- Trinkets Updated
- Artifacts
- Aether II
- Aether
- Aether Treasure Reforging
- Glacidus
Backend Changes
- The dynamic lighting engine is now ran per world
- This should enable for easier compat with mods like Immersive Portals
- The dynamic lighting engine no longer runs in its own thread in a super hacky way
- It instead runs during client level tick as a background task
- If calculations could not be finished in time for the tick to end, it will wait for the next tick to apply them
- Added
RegistryAccessto the various plugin registry methods, passed into the variousXRegistryclasses
LucentHooks -> LucentApi
- Updated methods to work with the new backend
LucentCapability
- Contains various
AttachmentTypesaccessed from ClientLevel that can be used to obtain dynamic lighting. - These attachments contain generic java functions that can be accessed regardless of if Lucent is in your development workspace.
Plugin Refactor
registerArmorTrimTextureLightings(ArmorTrimLightingRegistry)->registerArmorTrimEmissivity(ArmorTrimEmissivityRegistry)- The
@LucentPluginannotation is now responsible for storing run priority and the owner mod ID- The owner mod ID still has a method for the purpose of internal helper methods
- The motivation for this change was primarily for internal reasons, however it allows for a plugin class to be validated without initializing the class
Old Format
@LucentPlugin
public final class LavaMonsterPlugin implements ILucentPlugin
{
@Override
public String ownerModID()
{
return "lava_monster";
}
}
New Format
@LucentPlugin(modid = LavaMonsterPlugin.MODID)
public final class LavaMonsterPlugin implements ILucentPlugin
{
static final String MODID = "lava_monster";
@Override
public String modid()
{
return MODID;
}
}
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:JE0fgMUp:gNPedmmx"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:JE0fgMUp:gNPedmmx"
}

