For the trees, I think it's based on efficiency. Of course they always have to check if they can grow; so instead of, for each of the four saplings, checking a 1*1 area above it it picks one sapling specifically (because randomness takes longer) and checks a 3*3 area, saving memory. But that's just my hypothesis
you are correct in that it only checks one sampling as it is faster to compute, checking all four poses no overhead in memory tho but is just slower. the reason that its the southeast sapling tho is because the code is written with positive numbers as its simply easier to comprehend as a human. South being positive z and east being positive x
In earlier versions of the game, north/south and east/west orientations were handled differently by a lot of mechanics. Back then, most farms and redstone contraptions needed to be built in a certain orientation, or they wouldn't work. I recall that dispensers worked slightly differently in N/S and E/W, and an auto bonemeal farm I was building only worked in the N/S direction. Most of those have since been fixed, but with a code base as old and featured as minecraft, spaghetti code that deep never really dies :D
Pretty sure it’s because direction south and east correspond to increasing positively on the z and x and scale, and I’d assume that positive is probably the games default
Ayyo! I think you should upload this video to ur main channel. Tbh, it’s a good unsolved mystery and I enjoyed it man! Plus, ur gonna get way more views on your main channel than on this channel. Yes, this video is going to start this channel going, but since this is a good video, I think you should upload something else on this channel. Perhaps RU-vid shorts? Anyway, good luck on your tests man!
Ty! As I mentioned in the post I made this video around october but I kept pushing it back because i wanted to keep my momentum. Eventually when I lost momentum it was below the standard for videos I had established by then. Things like random pauses, background music, awkward cuts and audio glitches are something I try to avoid more in main channel. Also my voice is significantly different :p Im glad you liked it though and im happy it got to see the light of day somewhere But yeah I'll be trying out more random videos here like commentary, shorts, etc Pretty much watever i feel like posting
@@kingkane one doesnt need two channels,especially when one already has that much effort put in. i'm saying people do "lessen the quality of their video to meet an aesthetic"
Man, I love your new videos, but I miss the originals like this! The intro hit pretty hard too. Your videos Are well written and I learn new things each time! Your videos are great, keep up the good work wifies.
I noticed that when i tried to use my 0 tick pistone door, the machine part of the door that was facing north was somehow strugeling more then the part facing west.
3:12 Right as he was mentioning TNT cannons, a guy with the username “TNTCannonMoment” got a kill. Edit: Ok well I just realized that was literally him… oops…
Complete shot in the dark but it might be due to the difference in positive and negative values. South and East are positive Z and X, and North and West are negative Z and X. When it comes to the trees, it MIGHT have to do with the central point. The setup has four saplings in a 2x2 grid, so the centerpoint would be between all four blocks, which is not a valid block position, it's a perfect intersection. So instead, the centerpoint of detection "snaps" to the nearest block like a shulker or falling sand block would when teleporting or landing, or even like the functionality of the /tp command- when you input an integer to teleport to, you'll notice that while your Y position ends in X.0 as you are perfectly on top of the block you teleported to rather than a half slab above it, your X and Z positions both end in X.5- the dead center of the block. You have to manually specify .0 to teleport to the edge or corner of a block. So, same deal here- instead of being at a X.0 block position, it's at a proper X.5 block position, aka the center of a block. This likely defaults to south and east since those are the positive values for both instances- between negative 1 and 1 is 0, which is technically a positive value, after all. Negative 1 is farther to 0 than 1 is by an impossibly small amount. Or alternatively, negative values could be the absolute maximum number the game can handle, probably some power of two minus one, and it's just split down the middle to determine positive and negative, so between negative 1 and 1, negative 1 is the farthest possible number from 0 compared to 1 being the closest. So in practice, the centerpoint of the tree snaps to the closest block to the southeast- prioritizing the positive values- which is where it checks for blocks obfuscating its growth. Even if the centerpoint wasn't snapped, the eight points it likely checks for blocks from would all also be at the perfect corners of the blocks around it, which would themselves also choose the positive values over the negative ones, and choose the south east of the four blocks surrounding them. This isn't snapping as much as it is choosing the block without considering the .0, because even if you are in a perfect corner between four blocks, in the code you are still at an X.0 value and that value is the block the game will think you're standing on, and hence that's why even though you should be perfectly centered between four blocks, when you look down you can still only mine one- the south east block. This same explanation could apply to rails as well, with the same positive-over-negative explanation for its behavior. This might be why TNT cannons don't see this same rule applied- they aren't affected by this snapping behavior, they aren't limited to a grid just like falling sand blocks when in midair, so they therefore aren't affected by the Z-X law. As for entity rotation, that's technically a similar yet seperate law. Entities spawn facing perfectly south because their camera rotation defaults at [0,0]- facing directly "forward". Positive X, Positive Y. It's not quite snapping, it's just a default setting. If the game was 2D, you'd only have X and Y, a 2D graph of left to right and up to down with no depth, which is where Z comes in- forward to back, which is where you'd be facing if you were looking at it from a 2D perspective. I can't confirm this. This is just an observation and a guess based on said observation. I could be completely wrong, so take this with a grain of salt.
I think the southeast rule is likely due to some placeholder code for choosing directions. Also this rule decides the direction of zombified piglins spawning by nether portals (they always spawn in the south or east side, depending on which side the portal faces), very useful in designing an overworld gold farm. Also, when a lever is placed horizontally, it always faces south and east too, depending on the player's direction when placing. Although it is not very useful for Java Edition players thanks to the F3 menu, it very useful for Bedrock Edition players when building a gold farm, especially consider that in Bedrock edition we usually use a trident killer to kill them, so a lever will be needed anyway.
these quirks result from it being easier to think in positive numbers, so the code is written to work towards positive x and positive y them being south and east was a random decison.
Yes this is what I was thinking, it is probably just some coded bias towards certain directions, especially since coordinates work from the corner of a block not the centre, that is probably why trees do that wonky 3*3 check.
for the trees I thing it checks for where the logs of any posible are going to be located, and probably all the posibles trees are always inclined towards the south (wich I think it could be a coincidence) you could test it growing a lot of trees and watching in wich blocks there are logs located. PS: I love your channel
ig it just gets caused by the order of caluclations are performed in the game, so blocks in chunks get updated when starting from 1 corner and ending at the other one this game is mostly single-threaded so stuff almost never happens in parallel, unless you do some weird manipulations just like ppl who got command blocks in survival do, simply the game checks for blocks in order and takes the first thing that works for it, ignoring the remaining possibilities
I think that i know why they added the rule, I am a game developer and I think it’s a lot easier to add a such rule, why do you think? You can make the facing of some blocks much easier if you have a common direction, you can have just something like: turn 2 west
The TNT cannons don't shoot a constant distance because there is some code that adds a bit of randomness on the priming of the TNT, thus making the TNT shoot at different distances. The same happens with ender pearls.
For the tnt, when the tnt ignites it slightly jumps to a direction which might have a wall (based on how the cannon is built) this slight jump hits into the wall of the tnt cannon which causes changes in the trajectory of the cannon. This is all my theory btw
