V2 - #25
Open
Giovanniricotta2002 wants to merge 124 commits into
Open
Conversation
…and IRadiationSource interface
Implement radiation items and effects, including RadiationItem class …
V2 advancement
…, and configuration options
V2 fluids radiation
V2 liquid input
…or triggering the alarm
Add reactor alarm block and sound mechanics, including advancements f…
…on capability wiring - Bump Create to 6.0.10-280, Ponder to 1.0.82, Flywheel to 1.0.6, Registrate to MC1.21-1.3.0+67, NeoForge to 21.1.247, JEI to 19.43.0.390, and Jade to 7545219 - Disable Gradle configuration cache and add a client2 run configuration for local multiplayer testing - Convert SimpleMultiBlockPattern to a record and drop the dead matches(java.util.logging.Level, ...) override and unused test() helper - Remove the unused multiblock manager/cache classes (SimpleMultiBlockPatternBuilder, IBetterPattern, MultiBlockCache, MultiBlockManager, RegisteredMultiBlockPattern) - Rename MultiBlockOffsetPos#caracter to #character and update all call sites - Replace the unchecked Object cast in IodineEffect with a properly typed Attribute holder for CNAttributes.IRRADIATED_RESISTANCE - Clean up fully-qualified references in CreateNuclear.java and PersistentFluidLocks.java in favor of imports - Remove the enriching campfire block tag registration and its reactor casing sound events/subtitles (break, fall, hit, place, step) that are no longer used - Add enriched_soul_soil to the enriching_fire_base_blocks tag and register enriching_fire/enriching_campfire as fan processing catalysts - Add EnrichedRecipeGen skeleton under the new net.nuclearteam.createnuclear.api.data.recipe package, mirroring the existing foundation.data.recipe.EnrichedRecipeGen ahead of an API extraction - Refresh generated datagen resources (lang files, sounds, block tags, datagen cache) to match the above changes
…exture handling for radiation effects
…turing Remove the 48 per-color model, recipe, and advancement JSON files for anti-radiation armor pieces, replacing them with a single default model per armor slot (boots/chestplate/helmet/leggings) plus a colored/ variant folder. Introduce AntiRadiationArmorTextureMixin to resolve the correct texture/color at render time instead of relying on baked per-dye assets, and add ClothTagHelper and CNBuilderTransformers to support the new tag-driven dye/cloth lookup. Update CNItems, CNTags, CNDataComponents, CNEntityType, AntiRadiationArmorItem/ClientExtensions, ClothItem, RadiationEffect, and related registries to wire up the new structure, and drop the now-unused default_anti_radiation_suit.png texture and obsolete dye tag files (anti_radiation_*_dye.json, all_anti_radiation_armors.json).
Re-enable the previously commented-out SmithingClothRecipeBuilder calls
in CNItems for helmet, chestplate, leggings, and boots, generating a
smithing recipe per cloth color (skipping Cloths.DEFAULT) that applies
a colored cloth to the base armor piece. Back this with a new
SmithingTransformRecipeMixin (registered in
createnuclear.neoforge.mixins.json) and SmithingClothRecipeBuilder API
class, and regenerate the resulting smithing recipe/advancement JSON
under src/generated/resources/data/createnuclear/{recipe,advancement}/smithing/.
Change CNDataComponents' CLOTH_ITEM component from a raw ItemStack to a
new ClothItemStack wrapper record that implements content-based
equals/hashCode (via ItemStack.isSameItemSameComponents/
hashItemAndComponents), since NeoForge requires data component values
to implement proper value equality. Update ClothTagHelper and
CNBuilderTransformers accordingly, and refresh the colored anti-radiation
armor model JSONs to match. Minor unrelated fix to gradlew.bat.
…rControllerBlockEntity Purely cosmetic whitespace cleanup, no behavior change. - Fix the displayState field declaration's indentation (3 spaces → 4 spaces, matching the rest of the class) - Remove a stray blank line between getConfiguredPatternCoolerRodCount() and getConfiguredPatternFuelRodCount()
…doc after RodType alignment Small trailing cleanups now that RodType has been aligned with the Forge implementation (see prior "refactor(rod-type)" commits), plus re-enabling alarm-entity validation logic that had been left commented out, and refreshing PORTAGE_REACTEUR.md to mark several previously-blocking API divergences as already resolved. - RodType: drop unused imports left over from the HolderSet→Holder migration (HolderSet, RegistryCodecs, NeoForgeRegistries, CNTags.CNItemTags, CNRodTypes) - ReactorControllerInventory: simplify isItemValid() from a switch with a `default -> !super.isItemValid(...)` branch to a direct `slot == 0 && resource.is(CNItems.REACTOR_BLUEPRINT.get())` check — slot 0 is the only valid slot, so the switch's default branch was unreachable dead logic - ReactorAlarmManager: uncomment and re-enable the ReactorAlarmEntity-based pruning in the stale-position cleanup and the loaded/valid-position filtering, restoring actual validation instead of leaving `positions`/`validPositions` unfiltered - PORTAGE_REACTEUR.md: update the Forge→NeoForge reactor port tracking doc — mark the previously blocking API divergences (RodType shape, IHeat.HeatLevel reactor-size awareness, CReactorHeat config, CRods completeness) as resolved as of the batch-0 port work, with side-by-side verification notes dated 2026-08-14
…er.properties timestamp Refresh the reactor port tracking doc's gametest count from the original 29 to the current 31 (regression tests for zero-heat serialization and empty-slot pattern persistence/network sync were added since, per Lot 2bis/9), and record run/server.properties' auto-updated last-modified timestamp from a local dev server run. - PORTAGE_REACTEUR.md: bump the reported `./gradlew runGameTestServer` pass count from 29 to 31 in the summary header, Lot 8, and §9.5; add a 2026-08-14 note explaining the count moved from 29 (after two bug-contract marker tests were removed) to 31 (after new regression tests were added), so the change reads as expanded coverage, not a regression - run/server.properties: update the auto-generated header timestamp comment from "Fri Aug 07 17:41:43 CEST 2026" to "Fri Aug 14 21:51:07 CEST 2026" (written by Minecraft on local server start)
…set rods An audit of content/multiblock/controller (documented in PARITE_FORGE_NEOFORGE.md §7/§8) traced RodType.ratio() usage up to its Builder and found ratio defaulted to null instead of the constant-1 supplier the class's own Javadoc promises. build() passes ratio through unchanged, so any RodType built without an explicit .ratio(...) call throws an NPE the first time ReactorHeatUpdateCoordinator calls rodType.ratio().get() during heat balance calculation. Currently latent (all three real Builder usages in CNItems set ratio explicitly), but a live trap for the next rod added without it. - RodType.Builder: default the `ratio` field to `() -> 1` instead of `null`, matching build()'s existing Javadoc claim that ratio is exempt from the required-fields check because it defaults to a constant 1 - CNCrushingRecipeGen: remove trailing blank lines at the end of the class body - Add src/main/resources/META-INF/icon.png: the mod's icon, previously present on Forge but missing on NeoForge (flagged in PARITE_FORGE_NEOFORGE.md as the mods-screen showing no icon since neoforge.mods.toml references a nonexistent logo.png) - PARITE_FORGE_NEOFORGE.md: refresh the Forge/NeoForge parity audit for 2026-08-14 — mark the Alex's Caves compat and client mixins as ported, mark SnowPowderRecipeGen's package divergence as resolved, add a new §7 line-by-line audit of content/multiblock/controller (41/41 files paired, 21 diverging but all either 1.21 API adaptation or cosmetic, one pre-existing dead-code note on ReactorControllerBlock's unused setValue(ASSEMBLED, false) call), document the RodType.ratio() bug found during that audit (fixed by this commit) as well as the still-open ReactorGaugeOverrides/ IrradiatedWoldCollarLayer orphan files, the disabled CNShapelessRecipeGen provider, and the worsening `create`-namespace recipe leak in CNCrushingRecipeGen/CNWashingRecipeGen; renumber the "verify project state" section from §7 to §8 and update its expected file counts
…tale icon.png claim Follow-up pass on PARITE_FORGE_NEOFORGE.md after the previous commit fixed RodType.Builder.ratio's null default: reconcile the file/ resource counts, fold §8 into §7 (a numbering slip from the last edit), and correct an inaccurate claim about the mod's icon that a fresh check disproved. - Update the top-of-file file/resource counts (302→301 .java files, 1119→1120 resources) to match the current tree - §7.3: replace the detailed bug write-up for RodType.Builder.ratio's null default with a short "fixed" note pointing at commit `970503b`, since the previous commit already applied the suggested fix (`private Supplier<Integer> ratio = () -> 1;`) - Renumber the controller-audit subsections from §8.1–§8.4 to §7.1–§7.4, correcting a heading-numbering mistake from the prior edit (the section itself is titled "## 7. Audit ciblé...") - Correct the mod-icon note: `src/main/resources/META-INF/icon.png` does exist on NeoForge (added in the previous commit) — the earlier claim that it was missing was wrong. Only `logo.png` (referenced by `logoFile` in neoforge.mods.toml) remains genuinely absent; flag that `logoFile` may just need to point at `icon.png` instead - Note that `content/multiblock/frame/ReactorGaugeOverrides.java` (previously flagged as an orphaned file) has been removed from the codebase; remove it from the orphan-files table and the priority work list accordingly, updating the remaining IrradiatedWoldCollarLayer/logo.png work-list entries to reflect the one-less-file scope - Update the §8 "verify project state" comment's expected orphan-file count from 15 (4+2+9) to 11 (3+3+5), matching the earlier §0 revision
Port reactor logic from Forge branch with enhancements and fixes
… into the create namespace
Create's ProcessingRecipeGen#create(Supplier<ItemLike>, ...) overload
defaults to Create's own namespace in 1.21, not the calling
generator's. CNCrushingRecipeGen and CNWashingRecipeGen relied on
that overload, so their generated JSON landed under
data/create/recipe/... instead of data/createnuclear/recipe/...,
silently overwriting Create's own recipes wherever the ids collided
(crushing/raw_copper, crushing/raw_zinc,
crushing/raw_uranium_block, splashing/crushed_raw_lead). Override the
single-ingredient create(...) method in both generators to force
CreateNuclear.MOD_ID as the namespace, and regenerate the affected
recipe JSON under the correct namespace. Also delete the unused
CNShapelessRecipeGen generator and fix the mod's logo reference.
- CNCrushingRecipeGen / CNWashingRecipeGen: override
create(Supplier<ItemLike>, UnaryOperator<...>) to delegate to
create(CreateNuclear.MOD_ID, singleIngredient, transform), pinning
every recipe generated through the single-ingredient convenience
overload to the createnuclear namespace
- Move the crushing recipes for granite, raw_copper, raw_thorium,
raw_thorium_block, raw_uranium_block, raw_zinc, and the splashing
recipe for crushed_raw_lead from
src/generated/resources/data/create/recipe/ to
src/generated/resources/data/createnuclear/recipe/, matching the
fixed namespace
- Delete foundation/data/recipe/CNShapelessRecipeGen.java (504 lines):
its registration in CreateNuclearDatagen was already commented out,
so its shapeless recipes (including cloth items) were never
produced; remove the dead generator along with the now-unused
CreateMechanicalCraftingRecipeGen/CreateRecipeProvider imports it
required in CreateNuclearDatagen
- neoforge.mods.toml: point `logoFile` at the mod's actual icon
(`icon.png`) instead of the nonexistent `logo.png`; quote the
`[[dependencies.${mod_id}]]` table headers as
`[[dependencies."${mod_id}"]]` (TOML requires quoting a key that
isn't a bare identifier once it contains variable substitution
syntax); add blank lines between TOML sections for readability
…E_FORGE_NEOFORGE.md Follow-up documentation pass after the previous commit fixed CNCrushingRecipeGen/CNWashingRecipeGen leaking recipes into Create's namespace: update the tracking doc's status line and replace the "still broken, getting worse" warning in §3.1 with a resolved note explaining the fix, then remove the item from the priority work list. - Update the top-of-file status line: date 14→15 August 2026, branch V2-Reacteur→V2, and add the namespace-leak fix to the list of work already landed - §3.1: replace the⚠️ warning about CNCrushingRecipeGen/ CNWashingRecipeGen leaking recipes into data/create/recipe/ with a ✅ resolved note pointing at commit `93975b3` — explain the root cause (Create's 2-arg `create(Supplier<ItemLike>, ...)` overload hardcodes `Create.ID` rather than the calling generator's namespace), the fix applied (overriding that single overload per generator to delegate to the 3-arg `create(CreateNuclear.MOD_ID, ...)` form), and verification performed (regenerated datagen output, plus an audit confirming the other 10 recipe generators in the project don't share the bug); note CNStandardRecipeGen.createSpecial()'s unrelated Create.asResource(...) hardcode as dead code with no in-game impact, found in passing during that audit - §5 (chantier priority table): remove the now-resolved "namespace create des recettes crushing/washing" row, renumber the remaining four rows, and add a note that this item was resolved by commit `93975b3` and dropped from the list
…provider registration neoforge.mods.toml's `logoFile` is resolved by NeoForge relative to the jar root (alongside assets/, data/), not relative to META-INF/ where the toml itself lives — so pointing logoFile at "icon.png" while the image sat in src/main/resources/META-INF/icon.png left it unresolvable at runtime despite existing in the repo. Move the icon to the resources root to match the NeoForge/Forge MDK convention, and drop a leftover commented-out provider registration line documented as already resolved (the CNShapelessRecipeGen generator itself was deleted in a prior commit). - Move src/main/resources/META-INF/icon.png to src/main/resources/icon.png so `logoFile = "icon.png"` in neoforge.mods.toml actually resolves - CreateNuclearDatagen: remove the stray commented-out `generator.addProvider(event.includeServer(), new CNShapelessRecipeGen(...))` line — the referenced class no longer exists after its removal in commit `93975b3` - PARITE_FORGE_NEOFORGE.md: document the actual root cause of the logoFile resolution failure (relative to jar root, not to META-INF/) and its fix; mark CNShapelessRecipeGen as deleted rather than reconnected (it was dead code from the start, so no shapeless recipes were lost); remove both items from the §2.2 orphan-file table and the §5 priority work list, replacing them with ✅ resolved notes
…put pitfall Follow-up to the previous commit that moved icon.png to the resources root: mark the logoFile fix as verified working, and record an unrelated IDE gotcha discovered while confirming it, so it doesn't get rediscovered from scratch later. - PARITE_FORGE_NEOFORGE.md §2.2: change the logoFile note from⚠️ "still broken" to ✅ "fixed", keeping the same root-cause explanation (NeoForge resolves logoFile relative to the jar root, not to META-INF/) - Add a note that IntelliJ's `bin/main` compilation output (distinct from Gradle's `build/`) can serve a stale copy of neoforge.mods.toml/resources if the run configuration loads that output instead of `build/resources/main`, and that a full Rebuild Project (or switching IntelliJ's "Build and run using" setting to Gradle) is needed for resource changes to actually show up in-game — flagged as unrelated to the Forge/NeoForge port itself, kept here for future "the file is right but nothing changed" debugging
…ag, and extract shared AnimalUtil helpers Add a fourth irradiated animal (cow, alongside cat/chicken/wolf), following the same registration pattern in CNEntityType, and pull the food-check logic shared with the other irradiated animals into a new AnimalUtil class. Also rename the anti-radiation helmet detection tag from a dye-specific name to a general one, since HelmetOverlay only needs to know "is this an anti-radiation helmet", not "is it fully dyed". - Add content/contraptions/irradiated/cow/IrradiatedCow(.java), IrradiatedCowModel, IrradiatedCowRenderer: a new tameable-in-future irradiated cow entity (milk bucket interaction, breeding, cow ambient/hurt/death/step sounds, fed via CNItems.YELLOWCAKE) - Add content/contraptions/irradiated/AnimalUtil: extracts isFood(ItemStack, Ingredient[, Predicate<ItemStack>]) (yellowcake always counts as food, plus the animal's own food ingredient/extra test) and blockTamingWip(Player, Level) (sends a "taming is WIP" chat message and consumes the interaction) for reuse across irradiated animals - CNEntityType: register IRRADIATED_COW (CREATURE category, 0.6x0.85 hitbox, IRRADIATED_IMMUNE tag, IrradiatedCowRenderer, custom attributes) and its model layer via CNModelLayers.IRRADIATED_COW; fix indentation on IRRADIATED_CAT/IRRADIATED_WOLF field declarations and the registerModelLayer() body (inconsistent 3-space indent) - CNModelLayers: add the IRRADIATED_COW model layer registration - Add generated loot table data/createnuclear/loot_table/entities/irradiated_cow.json and add createnuclear:irradiated_cow to the generated irradiated_immune entity_type tag - CNTags: rename the ANTI_RADIATION_HELMET_FULL_DYE item tag to ANTI_RADIATION_HELMET - CNItems: tag the anti-radiation helmet item with the renamed CNItemTags.ANTI_RADIATION_HELMET.tag (in addition to ANTI_RADIATION_ARMOR.tag and the forge armors/helmets tag) - HelmetOverlay: check the renamed CNItemTags.ANTI_RADIATION_HELMET.tag instead of the removed ANTI_RADIATION_HELMET_FULL_DYE.tag when deciding whether to hide the vanilla helmet overlay - Replace the generated data/createnuclear/tags/item/anti_radiation_helmet_full_dye.json with anti_radiation_helmet.json, matching the tag rename - Regenerate en_us.json/en_ud.json language files with the new "Irradiated Cow" entry
…and fix a stale particle path The anti-radiation armor item models referenced their texture under item/, but that path isn't stitched into an atlas the item-model renderer looks up at that texture id, so the armor pieces likely rendered with a missing-texture fallback. Register a models/armor/ directory source in the blocks atlas and repoint the four armor item models at it. Also fix the fluid input's vertical block model, whose particle texture pointed at a nonexistent block/reactor/input/input path instead of the actual block/reactor/fluid_input/input texture. - assets/minecraft/atlases/blocks.json: add a "directory" source stitching models/armor/ (prefixed models/armor/) into the blocks atlas, alongside the existing single fluid/nitrogen_still entry - default_anti_radiation_boots/chestplate/leggings/item.json: repoint the "14" texture entry from createnuclear:item/default_anti_radiation_suit to createnuclear:models/armor/default_anti_radiation_suit - default_anti_radiation_helmet/item.json: repoint both the "layer0" and "particle" texture entries the same way - block/reactor/fluid_input/fluid_input_vertical.json: fix the "particle" texture reference from createnuclear:block/reactor/input/input (nonexistent) to createnuclear:block/reactor/fluid_input/input (the actual texture used by texture key "0" in the same model)
…d default-texture reference
Follow-up to the previous commit that fixed the missing anti-radiation
armor icons: write up the full root-cause analysis in
PARITE_FORGE_NEOFORGE.md — why the textures were missing, why Forge's
divergent approach (duplicating textures under textures/item/armors/)
isn't being replicated here, and the atlas-syntax pitfall hit while
authoring the fix.
- PARITE_FORGE_NEOFORGE.md: add §3.2 "Icônes d'inventaire des armures
anti-radiation colorées — divergence assumée avec Forge", covering:
- the symptom (ModelManager logging missing-texture warnings for
all 16 colored armor inventory icons at startup, despite the PNGs
existing on disk at the right size) and that it was not the
IntelliJ bin/main staleness pitfall noted in §2.2 despite the
similar symptom
- the root cause: models/armor/ is never a default sprite source
for the minecraft:blocks atlas (unlike textures/block/ or
textures/item/), since it's normally only loaded via direct GL
binding for the worn armor layer, not atlas lookup for 3D
Blockbench item models — explaining why Forge instead duplicates
these 16 textures under textures/item/armors/
- the fix taken here (adding models/armor as a directory source to
assets/minecraft/atlases/blocks.json instead of duplicating
textures), and that per-resource-pack atlas sources add up rather
than override each other
- a JSON-structure pitfall hit while writing that atlas file
(nesting the source entry under a sources object instead of
putting `type` directly in the root `sources` array), which broke
parsing and silently regressed the already-working fluid sprite
entries — flagged for anyone editing this file again
- a second, separate dead-reference bug found and fixed in the same
pass: the 4 base Blockbench armor item models pointed their
default texture at a nonexistent createnuclear:item/
default_anti_radiation_suit path (present identically, and
equally dead, on Forge) — harmless since those base models are
only ever used as a parent for the 16 colored overrides, but
corrected to point at the real
createnuclear:models/armor/default_anti_radiation_suit path
…layer Flagged as dead code in PARITE_FORGE_NEOFORGE.md §2.2: this render layer (note the "Wold"/"Wolf" typo in its own name) was a started, never-finished attempt at a tinted collar for the tamed irradiated wolf — its render() method was an empty no-op, and it was never registered via addLayer(...) on IrradiatedWolfRenderer, so it had no effect at runtime and doesn't exist on Forge. Remove it rather than finish the feature. - Delete content/contraptions/irradiated/wolf/IrradiatedWoldCollarLayer.java
…, fold layer registration into CNClientEvent CommentEventClients existed solely to forward EntityRenderersEvent.RegisterLayerDefinitions to CNEntityType.registerModelLayer(...), duplicating the client-event subscriber role already served by CNClientEvent. Merge the two by moving that single @SubscribeEvent method into CNClientEvent and deleting the now-empty class. - Delete foundation/events/CommentEventClients.java - CNClientEvent: add the registerLayers(EntityRenderersEvent.RegisterLayerDefinitions) @SubscribeEvent method (delegating to CNEntityType.registerModelLayer(event)), moved over from the deleted class; add the corresponding EntityRenderersEvent import, and collapse the four net.nuclearteam.createnuclear.CN*/CreateNuclear imports into a single wildcard import - PARITE_FORGE_NEOFORGE.md: update the Forge/NeoForge parity tracking doc — mark the irradiated cow port (commit `5350638`) and the IrradiatedWoldCollarLayer removal (commit `4918bf7`) as done, refine §2.1 to note that AnimalUtil only covers isFood()/blockTamingWip() and the full IrradiatedAnimal base-class abstraction is still outstanding (IrradiatedCat/IrradiatedWolf still duplicate behavior), document the anti-radiation armor atlas fix in §3.2, and refresh the top-of-file file/resource counts and the "verify project state" orphan-file count (11→7) accordingly
Follow-up to the previous commit that folded CommentEventClients into CNClientEvent and deleted it: record why in PARITE_FORGE_NEOFORGE.md §2.2, clarifying it wasn't dead code (its @EventBusSubscriber-registered layer registration was load-bearing for irradiated cat/chicken/wolf/cow rendering) but a structural oddity — a likely "CommonEventClients" typo, split out with no Forge equivalent, where Forge instead keeps that registration directly in CNClientEvent.registerLayers alongside the rest of client registration. - PARITE_FORGE_NEOFORGE.md §2.2: add a note explaining the CommentEventClients merge/removal — not dead code, but a Forge-divergent file split (likely a "CommonEventClients" typo) now resolved by moving registerLayers(...) into CNClientEvent to match Forge's structure
…`c` tag conventions
Replace CNBlocks' hand-rolled createnuclear-namespace ore/storage-block
tags (CNBlockTags.LEAD_ORES/URANIUM_ORES/THORIUM_ORES and their
forgeBlockTag "ores"/"ores_in_ground/*"/"storage_blocks" duplicates)
with NeoForge's standard Tags.Blocks/Tags.Items constants
(Tags.Blocks.ORES, ORES_IN_GROUND_DEEPSLATE/STONE, STORAGE_BLOCKS, and
their item equivalents), fix a thorium-block loot table bug found
along the way, move block render types from Java registration to
per-model JSON, and reformat CNBlocks to consistent indentation.
- CNBlocks: for every ore/raw-storage/storage block (uranium, lead,
thorium, nitrate deepslate+stone variants; raw_uranium_block,
raw_lead_block, raw_thorium_block, lead_block, thorium_block,
steel_block), tag with `Tags.Blocks.ORES`/`Tags.Blocks.ORES_IN_GROUND_DEEPSLATE`/
`Tags.Blocks.ORES_IN_GROUND_STONE`/`Tags.Blocks.STORAGE_BLOCKS` and
the matching `Tags.Items.*` on the item side, instead of the
removed CNBlockTags/CNItemTags LEAD_ORES/URANIUM_ORES/THORIUM_ORES
and forgeBlockTag/forgeItemTag("ores")/("storage_blocks") variants
- Fix THORIUM_BLOCK's loot table: it dropped `raw_uranium` (with a
fortune bonus) via an `alternatives` entry instead of dropping
itself — the block now has a plain self-drop entry gated on
`survives_explosion`, matching the other storage blocks
- REINFORCED_GLASS: tag with `Tags.Blocks.GLASS_BLOCKS`/`Tags.Items.GLASS_BLOCKS`
instead of the custom `forgeBlockTag`/`forgeItemTag("glass_blocks")`;
raise explosionResistance from 7.0F to 1200.0F (matching vanilla
reinforced deepslate/obsidian-tier blast resistance, not a normal
glass block anymore)
- ENRICHING_CAMPFIRE: drop the `.tag(BlockTags.CAMPFIRES)` call from
CNBlocks and instead register it via
CreateNuclearRegistrateTags.genBlockTags() (`prov.tag(BlockTags.CAMPFIRES).add(...)`),
consistent with how the fire-tag registration for ENRICHING_FIRE is
already handled there
- Remove `.addLayer(() -> RenderType::cutout/cutoutMipped/translucent)`
Registrate calls for REACTOR_FRAME, ENRICHING_FIRE, REACTOR_ROD_INPUT,
REACTOR_FLUID_INPUT, and REINFORCED_GLASS; add the equivalent
`"render_type"` field directly to the affected block/item model
JSON files (enriching/fire/{floor0,floor1,side0,side1,side_alt0,side_alt1}.json,
reactor/rod_input/{item,rod_input,rod_input_vertical}.json) — the
1.21 render-type-in-model mechanism replacing the old Java-side
registration
- CNTags: remove the now-unused THORIUM_ORES/URANIUM_ORES/LEAD_ORES
CNBlockTags entries
- Reformat CNBlocks' block/item registration chains to consistent
4-space Registrate-builder indentation throughout (no functional
change beyond the tag/render-type edits above)
- Regenerate the affected tag/loot-table JSON under
data/c/tags/{block,item}/... (new common ore/storage-block tags),
data/createnuclear/tags/{block,item}/{lead,uranium,thorium}_ores.json
(item tags kept, block tags deleted), and
data/minecraft/tags/block/{mineable/pickaxe,needs_diamond_tool,needs_iron_tool}.json
- Add .editorconfig: LF line endings, final newline, space indentation
(4 spaces for .java)
…itself The shapeless cloth-dye recipe required the createnuclear:cloth tag (matching any color) as the base ingredient, so e.g. white cloth + white dye validly crafted white cloth — a no-op recipe reachable in survival. Require any color except the target color instead. Also tag several items with NeoForge's common `c` tags where a project-specific forge tag was used redundantly. - CNItems: for the cloth crafting recipe, replace the `.requires(CNItemTags.CLOTH.tag)` base ingredient with `.requires(Ingredient.of(...))` built from every DyeColor except the target color, resolved via ClothItem.Cloths.getByColor(...) — a cloth item can no longer be crafted from itself - Regenerate the 16 shapeless/cloth/*.json recipes with the new 15-color ingredient list instead of the createnuclear:cloth tag - CNItems: tag RAW_URANIUM/RAW_LEAD/RAW_THORIUM with Tags.Items.RAW_MATERIALS, URANIUM_POWDER/COAL_DUST/THORIUM_DUST with Tags.Items.DUSTS, STEEL_INGOT/LEAD_INGOT/THORIUM_INGOT with Tags.Items.INGOTS, STEEL_NUGGET/LEAD_NUGGET/THORIUM_NUGGET with Tags.Items.NUGGETS, URANIUM_ROD/GRAPHITE_ROD/THORIUM_ROD with Tags.Items.RODS, and all four anti-radiation armor pieces with Tags.Items.ARMORS — in each case in addition to, not replacing, the existing project-specific forgeItemTag - Add generated data/c/tags/item/armors.json listing the four anti-radiation armor items under the new common tag
…ION_BIOME_EXTRACTOR Purely cosmetic re-indentation of the last two item registrations in CNItems (8-space Registrate-builder chains reduced to 4 spaces), matching the indentation already used throughout the rest of the file. No functional change. - CNItems: reformat the REINFORCED_GLASS_BOTTLE and IRRADIATION_BIOME_EXTRACTOR item registration chains
…he reactor alarm recipe
Follow-up to PARITE_FORGE_NEOFORGE.md §3.1's "reste à traiter" list:
fill in the three recipes flagged as still missing on NeoForge —
thorium fluid mixing, thorium metal compacting, and the reactor
alarm's mechanical crafting recipe — so thorium's fluid/metal chain
and the reactor alarm are actually craftable, not just obtainable via
creative. Also swap several tag-based recipe lookups from
now-removed CNItemTags entries to the equivalent forgeItemTag, and
tag nitrogen fluid under the water fluid tag.
- CNMixingRecipeGen: add THORIUM_FLUID, mixing dusts/thorium into
25mB of CNFluids.THORIUM under HeatCondition.HEATED, mirroring the
existing uranium fluid recipe
- CNCompactingRecipeGen: add THORIUM (compacting 200mB of thorium
fluid into a thorium ingot); switch YELLOWCAKE's ingredient from a
direct CNFluids.URANIUM.get() reference to the CNFluidTags.URANIUM
tag, matching how THORIUM's own ingredient is already tag-based;
drop the now-unused CNFluids import
- CNStandardRecipeGen: add THORIUM_COMPACTING
(nugget/ingot/block compacting chain for thorium, alongside the
existing lead/steel chains); switch
URANIUM_ORE_TO_URANIUM_POWDER/RAW_LEAD_ORES from the removed
CNItemTags.URANIUM_ORES/LEAD_ORES tags to
CNTags.forgeItemTag("ores/uranium")/("ores/lead")
- CNMechanicalCraftingRecipeGen: add REACTOR_ALARM, a mechanical
crafting recipe for CNBlocks.REACTOR_ALARM (casing, note blocks,
repeaters, and a clock); fix an existing recipe's 'B' key, which
referenced CNFluids.URANIUM.get().getBucket() (an item that doesn't
exist as a standalone bucket entry) to use the vanilla Items.BUCKET
instead
- CreateNuclearRegistrateTags: tag CNFluidTags.NITROGEN under
FluidTags.WATER
- CNTags: remove the now-unused URANIUM_ORES/LEAD_ORES CNItemTags
entries (their consumers were just migrated to forgeItemTag above)
- Regenerate the affected recipe/advancement JSON for the blasting/
smelting lead and uranium ore recipes, the uranium-to-yellowcake
compacting recipe, and the reactor frame mechanical crafting
recipe; add the new thorium_fluid, thorium_block_from_compacting,
thorium_ingot_from_compacting/decompacting,
thorium_nugget_from_decompacting, and reactor_alarm recipe/
advancement JSON; add data/minecraft/tags/fluid/water.json (now
includes createnuclear:nitrogen); delete the orphaned
tags/item/lead_ores.json and uranium_ores.json generated files
- AUDIT_NEOFORGE.md: flag three CNCrushingRecipeGen content
differences from Forge found during this pass (a new
RAW_URANIUM_BLOCK crushing recipe with no Forge equivalent, and two
changed secondary-drop chances/items for RAW_THORIUM_BLOCK/RAW_THORIUM_ITEM)
as open questions to resolve later, not yet fixed
…it into the chicken, and align the cat with vanilla Cat Deliver the "IrradiatedAnimal" abstraction flagged as outstanding in PARITE_FORGE_NEOFORGE.md §2.1: a shared default-method interface for converting an irradiated animal back into its vanilla counterpart (same pattern as zombie villager curing), wired into IrradiatedChicken first. Separately, rewrite IrradiatedCat's AI to closely track vanilla Cat's own goal/behavior implementation instead of duplicating it in project-specific goal classes, and delete the three custom cat goals that duplication required. - Add content/contraptions/irradiated/IrradiatedAnimal: an interface with a static EntityType→EntityType VANILLA_TO_IRRADIATED map and default methods startConverting(int)/finishConversion(ServerLevel)/ getConversionProgress() driving a conversion sequence (damage-boost effect, EntityEvent.ZOMBIE_CONVERTING broadcast, convertTo(...), confusion effect, SOUND_ZOMBIE_CONVERTED) mirroring vanilla's zombie-villager-cure mechanic; implementers supply getNormalVariant()/isConverting()/setConverting()/ setConversionTime(int)/getConversionTime(), and optionally override readFromVanilla(Animal)/writeToVanilla(Animal) to carry state across the conversion - IrradiatedChicken: implement IrradiatedAnimal — add a synced DATA_CONVERTING_ID flag, conversionTime field, getNormalVariant() returning EntityType.CHICKEN, and read/writeFromVanilla(...) syncing the isChickenJockey flag; also port vanilla Chicken behavior that was previously missing: periodic egg-laying (eggTime field, egg spawn/sound/GameEvent.ENTITY_PLACE on tick), chicken-jockey removeWhenFarAway()/getBaseExperienceReward() handling, and persisting IsChickenJockey/EggLayTime/ConversionTime via read/addAdditionalSaveData - CreateNuclear: during common setup, enqueue registering EntityType.CHICKEN → CNEntityType.IRRADIATED_CHICKEN in IrradiatedAnimal.VANILLA_TO_IRRADIATED - IrradiatedCat: rewrite registerGoals()/mobInteract()/canMate()/ getBreedOffspring()/finalizeSpawn() to mirror vanilla Cat's current implementation more closely — use vanilla's own CatTemptGoal/ CatAvoidEntityGoal/CatRelaxOnOwnerGoal instead of the project's duplicated IrradiatedCatTemptGoal/IrradiatedCatAvoidEntityGoal/ IrradiatedCatRelaxOnOwnerGoal; add a PanicGoal; getBreedOffspring() now spawns a vanilla Cat (carrying over tame/owner state) instead of another IrradiatedCat; canMate() now checks against any Cat rather than only IrradiatedCat; finalizeSpawn() adds the CATS_SPAWN_AS_BLACK structure-tag persistence check; mobInteract() rewritten with an explicit client-side branch matching vanilla's structure; add doHurtTarget(Entity)/getAttackDamage() - Delete the now-unused content/contraptions/irradiated/cat/IrradiatedCatAvoidEntityGoal.java, IrradiatedCatRelaxOnOwnerGoal.java, and IrradiatedCatTemptGoal.java - CatLieOnBedGoal / CatSitOnBlockGoal: rename the `irradiatedCat` field to `cat` throughout, and reformat isValidTarget()'s bed/ furnace lookup for readability (no behavior change)
…s and complete the CNBlocks/CNItems parity audit A full line-by-line audit of CNBlocks and CNItems against Forge (closing the "continuous" work item in PARITE_FORGE_NEOFORGE.md §5) found that uranium_ore, deepslate_uranium_ore, lead_ore, and deepslate_lead_ore had lost their base SetItemCountFunction drop range during the Enchantments.BLOCK_FORTUNE → 1.21 Enchantments.FORTUNE port — they fell back to vanilla iron/gold-style single-item drops (via ApplyBonusCount.addOreBonusCount alone) instead of Forge's guaranteed 3–4 (uranium) / 2–4 (lead) raw-material range, unlike thorium_ore which kept its set_count correctly. Restore the missing SetItemCountFunction call on all four loot tables. The audit also confirmed several apparent gaps were false positives, not bugs. - CNBlocks: add back `.apply(SetItemCountFunction.setCount(UniformGenerator.between(3.0F, 4.0F)))` before the fortune bonus on uranium_ore/deepslate_uranium_ore, and `.between(2.0F, 4.0F)` on lead_ore/deepslate_lead_ore, matching Forge's drop ranges - Regenerate the affected loot table JSON (deepslate_lead_ore/deepslate_uranium_ore/lead_ore/thorium_ore/uranium_ore.json) - PARITE_FORGE_NEOFORGE.md: record the full CNBlocks/CNItems audit (§3.3) — confirm 1:1 block/item list parity (27 blocks, 29 items on each side); clear up the six blocks whose Forge-side `.addLayer(() -> RenderType::X)` calls appeared missing on NeoForge — verified they were correctly replaced by a per-model `"render_type"` JSON field (the 1.21 mechanism), not dropped; note a remaining, unfixed divergence where the fortune-bonus formula (`ore_drops` vs Forge's `uniform_bonus_count`) still differs on the affected ores even after this fix, flagged for follow-up if a player reports an odd fortune yield; log a few other reviewed, harmless divergences (redundant setCreativeTab call, the ANTI_RADIATION_HELMET tag being NeoForge-only but alive, and data-component-related typing differences already covered elsewhere in the doc); update the top-of-file status line, file/ resource counts, and the §3.2/§5 tracking tables and priority list to reflect this pass and the previously-landed IrradiatedAnimal work (commit `7d16431`) — PARITE_FORGE_NEOFORGE.md's tracked feature-parity backlog is now empty, only the continuous CNBlocks/ CNItems audit item remains by nature
…de to Modrinth, and fix HUD depth-mask occlusion
Three related fixes bundled together: the anti-radiation armor pieces
never had CNArmorMaterials.durabilityForType(...) applied to their
item builders, so they used the default (zero) durability, which also
caused HelmetOverlay's durability-ratio calculation to divide by
zero; RenderHelper's full-screen overlay blit never touched the depth
state, which harmlessly no-op'd under Forge's old GUI pipeline but
occludes other mods' HUD layers (e.g. Jade) under NeoForge's
GuiLayerManager z-ordering; and Jade was pulled from a pinned
CurseForge build id instead of Modrinth's Maven, which is more
reproducible and doesn't require a Curse API token.
- Rename content/equipment/armor/ArmorMaterials.java to
CNArmorMaterials.java (was shadowing vanilla
net.minecraft.world.item.ArmorMaterials without the project's usual
CN-prefix naming convention for such deliberately-vanilla-shadowing
classes)
- CNArmorMaterials: add setArmorDurability(Type, int factor) and a
setArmorDurability(Type) overload (factor defaulting to 15),
returning a NonNullUnaryOperator<ItemBuilder<T, P>> that sets
`p.durability(type.getDurability(factor))` — usable directly as a
Registrate `.transform(...)` step; adjust the existing
durabilityForType(...)/register(...) signatures to use the
now-imported ArmorItem.Type alias
- CNItems: apply
`.transform(CNArmorMaterials.setArmorDurability(Type.HELMET/CHESTPLATE/LEGGINGS/BOOTS))`
to each of the four anti-radiation armor item builders, so they
finally get real durability instead of the default
- AntiRadiationArmorItem, CreateNuclear: update references from
ArmorMaterials to the renamed CNArmorMaterials
- RenderHelper.renderOverlay(...): wrap the full-screen texture blit
with RenderSystem.disableDepthTest()/depthMask(false) before and
enableDepthTest()/depthMask(true) after, so a fully opaque overlay
(e.g. the anti-radiation helmet HUD) no longer occludes other mods'
post-layer HUD elements (observed with Jade) via depth testing
under NeoForge's GuiLayerManager
- HelmetOverlay: minor whitespace cleanup (blank line before the
durability-ratio comment)
- build.gradle / gradle.properties: replace the pinned
`curse.maven:jade-324717:6291517` dependency and `jade_id` property
with `maven.modrinth:jade:${jade_version}` resolved via a new
`https://api.modrinth.com/maven` repository, and a `jade_version`
property (`15.10.6+neoforge`)
- AUDIT_NEOFORGE.md: mark the RenderHelper depth-state issue as found,
explained (Forge's old painter's-algorithm GUI pipeline vs
NeoForge's GuiLayerManager depth-tested layers), fixed, and
in-game-tested
- PARITE_FORGE_NEOFORGE.md: update the reference to the renamed
ArmorMaterials → CNArmorMaterials class in the "names shadowing a
vanilla class" note
…ti-radiation helmet as a Create goggle, and audit 5 previously-unreviewed files Continuation of the CNAdvancement work: this time also register the anti-radiation helmet with Create's GogglesItem so goggle-gated tooltips (e.g. Create's stress/kinetic overlays) recognize it as goggle-equivalent, matching what wearing it should unlock. Also complete the line-by-line audit PARITE_FORGE_NEOFORGE.md's §3 table had left as "non revérifié" since 14 August, covering CNAdvancement, CNStandardRecipeGen, CreateNuclearJEI, RadiationCapability, and IrradiatedWolf — finding two real, undecided gameplay divergences (the disabled advancements themselves, and IrradiatedWolf missing a panic goal while having gained a full taming/armor system Forge deliberately keeps WIP-blocked) alongside two divergences explicitly accepted as intentional. - CNAdvancement: uncomment ANTI_RADIATION_ARMOR/AVOIDING_CANCER/ DYE_ANTI_RADIATION_ARMOR and REACTOR_ROD_INPUT/REACTOR_FLUID_INPUT (6 advancements total, previously commented out with no compile error since the surrounding chained-field syntax stayed valid) - Add a FULL_ARMOR EntityEquipmentPredicate (head/chest/legs/feet all matching the mod's anti-radiation armor items) and rewrite AVOIDING_CANCER's externalTrigger to build an InventoryChangeTrigger.TriggerInstance directly via CriteriaTriggers.INVENTORY_CHANGED.createCriterion(...) checking an EntityPredicate.wrap(...) of the player wearing FULL_ARMOR, instead of the removed InventoryChangeTrigger.TriggerInstance.hasItems(...) helper (which only checked inventory contents, not equipped slots) - Minor formatting cleanup: reflow the PREDICATES list indentation and drop a few stray blank lines between advancement entries - Regenerate the six new advancement JSON files (anti_radiation_armor, avoiding_cancer, dye_anti_radiation_armor, feeding_the_reactor, fueling_the_reactor, unlimited_power) and update the generated en_us.json/en_ud.json lang files with their titles/descriptions - CreateNuclear: call GogglesItem.addIsWearingPredicate(AntiRadiationArmorItem.IGoggleHelmet::isGoggleHelmet) during common setup, registering the anti-radiation helmet as a valid "wearing goggles" source for Create's GogglesItem checks - PARITE_FORGE_NEOFORGE.md: add §3.4, a full audit of CNAdvancement, CNStandardRecipeGen, CreateNuclearJEI, RadiationCapability, and IrradiatedWolf — document the 6 disabled advancements as an unresolved real bug (§3.4.1); confirm CNStandardRecipeGen's 6 extra decompacting recipes (lead/steel/thorium) and RadiationCapability's persisting contagionDose/contagionTicks (Forge never persists them) as intentional, closed divergences (§3.4.2/§3.4.4); confirm CreateNuclearJEI is a healthy superset of Forge with the snow-powder JEI category correctly wired (§3.4.3); document IrradiatedWolf's defineSynchedData as safe (unlike the earlier IrradiatedCat regression) but flag a missing WolfPanicGoal and a fully-implemented taming/armor system that Forge deliberately keeps WIP-blocked, needing an explicit scope decision (§3.4.5); confirm bluePrintItem/ was already covered by PORTAGE_REACTEUR.md's Lot 2bis rather than left unaudited, and that the api/data/recipe/ EnrichedRecipeGen "vestige" flagged earlier is alive and correctly wired, not dead code; update the top-of-file status line and the §3/§5 tracking tables and priority list with three new work items (re-enable the advancements, decide the wolf taming/armor scope, restore the wolf panic goal)
…t the AVOIDING_CANCER trigger pitfall Follow-up to the previous commit that re-enabled the 6 disabled advancements: update PARITE_FORGE_NEOFORGE.md's §3.4.1 finding from "real bug, unresolved" to "fixed", and record the CriterionTrigger.getId() API pitfall discovered while fixing AVOIDING_CANCER's trigger, plus refresh the doc's summary/status/tracking sections to match. - Update the top-of-file status summary: 3 of the 4 audit findings (RadiationCapability persistence, CNStandardRecipeGen's extra decompacting recipes, and now CNAdvancement) are resolved; only IrradiatedWolf still has open, undecided work - §0's file/resource-status table: mark foundation/advancement/CNAdvancement as ✅ fixed instead of⚠️ unresolved - §3.4.1: rewrite the finding as resolved — explain that CriterionTrigger.getId() no longer exists in the 1.21 API (triggers are identified via their registry, not a self-reported id), so the original Forge-era AVOIDING_CANCER trigger (`new PlayerTrigger.TriggerInstance(CriteriaTriggers.INVENTORY_CHANGED.getId(), ...)`, itself a 1.16–1.20 workaround) had to be rebuilt as CriteriaTriggers.INVENTORY_CHANGED.createCriterion(new InventoryChangeTrigger.TriggerInstance(...)), matching the pattern already used elsewhere in the file; note that compileJava and runData both pass but in-game triggering hasn't been tested yet - §4 (pending in-game verifications): add a row for the 6 re-enabled advancements, flagging AVOIDING_CANCER's rewritten trigger as specifically needing an in-game check - §5 (priority work list): drop the now-resolved "uncomment the 6 disabled advancements" item, renumber the remaining IrradiatedWolf/ CNBlocks-CNItems-audit items, and add a ✅ resolved note summarizing the CNAdvancement fix
…aming and restore the missing panic goal Line-by-line audit of IrradiatedWolf (started 16 August, see PARITE_FORGE_NEOFORGE.md §3.4.5) found the NeoForge port had silently grown a full taming/wolf-armor subsystem that Forge deliberately keeps disabled, while losing a vanilla goal in the process. This fixes both, and uncovers a broader 1.21 API pitfall (dead getStandingEyeHeight override) hit while fixing the eye-height regression that came with it. - IrradiatedWolf: remove the entire taming/armor subsystem not present in Forge (tryToTame, EventHooks.onAnimalTame, canUseSlot, actuallyHurt, canArmorAbsorb, hurtArmor, hasArmor) and its now-dead imports (ItemParticleOption, DamageTypeTags, ItemAbilities, EnchantmentHelper/EnchantmentEffectComponents, Ingredient, EventHooks); rewrite mobInteract on Forge's model so feeding an untamed wolf calls AnimalUtil.blockTamingWip(player, level()) instead of attempting to tame it - IrradiatedWolf: reintroduce the missing WolfPanicGoal (priority 1, panics on isFreezing()/isOnFire()), copied from Forge - IrradiatedWolf: revert TAME_HEALTH from 40.0F back to 20.0F to match Forge now that the armor subsystem (which justified the higher value) is gone; getHurtSound/applyTamingSideEffects simplified accordingly - IrradiatedWolf: fix canBeLeashed to call super.canBeLeashed() (the 1.21 signature dropped the Player parameter entirely, so this wasn't a missing override — the super call itself was just missing) - IrradiatedWolf: remove the dead getStandingEyeHeight(Pose, EntityDimensions) override — confirmed via @OverRide that this hook no longer exists in the 1.21 Entity API (getEyeHeight(Pose) is now final), so the override silently compiled but never ran - CNEntityType: set eye height correctly via the 1.21 mechanism, EntityType.Builder.properties(p -> p.eyeHeight(0.68f)) (0.85 * 0.8, matching Forge's ratio), replacing the dead override removed above - PARITE_FORGE_NEOFORGE.md: mark §3.4.5/IrradiatedWolf as resolved, document the getStandingEyeHeight API pitfall in detail (likely present, unfixed, in IrradiatedCat/IrradiatedCow — added as a new §5 priority item), update the top summary, §0 status table, §4 pending-in-game-verification table, and §5 priority/resolved-notes sections accordingly
…iatedCat/IrradiatedCow and defer its fix out of scope Follow-up to the IrradiatedWolf audit: confirmed by direct reading that IrradiatedCat (line 339) and IrradiatedCow (line ~97) carry the same dead getStandingEyeHeight override found and fixed on the wolf, but deliberately leave it unfixed here — a broader integration pass is planned on both entities to keep shrinking their divergence from the vanilla mobs (continuing the work that already brought IrradiatedCat from 380 to 40 divergent lines, §2.1), and a one-off fix now would be wasted once that pass lands. - §3.4.5: replace the "to verify/fix" note on IrradiatedCat/ IrradiatedCow's getStandingEyeHeight with a resolved note confirming both files carry the dead override, explicitly scoping the real fix to the future vanilla-alignment refactor rather than this parity pass - §5 priority list: drop the now-superseded "verify/fix getStandingEyeHeight on IrradiatedCat/IrradiatedCow" item and add a resolved-note block explaining why it's intentionally left out of the Forge/NeoForge parity tracking
…ormant armor/camera code paths In-game testing pass (16 August) confirmed most previously "shipped without in-game test" items from PARITE_FORGE_NEOFORGE.md's pending table, but found and fixed a real ore-generation divergence, and re-enabled two code paths that had been left commented out. - CNConfiguredFeatures/CNPlacedFeatures: correct ore generation values that didn't match Forge — URANIUM_ORE count 7→4; LEAD_ORE vein size 10→12 and max height 112→60; THORIUM_ORE vein size 16→12, count 16→6, max height 112→55; STRIATED_ORES_OVERWORLD rarity 1/18→1/64 and height range -30..70→-63..16 (NITRATE_ORE was already correct, untouched); regenerated worldgen JSONs reflect the new values - AntiRadiationArmorItem: uncomment the DYE_ANTI_RADIATION_ARMOR advancement award call in inventoryTick, now that the advancement itself is re-enabled (CNAdvancement) - ClientEvents: uncomment the CameraAccessor tremor-offset camera move call, restoring the physical camera shake effect - CommentEvents: register a FluidBucketWrapper item capability for CNFluids.URANIUM's bucket via Capabilities.FluidHandler.ITEM - CreateNuclearDatagen: provide default lang for the "irradiated" translation key group - PARITE_FORGE_NEOFORGE.md: move the uranium/graphite tooltip, raw_uranium_block radiation, snow-powder fan, IrradiatedWolf taming message, ore mining drops, enable_world_gen (both states), and the full nitrogen chain out of the §4 pending-verification table as confirmed by manual in-game testing; document the ore-generation bug found and fixed above with a before/after table; note that WolfPanicGoal and the wolf's eyeHeight fix are deliberately deferred to a future pass covering all of the mod's living entities rather than tested in isolation; and record the open-pipe uranium irradiation test as inconclusive, with CNOpenPipeEffectHandlers/ RadiationEffectHandler confirmed bit-identical to Forge and RadiationCapability.canBeIrradiated()'s enabledItemRadiation config flag flagged as an unexplored lead
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.