I am noticing that every ranked cord suggestion thread I post this into dies immediately which I suppose is because the thread is too long. Here is a slightly shorter version I have proofread that was summerized by google gemeni:
The Problem
Standardizing “Wood Light” (lighting a portal with lava and wood) is difficult because players build portals at different times and with different layouts. Current solutions often fail to account for these variables or alter game speed, which breaks vanilla behavior.
The Solution: Synchronized Outcome Ranking
I propose a method that standardizes “luck” rather than the exact game state. This ensures that if one player gets a “lucky” tick, the other player also gets a “lucky” tick relative to their specific setup, without changing vanilla probabilities.
How It Works
Instead running random tick once for each tick*, the game runs a simulation of N possible outcomes for that tick.
- Simulation: We simulate N random ticks* for the player’s specific setup (e.g., 200 potential realities) but do not apply them yet.
- Ranking: We evaluate these outcomes based on how helpful they are (e.g., “Did fire spawn near the portal?”). We sort them from “Worst Outcome” to “Best Outcome.”
- Shared Luck: We generate a shared “luck value” (r) between 0 and 1 for both players.
- Application: If the shared value is high (e.g., 0.99), both players receive an outcome from the top 1% of their respective simulations.
- in the usual terms three random ticks run in each subchunk every tick, here i am refering to ‘random tick’ as the entire random tick process.
Why Imperfect Scoring Does Not Break Vanilla
It is critical to understand that the accuracy of the ranking system has zero effect on vanilla parity.
From the perspective of a single player, the game is picking one outcome from the list based on a random number. Mathematically, it does not matter how that list is sorted—whether it is sorted perfectly by “usefulness” or sorted completely randomly—every specific outcome still has the exact same probability of being chosen (1/N).
The scoring system is only used to align the two players.
- If the scoring is perfect: Both players get equivillant results at the same time.
- If the scoring is flawed: The players might not be perfectly synced, but their individual game mechanics remain 100% vanilla.
Therefore, we do not need a complex or perfect evaluation function to keep the game “legal.” We only need a “good enough” function to make the race fair.
Optimization
To make this computationally feasible, we use Importance Sampling. Since ~99% of random ticks in a wood light setup result in nothing happening, we can group those outcomes together and only heavily simulate the ticks where fire is actually generated. This allows us to run thousands of effective simulations per tick without causing lag.
Broader Applications
This logic extends beyond wood lights. By ranking outcomes and sharing a luck seed, we could standardize:
- Fire Spread: Ensuring fire spreads at similar rates.
- Stray Mob Spawning: Ranking spawns by type or distance.
- Blaze Cycles: Ensuring players get spawn cycles on the same “rank”.
This method offers a mathematically fair, vanilla-compliant way to reduce RNG variance in competitive play.
Below is the original version:
Standardizing wood light without significant vanilla disparity has long been considered impossible, for players can build the portal in different chunks and different relative position inside the chunks, their setups can be completely different, and build portal in different times. In a previous post I described a 'standardization` method that just lowers the varience by manipulating the speed of time, but it is not really a standardization since the time of both players lighting their portal is still independent. In this thread I will show a new standardization idea that probably works beyond just standardizing wood light.
¹ The process that flammable blocks catch fire from lava is called Fire Spread in the wiki, but it is both unintuitive and easily confused with the process air adjacent to flammable blocks catches fire from another fire, which works fundamentally different. I stand by my term from previous posts and in this post I am going to continue calling it Fire Generation.
To explain the idea better, let’s assume that both players build their wood light setups in a way that all the blocks affecting the wood light can be contained within one subchunk (the two players can build their setups in different subchunks), and we only care about standardizing the fire generation¹ process. Then a naive way to implement the idea will be like so:
- Detect when both players finish their portal build and start a timer, for every tick after we generate a pseudo-random number r based on that tick(when both players’ timer are at the same tick, they use the same pseudo-random number) for the random tick process in that subchunk. The number is uniformly random between
0and1, deciding how ‘lucky’ both players are in that tick. - For both players’ subchunk their portal is in, run N simulated random ticks, in which we don’t apply the changes C_i made by the simulated random tick i to the world, instead we pass C_i through a function to evaluate how much faster on average those changes make the portal light \Delta E_{C_i}.
- Sort all the simulated random ticks by \Delta E_{C_i}. Choose the random tick that is rank \lfloor rN\rfloor and apply it to the world.
This naturally raises the following questions:
- Why is this solution vanilla?
- How can we possibly accurately evaluate the average light time changed caused by these simulated random ticks without also running huge amount of simulations, and make the solution infeasible in terms of computational resources?
- How many simulated random ticks do we have to run in order to guarantee enough “fairness” between both players? (is that number small enough to be acceptable?)
Why is this solution vanilla?
From any player’s prospective, because r is a random number, the process that we choose the random tick ranked \lfloor rN\rfloor is just randomly selecting from that sorted list, which, it doesn’t matter at all how the list is arranged, every element is still uniformly randomly selected, and that has no difference compared to just running a random tick.
How can we accurately evaluate the changes made?
Since how we arrange the list before randomly selecting from it does not matter, we do not rely on any properties of the evaluation function to make the process vanilla, so the answer to this question is that we don’t actually have to make the evaluation accurate! In other words, from any players’ prospective, how we evaluate the simulated random ticks does not matter at all; comparing the luck of different players in that tick, the evaluation function just have to be anything better than random to make both players have closer luck.
For example, we can implement that the score of any fire generated is proportional to its distance to the portal, the score of a fire that immediately lights the portal is infinity, and add up the score of all fire generated in that random tick. So, say one player has a setup that is slightly worse than the other player, so their immediate light probabililty is slightly lower than the other, and the selected r just so happens to be at that borderline. The player might not get an immediate light like the other, but they can still get 2 blocks of fire at important positions, drastically lowering their expected portal light time.
For a more accurate evaluation without running mass simulations, there is probably a good GNN structure that can still be decently fast but that is not very necessary.
How many simulated random ticks do we have to run?
With the naive implementation that I described, the answer is a lot. For a real wood light process, ~99% of the ticks not a single fire is lit. Let’s say we only run 200 simulations, and r is 0.997, with two players doing the exact same setup, one player might get all 200 of them doing nothing, and the other player might get 199 of them doing nothing, while 1 of them immediately lighting the portal, making the standardization not fair at all. In order to avoid this as much as possible, we would have to run thousands of simulated random ticks every tick.
But we can optimize this with the help of something called importance sampling. I’m not an expert on this so it might not be the best way to do it, but one way to do it is we combine all the blocks that do nothing(air, stone, etc.) into one abstract block, this block has just slightly higher chance of being chosen compared to the rest of the blocks that does do something, and we scale the probability of each case happenning back when we select randomly from them. This way, out of 200 samples, we might have 20 that does nothing(each of them might effectively acts as ~10 samples), and 180 of them generating fire in various different spots(each of them might effectively acts as ~0.01 samples). Note that in this process we effectively combine duplicate cases together, so it shouldn’t cause vanilla disparity either if implemented correctly.
Of course, all the blocks affecting the wood light might not be in one subchunk. In order to avoid vanilla disparity, we cannot simply use the same r for every subchunk affected, instead we have to combine the effects from all the subchunks and rank it from there before applying any of them.
Similar idea can also be applied to standardizing fire spread, where we can increase the chance of each fire spreading when sampling; Or standardizing mobs in stronghold, we score the impact by the mob type and its direction and distance to portal room; Or standardizing strays between different fortresses, etc.