I've been working on some Minecraft hacks to the underlying storage system and started developing a list of "WTF were they thinking" type things. If you want to know what those are look at the block comments at the top of the header files.
Those little things that irk you about Minecraft
- Thread starter Ripley
- Start date
Also, some class (don't remember which one) has a field called like "isRemote", which is exactly the opposite of what it's supposed to be. Someone at MCP got confused there ^^All the things in minecraft that are publics, altered from anywhere, with no central update/alteration accessors.
All the things that have garbage names, names that have been known to be wrong for several versions of Forge, and still are not fixed.
Example: getAverageGroundHeight (misnamed), which really is just the lowest spawn height.
Latest: The "heightmap" (public, no sane access, bad name), that turns out to be skylight permeability, that can be modified by anything in the code, and only has an initial / sane generation on a chunk level on chunk creation. Oh, and a client-side only call to update/fix things that get wrong.
(seriously, was this someone's "learning java" project?
lol - yeah. Whenever I read code that has that !worldObj.isRemote I have to do a double think to make sure I understand what is going on.
Harvesting cinnamon from Harvestcraft cinnamon trees.
Is it really necessary for it to ping miles off in a random direction?
Is it really necessary for it to ping miles off in a random direction?
1) Multiple mods having the same ore/ore dust. Process machines in IC? Get IC2 ores. Process in TE? Get TE ores. Process in Mekanism? Get Mekanism ores. By now, I feel like there would be a way to fix it.
2) Recipes that require dust of any kind, whether it be obsidian, ore, or coal. So annoying.
3) NEI shift clicking recipes not working when an item in the recipe doesn't stack. Been happening for a long time now.
2) Recipes that require dust of any kind, whether it be obsidian, ore, or coal. So annoying.
3) NEI shift clicking recipes not working when an item in the recipe doesn't stack. Been happening for a long time now.
Celestialphoenix
Too Much Free Time
Losing the Gaia Guardian fight due to air guitar related reasons.
DAAAH da nuh nuh nyaaa... NAHH na na nuh nuh (dum dum drn drm dum dum drn drm drndrndrndrndr-dr-dr-dr-dr-drdrdrdrdrdrdr)
** ALL THE ONE DIMENSIONAL ARRAYS!! **
Please, Notch, if you code again, use two dimensional (or three dimensional!) arrays. Don't make people write out the index as explicit multiplication.
(Was it the X that you multiply by 16, or the Z)
Please, Notch, if you code again, use two dimensional (or three dimensional!) arrays. Don't make people write out the index as explicit multiplication.
(Was it the X that you multiply by 16, or the Z)
I just had to refactor this and split it into multiple files, yet that still pains me when 1 dimensional arrays
Oh wait, that's just the one line of idiocy left from something Flaxbeard did, I meant the entire file. Which is way to broad
Actually those 1 dimensional arrays serve a purpose. An "int[3][3]" is not 9 contiguous int in memory like C/C++/etc, rather it is an array of integer arrays. Of course, maybe JVMs are smart enough to figure it out and do some optimizations...
Nice to know, although I still think there should be optimization on that, I mean an array of arrays can always just be a 1 dim array of n * m length so the JVM should be able to do things. Then again I don't know and as Type said
Or maybe not. I mean, Java. You never know.
One thing to keep in mind, regarding how Java arrays may or may not be optimized: If you've got an array of arrays, the inner arrays need not be the same length. For instance, this code:
will produce something of a triangular array that looks like this:
[[0],
[10, 11],
[20, 21, 22],
[30, 31, 32, 33],
[40, 41, 42, 43, 44],
[50, 51, 52, 53, 54, 55],
[60, 61, 62, 63, 64, 65, 66],
[70, 71, 72, 73, 74, 75, 76, 77],
[80, 81, 82, 83, 84, 85, 86, 87, 88],
[90, 91, 92, 93, 94, 95, 96, 97, 98, 99]]
This sort of behavior can only happen if the syntax "new Type[num][]" is used. A new int[10][10] will be a 10x10 array of ints, and there is no need to initialize each row as in line 3 of the code above. While this could, technically, be implemented internally as a 1x100 array, I think that's unlikely. You can replace any row with any other 1-dimensional int array you like (using syntax like ints[5] = new int[50]), and it'll work fine. ints would then be an array whose #5 row contains 50 zeros, regardless of how ints was created.
The most sensible solution, I suppose, if the end goal was a multidimensional array object that represented its contents as a 1-dimensional Java array, would be to write your own MultidimensionalArray class. In any case, doing so probably doesn't save you much computational complexity anyway.
Code:
int[][] ints = new int[10][];
for(int i = 0; i < ints.length; i++) {
ints[i] = new int[i+1];
for(int j = 0; j < ints[i].length; j++) {
ints[i][j] = i * 10 + j;
}
}
System.out.println(Arrays.deepToString(ints);[[0],
[10, 11],
[20, 21, 22],
[30, 31, 32, 33],
[40, 41, 42, 43, 44],
[50, 51, 52, 53, 54, 55],
[60, 61, 62, 63, 64, 65, 66],
[70, 71, 72, 73, 74, 75, 76, 77],
[80, 81, 82, 83, 84, 85, 86, 87, 88],
[90, 91, 92, 93, 94, 95, 96, 97, 98, 99]]
This sort of behavior can only happen if the syntax "new Type[num][]" is used. A new int[10][10] will be a 10x10 array of ints, and there is no need to initialize each row as in line 3 of the code above. While this could, technically, be implemented internally as a 1x100 array, I think that's unlikely. You can replace any row with any other 1-dimensional int array you like (using syntax like ints[5] = new int[50]), and it'll work fine. ints would then be an array whose #5 row contains 50 zeros, regardless of how ints was created.
The most sensible solution, I suppose, if the end goal was a multidimensional array object that represented its contents as a 1-dimensional Java array, would be to write your own MultidimensionalArray class. In any case, doing so probably doesn't save you much computational complexity anyway.
AAUUGHHH.
So in the past, if you set your view distance to tiny, short, normal, or far, it made no difference to the tick range -- chunks would get random block ticks out to 8 chunks.
You could, for example, have a view distance of 16, and watch grass grow over dirt, or cracked sand spread, and it would stop just past the border at 8 chunks.
Today? I found out that in single player, a view distance of 16 is triggering chunk loads and unloads at the extreme range; Eclipse backtracking shows it is grass spread testing at the edges.
Yep -- if I say "view distance of 16", then the chunks that get ticked are all of those, and chunk loads and unloads are triggered at the edge.
In other words, normal is no longer "View out to 8, update out to 8, and have range 10 loaded so that chunks are not being constantly churned and garbage collected"; rather, several algorithms -- including mob spawns -- only work properly if view distance is 10, and setting it higher causes more random ticks and more chunk churn.
I would call it a bug, except that it seems to be a deliberate design change. Instead, I think it's a horrible decision, and it _IRKS_ me.
So in the past, if you set your view distance to tiny, short, normal, or far, it made no difference to the tick range -- chunks would get random block ticks out to 8 chunks.
You could, for example, have a view distance of 16, and watch grass grow over dirt, or cracked sand spread, and it would stop just past the border at 8 chunks.
Today? I found out that in single player, a view distance of 16 is triggering chunk loads and unloads at the extreme range; Eclipse backtracking shows it is grass spread testing at the edges.
Yep -- if I say "view distance of 16", then the chunks that get ticked are all of those, and chunk loads and unloads are triggered at the edge.
In other words, normal is no longer "View out to 8, update out to 8, and have range 10 loaded so that chunks are not being constantly churned and garbage collected"; rather, several algorithms -- including mob spawns -- only work properly if view distance is 10, and setting it higher causes more random ticks and more chunk churn.
I would call it a bug, except that it seems to be a deliberate design change. Instead, I think it's a horrible decision, and it _IRKS_ me.
I...I...what? I'm sorry, I think that made my brain blue screen. I'll be back once I stop hearing smells and when my mouth doesn't taste of blood.