Instead of random chance, if you want crops to grow regardless of whether they are loaded, it should be time based. All instances of the same crop take the same amount of time (based off day/night cycle). Crops would grow as soon as they are loaded.Time based on the day/night cycle could be abused by sleeping in the bed but not by exiting and coming back. If there was a way to do it based off in game running time, that would be ideal.
Well, I guess you didn't read that linked page on Poisson distributions that I linked, or if you did, you didn't understand it.
I only sort of skimmed it. I haven't had enough statistics to properly understand it.
My thinking was that the sum of N random numbers from X to Y was the same thing as a random number from N*X to N*Y. (For example, the sum of 10 random numbers from 0 to 10 would be a random number from 0 to 100, and 10 random numbers from 1 to 10 would be a random number from 10 to 100.) N would be the number of ticks passed and X and Y are whatever the range of values are for each tick.
Edit: Nevermind, I just realized why that doesn't work. The middle values should be a lot more common because there are many ways to add to them, while the end values have only one way (like rolling a pair of dice.)
In any case, I'm sure that Mojang can figure out that poisson distribution stuff, or that there is already a library that contains the code for that sort of thing.
There's also the possibility of just changing the way growth works. The growth time would be determined upon planting and would count down in a linear non-random fashion.
Rollback Post to RevisionRollBack
Mostly moved on. May check back a few times a year.
Edit: Nevermind, I just realized why that doesn't work. The middle values should be a lot more common because there are many ways to add to them, while the end values have only one way (like rolling a pair of dice.)
Don't stop now! You're 95% of the way to understanding it! It will feel good when you hit 100%! The math may look hard, but it's actually really easy if you just walk it through with an example.
Learning the math for the Poisson distribution (Math 363 at the university I attended) was actually memorable. I realized that I had been curious about it my whole life, and was happy to finally have a term I could use to describe it.
The math for Poisson distributions is centered around a variable called λ. To compute λ, you first need to know an expected value (E). Let's say we want to compute the chance that exactly 7 growth cycles occur in a minute...
Looking at the minecraft wiki, it appears that ideally planted wheat has a 1/10 chance to grow every second. So the expected (E) number of growth units in a minute would be 6 (60 / 10).
Once you know E for any distribution, then you look at the defining characteristic to model that distribution based on E. For Poisson, this is extremely simple. λ = E. So, λ = 6.
Then you simply plug λ into a formula. We want to know the chances of exactly 7 growth cycles in a minute. The formula from wikipedia is:
Probability (P) = (λ^7 * e^-λ) / (7!).
Don't try to evaluate that in your head. Use a calculator or WolframAlpha. Alpha says that P = 13.7677 %
Finding the probability that 7+ growth cycles have occurred is just another formula of that wikipedia page. Applying the probabilties to a sample set, using a random number is just another formula off the page.
ITT: A 10 year old who doesn't know anything about game programming.
ITT: A bunch of people who think they know more than they do.
I am, in fact, a game programmer (not incredibly rare on this board, I imagine), and the solution to this does not in any way require keeping every chunk running. In fact, it's not particularly difficult and should have minimal performance impact. Step 1: Each chunk saves the last time that the player visited it, measured in seconds of play time (so it won't insta-grow if you shut down your computer for a week and then come back). Step 2: When a chunk becomes loaded, compare the last played time to the current seconds of play time (this value is already tracked, IIRC). Apply this delta time to timed objects within the chunk on their next update. Step 3: When applying this delta time, treat "random chance every tick" events as "random time taken" events, with the same average rate. If you want to get the exact same results, you can use a Poisson distribution, but IMO extremes like "instant growth" or "never growing" are not actually desirable features.
* For smelting, wheat, and netherwart, these changes are trivial and would have no performance impact.
* For melons and pumpkins, still quite easy.
* Trees, because of the way they "attempt" various shapes, may not be instantly-growable, but a similar result could be achieved by extremely increasing their growth chance for a few ticks.
* Grass could not be simulated 100%, but even quick-running a single-digit number of spread-cycles (or giving a temporary speed-boost like trees) would be a lot better than what we have now.
Just dont go to the nether thats what i would do if i ever played single player agian
But im not you and your not me so i dont know what happening in your head but cant You grow nether wart in the normal world dont rage at me i dont
Play single player anymore so ya
@Chezzik
I think I get it. There are a whole lot of equations on the page and I was confused as to which one to look at. It's simple enough once you know the equation and the variables. (Maybe I'll get out my calculus textbook and try to make sense of the proof for the equation later.)
So now we have a way to figure out the probability of a given result, but how would we go about actually choosing a result from the many possibilities?
New to Minecraft, aren't you?
Only loaded chunks are updating.
Which means only the area around a player "changes". Plants grow, monsters and mob can spawn there, etc.
Nether chunks are only loaded when you (or another player) is in the Nether. And vice versa.
I've actually played Minecraft for more than a year, but I never noticed this before I started growing Nether Wart.
Well guess what, I'm a game player, and I say just kill pigmen until your wart grows. Head out and kill some ghasts, there are many things you can do while waiting on that wart to grow. Make sure that you make a big enough farm, then, I promise you will have more than you know what to do with. We started not long ago, and we have 15 stacks already, and potions are worth it if you ask me, I don't think they are hard at all. Makes it so easy to kill at xp farms, and swim in lava, run faster, just my opinion, thanks for listening.
ITT: A bunch of people who think they know more than they do.
I am, in fact, a game programmer (not incredibly rare on this board, I imagine), and the solution to this does not in any way require keeping every chunk running. In fact, it's not particularly difficult and should have minimal performance impact. Step 1: Each chunk saves the last time that the player visited it, measured in seconds of play time (so it won't insta-grow if you shut down your computer for a week and then come back). Step 2: When a chunk becomes loaded, compare the last played time to the current seconds of play time (this value is already tracked, IIRC). Apply this delta time to timed objects within the chunk on their next update. Step 3: When applying this delta time, treat "random chance every tick" events as "random time taken" events, with the same average rate. If you want to get the exact same results, you can use a Poisson distribution, but IMO extremes like "instant growth" or "never growing" are not actually desirable features.
* For smelting, wheat, and netherwart, these changes are trivial and would have no performance impact.
* For melons and pumpkins, still quite easy.
* Trees, because of the way they "attempt" various shapes, may not be instantly-growable, but a similar result could be achieved by extremely increasing their growth chance for a few ticks.
* Grass could not be simulated 100%, but even quick-running a single-digit number of spread-cycles (or giving a temporary speed-boost like trees) would be a lot better than what we have now.
I don't think I am convinced that this could be done with minimal performance impact. If I am traveling at a high rate of speed (such as in a cart on a powered rail), the system would have to do a much larger number of chunk updates in a relatively small amount of time. Depending on how many time-sensitive block/items are located in each chunk, this could result in bursts of lag or brief periods of invisible terrain, and the problem would be magnified in an SMP environment.
IMHO, the game would be more interesting with a minimal computational cost.
For example every item or blocks that need to be simulated (furnaces, wheat/animal/tree growth, ...) could be inserted in a global list. A low priority thread could simulate each item in the list until the item reach the end status and it is removed from the list (a furnace has stopped to burns or the tree has grown).
One thing that always bugged me is that during sleep the time freezes.
I doubt it would be a minimal computing or I/O cost for what you are suggesting.
Imagine if instead of SSP, it were an SMP server, with dozens or hundreds of players, each potentially with their own wheat, tree, and animal farms scattered across the map, with some farms even being in the Nether or the End dimensions. If all "active" time-sensitive objects were kept in a big list, then that list would also have to be saved and loaded when the SMP server was stopped and started (or the whole map would have to be scanned for "active" time-sensitive blocks to watch), and the list would be one more potential thing to get corrupted or lost if the server crashed.
Whenever someone entered a chunk, either the list would have to be checked whether that chunk contained any of the "active" blocks, or the chunk would have to be scanned for specific blocks and then cross-referenced in the list. This would certainly add a significant amount of CPU, memory, and I/O cost to store and process the list.
There simply wouldn't be enough benefits to do this.
I'm not saying "get a mod", just implying that the whole thing isn't impossible to do.
From what I am reading, this mod only simulates the chunks that are loaded, and only when you sleep, and only on SSP. I haven't read through all 48 pages, but it appears that it will not simulate Nether chunks while you are sleeping in the overworld, and it will only simulate chunks that are loaded, so any farms would have to be right near your bed anyway.
I don't think I am convinced that this could be done with minimal performance impact. If I am traveling at a high rate of speed (such as in a cart on a powered rail), the system would have to do a much larger number of chunk updates in a relatively small amount of time. Depending on how many time-sensitive block/items are located in each chunk, this could result in bursts of lag or brief periods of invisible terrain, and the problem would be magnified in an SMP environment.
If the growth time for stuff was determined ahead of time (instead of incrementally, requiring a random number for each tick) then the computations become very simple and perhaps quicker than they are now.
I don't see how things could get much worse than they are now, with things performing growth ticks anyways as you are passing through the chunks.
Rollback Post to RevisionRollBack
Mostly moved on. May check back a few times a year.
Notch and Jeb are programmers. They're the type of person that sees everything as math problems in school. There are right answers and wrong answers, and nothing else.
Yeah, that's not real software is developed. At all. Especially games. Physics and graphics simulations are nothing but "close enough" approximations that are chosen because they're fast.
Guess what, I am a programmer too.
The problem here is that it's so much effort and power taken for such an insignificant thing. Who cares if your crops don't grow when you aren't like 500 blocks from it? You can use bonemeal, have multiple farms or just kill a cow.
There are also limits in java itself. It's not really the best language for games.
Are you joking? Limits in java itself?
The game runs the same kind of calculations 20 times a second. Each time the game 'ticks' it's updating furnaces, wheat, animals, checking to see if/where it should spawn things, etc. Each 1/20 of a second wheat is checking to see if it should grow. Updating the chunk as you load it would take *far* less time than that, since you're concerned with fewer in-game objects.
Increasing each newly-loaded chunk's first tick by 50% is hardly going to be noticeable.
Think about it this way, does a farmer plant his seed and then go on vacation for 3 months or....does he weed and fertilize and spray for bugs and fix the fence to keep the sheep out day after day after day?
Think about it this way, does a farmer plant his seed and then go on vacation for 3 months or....does he weed and fertilize and spray for bugs and fix the fence to keep the sheep out day after day after day?
What about cacti? They are very low maintenance.
I would also assume netherwart is very hardy to survive in the nether.
Rollback Post to RevisionRollBack
Mostly moved on. May check back a few times a year.
This whole "list" thing is not even necessary. What I'm talking about is a simple change in the tick behavior of certain blocks, for 1 to N ticks (where N is small). No extra data stored, no significant extra processing.
Seriously:
Furnace: Raise a single number for one tick, possibly add more than one item to completed stack.
Wheat / Netherward: Raise a single number for one tick.
Melons / Pumpkins: Raise a single number, potentially run a very simple space calculation to see how many can spawn, or alternately just raise the number for N ticks.
Trees / Grass: Raise a single number for N ticks. For grass, you could optionally run a very simple space calculation for quick spreading, but you don't even have to.
If you think that this is a significant amount of processing, you need to study more. It's orders of magnitude less than the amount necessary to start drawing those chunks again.
Re: Replacing tick-based mechanics with time-based mechanics. I considered this, and gameplay wise it's a good thing, but it does increase the amount of storage necessary, potentially by a considerable amount.
My thinking was that the sum of N random numbers from X to Y was the same thing as a random number from N*X to N*Y. (For example, the sum of 10 random numbers from 0 to 10 would be a random number from 0 to 100, and 10 random numbers from 1 to 10 would be a random number from 10 to 100.) N would be the number of ticks passed and X and Y are whatever the range of values are for each tick.Edit: Nevermind, I just realized why that doesn't work. The middle values should be a lot more common because there are many ways to add to them, while the end values have only one way (like rolling a pair of dice.)
In any case, I'm sure that Mojang can figure out that poisson distribution stuff, or that there is already a library that contains the code for that sort of thing.
There's also the possibility of just changing the way growth works. The growth time would be determined upon planting and would count down in a linear non-random fashion.
Mostly moved on. May check back a few times a year.
Don't stop now! You're 95% of the way to understanding it! It will feel good when you hit 100%! The math may look hard, but it's actually really easy if you just walk it through with an example.
Learning the math for the Poisson distribution (Math 363 at the university I attended) was actually memorable. I realized that I had been curious about it my whole life, and was happy to finally have a term I could use to describe it.
The math for Poisson distributions is centered around a variable called λ. To compute λ, you first need to know an expected value (E). Let's say we want to compute the chance that exactly 7 growth cycles occur in a minute...
Looking at the minecraft wiki, it appears that ideally planted wheat has a 1/10 chance to grow every second. So the expected (E) number of growth units in a minute would be 6 (60 / 10).
Once you know E for any distribution, then you look at the defining characteristic to model that distribution based on E. For Poisson, this is extremely simple. λ = E. So, λ = 6.
Then you simply plug λ into a formula. We want to know the chances of exactly 7 growth cycles in a minute. The formula from wikipedia is:
Probability (P) = (λ^7 * e^-λ) / (7!).
Don't try to evaluate that in your head. Use a calculator or WolframAlpha. Alpha says that P = 13.7677 %
Finding the probability that 7+ growth cycles have occurred is just another formula of that wikipedia page. Applying the probabilties to a sample set, using a random number is just another formula off the page.
I am, in fact, a game programmer (not incredibly rare on this board, I imagine), and the solution to this does not in any way require keeping every chunk running. In fact, it's not particularly difficult and should have minimal performance impact.
Step 1: Each chunk saves the last time that the player visited it, measured in seconds of play time (so it won't insta-grow if you shut down your computer for a week and then come back).
Step 2: When a chunk becomes loaded, compare the last played time to the current seconds of play time (this value is already tracked, IIRC). Apply this delta time to timed objects within the chunk on their next update.
Step 3: When applying this delta time, treat "random chance every tick" events as "random time taken" events, with the same average rate. If you want to get the exact same results, you can use a Poisson distribution, but IMO extremes like "instant growth" or "never growing" are not actually desirable features.
* For smelting, wheat, and netherwart, these changes are trivial and would have no performance impact.
* For melons and pumpkins, still quite easy.
* Trees, because of the way they "attempt" various shapes, may not be instantly-growable, but a similar result could be achieved by extremely increasing their growth chance for a few ticks.
* Grass could not be simulated 100%, but even quick-running a single-digit number of spread-cycles (or giving a temporary speed-boost like trees) would be a lot better than what we have now.
But im not you and your not me so i dont know what happening in your head but cant You grow nether wart in the normal world dont rage at me i dont
Play single player anymore so ya
I think I get it. There are a whole lot of equations on the page and I was confused as to which one to look at. It's simple enough once you know the equation and the variables. (Maybe I'll get out my calculus textbook and try to make sense of the proof for the equation later.)
So now we have a way to figure out the probability of a given result, but how would we go about actually choosing a result from the many possibilities?
Forget about traveling any significant distance away, either.
Notch wanted to encourage exploration. Having to stick around for your crops to grow does not do that.
Mostly moved on. May check back a few times a year.
I've actually played Minecraft for more than a year, but I never noticed this before I started growing Nether Wart.
I don't think I am convinced that this could be done with minimal performance impact. If I am traveling at a high rate of speed (such as in a cart on a powered rail), the system would have to do a much larger number of chunk updates in a relatively small amount of time. Depending on how many time-sensitive block/items are located in each chunk, this could result in bursts of lag or brief periods of invisible terrain, and the problem would be magnified in an SMP environment.
- sunperp
OH GOD GUYS.
STOP THE ****ING PRESSES.
I doubt it would be a minimal computing or I/O cost for what you are suggesting.
Imagine if instead of SSP, it were an SMP server, with dozens or hundreds of players, each potentially with their own wheat, tree, and animal farms scattered across the map, with some farms even being in the Nether or the End dimensions. If all "active" time-sensitive objects were kept in a big list, then that list would also have to be saved and loaded when the SMP server was stopped and started (or the whole map would have to be scanned for "active" time-sensitive blocks to watch), and the list would be one more potential thing to get corrupted or lost if the server crashed.
Whenever someone entered a chunk, either the list would have to be checked whether that chunk contained any of the "active" blocks, or the chunk would have to be scanned for specific blocks and then cross-referenced in the list. This would certainly add a significant amount of CPU, memory, and I/O cost to store and process the list.
There simply wouldn't be enough benefits to do this.
- sunperp
From what I am reading, this mod only simulates the chunks that are loaded, and only when you sleep, and only on SSP. I haven't read through all 48 pages, but it appears that it will not simulate Nether chunks while you are sleeping in the overworld, and it will only simulate chunks that are loaded, so any farms would have to be right near your bed anyway.
- sunperp
I don't see how things could get much worse than they are now, with things performing growth ticks anyways as you are passing through the chunks.
Mostly moved on. May check back a few times a year.
But wouldn't it have to be kept in the list until the chunk was actually updated? Or would you include chunk updates in the background process?
- sunperp
Yeah, that's not real software is developed. At all. Especially games. Physics and graphics simulations are nothing but "close enough" approximations that are chosen because they're fast.
Are you joking? Limits in java itself?
The game runs the same kind of calculations 20 times a second. Each time the game 'ticks' it's updating furnaces, wheat, animals, checking to see if/where it should spawn things, etc. Each 1/20 of a second wheat is checking to see if it should grow. Updating the chunk as you load it would take *far* less time than that, since you're concerned with fewer in-game objects.
Increasing each newly-loaded chunk's first tick by 50% is hardly going to be noticeable.
I would also assume netherwart is very hardy to survive in the nether.
Mostly moved on. May check back a few times a year.
Seriously:
Furnace: Raise a single number for one tick, possibly add more than one item to completed stack.
Wheat / Netherward: Raise a single number for one tick.
Melons / Pumpkins: Raise a single number, potentially run a very simple space calculation to see how many can spawn, or alternately just raise the number for N ticks.
Trees / Grass: Raise a single number for N ticks. For grass, you could optionally run a very simple space calculation for quick spreading, but you don't even have to.
If you think that this is a significant amount of processing, you need to study more. It's orders of magnitude less than the amount necessary to start drawing those chunks again.
Re: Replacing tick-based mechanics with time-based mechanics. I considered this, and gameplay wise it's a good thing, but it does increase the amount of storage necessary, potentially by a considerable amount.