Standardized Woodlighting Mod

[Vibzz]

I have been busy working on making a mod to standardize woodlighting, given the amount of suggestions in the MCSR Ranked discord I took it upon myself to create my own solution.

Now, I have this mod at the point where I’m comfortable making this more public for input.

Modrinth (when approved)
Github

Minecraft uses unpredictable random number generators for fire spread and lava lighting and etc, meaning two players with the same seed and identical portal setups can get wildly different woodlight times, anywhere from instantly or over 2 minutes, purely based on luck.

This ‘Woodlighting Standards’ mod replaces this with a seeded system where the time to light a portal is derived from the world seed, the quality of the player’s setup, difficulty and burnable blocks. Given the same seed, the same portal will light at the same time, every time.

Better setups (more burnable blocks, more lava in range) result in faster lights.

time = base_time × difficulty × (1 - setup_score × 0.40) × (1 - lava_score × 0.20)

Base time — exponential distribution from the seed

hash = murmur3(seed XOR murmur3(attempt))
uniform = hash mapped to 0.0-1.0
base_time = -ln(1 - uniform) / 0.06

Most seeds land 5-20 seconds, extends to 75s cap. 3s floor.

Difficulty — multiplier on the base time

• Peaceful: disabled, woodlight cannot occur
• Easy: ×1.3 (slower)
• Normal: ×1.0
• Hard: ×0.8 (faster)

Setup score (0-40% reduction) — based on spreadChance of flammable blocks in burn slots that have reachable lava. Planks (spreadChance 20) at full 12/12 coverage gives ~33% score. Only counts blocks that lava can actually reach via vanilla walk pathing.

Lava score (0-20% reduction) — logarithmic count of lava sources within vanilla walk range of filled burn slots. First few blocks matter most (1 lava ~30%, 4 ~67%, 8 ~90%, 12+ ~100%). Lava behind walls doesn’t count.

Example: Seed gives 20s base, hard mode, 8/12 planks with 6 reachable lava

20 × 0.8 × (1 - 0.22 × 0.40) × (1 - 0.72 × 0.20)
= 20 × 0.8 × 0.912 × 0.856
= ~12.5 seconds

Basically if you do the minimum setup, you will always have a cap of what the seed chooses, but if you create a better setup/ more burnable blocks/ more lava etc, you are rewarded with a faster light time, if both players create the same setup it will be the same total time.

^^^ALL SUBJECT TO CHANGE AND WANTING INPUT^^^

Each seed will start at the same base time for the first portal light, after every successful portal light a counter increments and there’s a new light period for the next woodlight and so on.

Also if you leave a game in the middle of the timer, it will save and continue where it left off.

DEBUG MODE

If you run the debug jar file, you will have a keybind [J] which opens a GUI and also highlights the nearest detected portal. Used for debugging and testing.

[ClearColdWater]

i appreciate the effort going into making this mod, but it is really concerning to see its lack of respect to vanilla parity as i was bringing up in the ranked cord suggestion.

the function to determine when the portal lights is completely arbitrary and is essentially the polar opposite of vanilla parity.

• while difficulty does impact the fire → fire spread in vanilla, the effect is minor and non-linear. applying a flat multiplier (like 1.3x for Hard and 0.8x for Easy) vastly overstates its actual impact. fire also does generate in peaceful mode.
• the ‘setup score’ and ‘lava score’ is calculated based on block counts, which implies that all blocks of the same type are equally valuable. however, in vanilla, position is everything. flammable blocks only exist to make adjacent air blocks lightable; stacking the same flammable block on multiple sides of an air blocks has no extra benifit. as for lava, a specific lava block can be up to 41 times more effective at fire gen than the other for the current 2x3 surface wood light portal. it is also noteworthy that in the current implementation blocks that are not directly adjacent to air blocks inside the portal has zero impact.
• the mod appears to be confusing what’s known as ignite odds(which are not actually odds, more accurate name is ‘encouragement level’) and burn odds(which are) on the wiki. for example, logs have burn odds 5 and give 4x less setup score than that of planks (which are at 20), but has the same encouragement level(both at 5). tnt with burn odds 100 gets a crazy buff. in vanilla, a higher burn odd just means the block burns away or explodes faster(which is worse), not that it lights the portal faster.
• 
  
  with the current implementation of your mod, a setup like this is now one of the optimal wood light setups among with the infinitely many others. implementing such changes drastically discourages strat development.

there is actually a way to calculate the probability of instalight every tick given the setup(which is quite easy), and then you can just do a similar thing with ExerSolver’s perch standardization where you get the cumulative probability of portal not lighting till each tick. but doing that for fire → fire spread will just be impossible without running simulations or training an ml model for approximation.

but even if you do get that to work, there are still the same questions i brought up in rankedcord:

if the light time is already predetermined, is fire in the world before portal light purely cosmetic? what happens if a player punches fire out? when does the game decide that a fire block should be generated? i doubt any solution can handle this remotely accurately, let alone perfectly.

[Vibzz]

Thanks for pointing out some issues with the current system, I’m already doing a rework of some of the things you mentioned to better simulate vanilla.

Now, for the other things, you mentioned “the polar opposite of vanilla parity”.
And while I mostly agree, once I fix a couple of the issues you mentioned, and fix the scoring systems, it will be better, but as for the simulation or ML Model theory, its just not the way to go about doing it I think. Currently fire is just cosmetic for the mod, I do plan on tackling that somehow in the future when this is more fleshed out however.

[Vibzz]

OK I made some drastic changes to how the whole calculation system works, and should represent vanilla a lot better. If you would be willing to test, the builds will be available in the github

I think this rewards a better setup, however fire spread is still not accounted for in the code so keep that in mind.