Talk: Pokechu22

— ^t numbermaniac ^c 01:08, 13 July 2013 (UTC)

Problem with link[]

I was looking at the change you made to 17w47a, you added "Private security issue" to the list of bugs. However, when I followed the link to the bug tracker it took me to a completely unrelated bug that was fixed in a snapshot 2 years ago. Are you sure the link is correct? -75.179.18.235 22:46, 27 November 2017 (UTC)

(sorry for the late response, apparently I wasn't watching my userpage .-.) The link was incorrect; that ticket was linked as related to the security issue I copied so I think I probably just messed up with the clipboard. --Pokechu22 (talk) 01:01, 27 January 2018 (UTC)

Beta 1.6 Test Build 3 Edit Reverted[]

Referencing this edit: https://minecraft.gamepedia.com/index.php?title=Beta_1.6_Test_Build_3&oldid=prev&diff=1183708

I couldn't see any difference between the tall grass. It also didn't crash when I enabled it on my system. What could be the explanation for why you can see a difference but I can't? I guess the crash is easily explained; it's just buggy code dependent on the GPU or something. I have an RX 480.

―HalfOfAKebab ^{(talk, contribs)} 22:54, 21 February 2018 (UTC)

All the information I have in that section was based off of my attempts to decompile it with MCP, which eventually produced the somewhat mangled gist I linked before. I actually ended up generating my own mappings (based off of those for b1.6.4 I think; here they are) to use with MCP v3.2 (linked on Programs_and_editors/Mod_Coder_Pack) and then ran MCP twice, once on 1.6 and another time on 1.6 test build 3.

The crash is probably machine-specific, the page on beta 1.6 (and the changelog) only says "Temporarily disabled Advanced OpenGL due to bugs". Here's the report. Perhaps the wording should be revised.

The difference for tall grass I've only identified via the code in that diff/with MCP. I haven't fully figured out what the ingame difference is yet; that code seems to be for randomizing the positions of it though. (A lot of the other things in that list were also found with that diff and are also hard to verify in game). I'm going to run some more tests and see if I can figure out if it actually does anything. Tall grass was added in that version, so it seems reasonable for it to behave slightly different during testing... --Pokechu22 (talk) 23:17, 21 February 2018 (UTC)

Got it! It is a change in how the position is randomized. Compare:

This should probably be added to the article. (And yes, it's consistent this way between restarts) --Pokechu22 (talk) 23:58, 21 February 2018 (UTC)

Cool, thanks. I'll update the article. ―HalfOfAKebab ^{(talk, contribs)} 16:52, 22 February 2018 (UTC)

Also, do you have Discord by any chance? I'd like to talk to you about something. ―HalfOfAKebab ^{(talk, contribs)} 16:57, 22 February 2018 (UTC)

I kind of have discord, but not really (I use an IRC bridge, and that doesn't always work well for random PMs). I'm also on the Gamepedia slack, and of course in several different IRC channels on freenode and esper. For wiki stuff the slack's probably the best place to contact me.

End biomes[]

What you said is actually the opposite of what it actually is, it isn't in 1.12 but it is in 1.13. If you look at the earlier videos about Buffet, the end biomes generate with stone. But now, they generate with end stone with bits of stone mixed in. 4hrue2kd83f (talk) 23:17, 17 October 2018 (UTC)

Commands/gamerule edit[]

I don't understand your edit summary. What is there that says there's any connection between random tick rate and the number of blocks in a chunk? Which block gets ticked each time is chosen at random, it doesn't go through them one by one. 4096 is simply the largest value that can fit in 12 bits (when 0 isn't possible), so that implies Bedrock stores it as a 12-bit value, but I doubt that Java has a 12-bit integer data type, so I'd expect it to be different in Java. And in any case, what are the units of the setting, random ticks per game tick? Random ticks per second? Do Java and Bedrock even use the same units? It seems to me the stated fact is based on ungrounded assumptions. – Auldrick (talk · contribs) 04:25, 15 March 2019 (UTC)

All of this is to my understanding (and perhaps I should have commented and done more research instead of merely reverting, but I'm rather busy lately). But the unit is "blocks within the chunk to tick per tick", to my understanding, and it works via a wikipedia:Linear congruential generator (pannenkoek on these, though the implementation would differ). I have a fairly high recollection of seeing a manual implementation of this while poking around in the world code, though I don't remember the details. But, recall, chunks columns are 16x256x16, which are composed of 16 16x16x16 chunk sections. The area within a chunk section is indexed into an array; not as a 12 bit data type, sure, but it's still semantically a 12 bit number at the lowest level (a paletted packed array for each chunk section). But, basically, on the assumptions that a) random ticks happen on a per-chunk-section basis and not a per-column basis (possible unconfirmed) or per-world basis (definitely not the case), b) the game uses a LCG for this, c) the LCG does pass through all blocks with the same period (like the SM64 one but without the extremely short cycle), and d) a block will not random tick itself twice on the same tick, 4096 is a sane maximum. I probably would need to do some more research and/or make a visual, though I can picture something in my head which makes me thing I saw something ages back that I can't think of right now. I'm also doing a stupid amount of math as of late and it's just on my mind. --Pokechu22 (talk) 04:54, 15 March 2019 (UTC)

It's not the array elements that would be 12-bit data types, it's the index (but really, it would probably be 3 4-bit indices). But that's closer to supporting your argument than mine.

On the other hand, your assumption d) is flawed. Assuming you meant that when a block is chosen to be ticked for a second time within a game tick, a different block is chosen instead, it implies that at a setting of 4096, every block in every section of every loaded chunk gets a random tick every game tick. That means that a square patch of dirt surrounded by grass will turn to grass from the outside in smoothly, shrinking each edge inward one block per game tick and always leaving a square of dirt. I tested that in a flat world using the command "/fill ~ 3 ~ ~100 3 ~100 dirt", and that isn't what happens. It fills from the outside in, but the edge is very ragged, so not every block is getting updated every tick. (And if it were, you certainly wouldn't call it a random process.)

If instead assumption d) was meant to imply that when a block was chosen to be ticked for a second time within a game tick, that random tick is simply discarded (as opposed to another block being chosen), this conflicts with your statement that the unit is "blocks within the chunk [section] to tick per tick". At a setting of 4096, you would only get 2048 blocks ticked on average (I think). It also refutes the statement made in the edit that every block will update constantly. – Auldrick (talk · contribs) 07:00, 15 March 2019 (UTC)