#BlameMojang

jaquadro

New Member
Jul 29, 2019
182
-13
0
GLStateManager is an abomination.

Its own pushAttrib and popAttrib abstraction will not save its own cached state. Modifying enable bits between a push and pop operation is thus guaranteed to fuck up GLStateManager's own internal state relative to underlying GL11.
 

Darkhax

New Member
Jul 29, 2019
34
0
0
One thing that constantly annoys me is how unfinished the systems which they implement can be. One of the most notable examples is from an int based id system to a string based one. There are many places in the code which still reference internal numeric ids rather than the new string system, such as the code used to make creepers drop records when shot by skeletons. Also, based on tweets from Searge, I was under the impression that more systems would be changed to string based identifiers (mainly the potion and enchantment system) however they have not :/
 

ljfa

New Member
Jul 29, 2019
2,761
-46
0
One thing that constantly annoys me is how unfinished the systems which they implement can be. One of the most notable examples is from an int based id system to a string based one. There are many places in the code which still reference internal numeric ids rather than the new string system, such as the code used to make creepers drop records when shot by skeletons. Also, based on tweets from Searge, I was under the impression that more systems would be changed to string based identifiers (mainly the potion and enchantment system) however they have not :/
Yes and especially, there is no code that checks if potion IDs or biome IDs collide. If two mods register the same one it just gets overwritten and you get weird looking biomes or unexpected effects from potions. However iirc, it is checked for enchantment IDs.
 
  • Like
Reactions: Reika and Darkhax

Darkhax

New Member
Jul 29, 2019
34
0
0
Yes and especially, there is no code that checks if potion IDs or biome IDs collide. If two mods register the same one it just gets overwritten and you get weird looking biomes or unexpected effects from potions. However iirc, it is checked for enchantment IDs.
Very true. At least with entities and Enchantments it will throw an exception. I don't get how Mojang could overlook such a critical issue that is also extremely simple to implement.
 

Darkhax

New Member
Jul 29, 2019
34
0
0
Because it's not an issue for Mojang. They don't have any reasons to add a check. It's something that Forge should implement, not Mojang.
I completely agree that Forge has the responsibility to handle this, however Mojang has implemented similar checks within the constructors for Enchantments, Items, Blocks and so on. There would be just as much of a need for them to implement this check in potions and biomes as there was for these other elements.
 

Reika

RotaryCraft Dev
FTB Mod Dev
Sep 3, 2013
5,079
5,331
550
Toronto, Canada
sites.google.com
Yes and especially, there is no code that checks if potion IDs or biome IDs collide. If two mods register the same one it just gets overwritten and you get weird looking biomes or unexpected effects from potions. However iirc, it is checked for enchantment IDs.
And this is why I have the CollisionTrackers.
 

FyberOptic

New Member
Jul 29, 2019
524
0
0
They'll probably focus on creating custom blocks and items with their plugin API via command block scripts, which is why all of this mess was added for block and item registration, block states, models, etc. Potions would be less important to be able to add when users can't really code in custom effects (at least not yet). Same with entities, biomes, enchants, etc. So why bother updating that code?

Mojang's priority is still vanilla, with existing modding probably factoring very little, if at all, into their decision-making process. I've said it before, but we wouldn't still be dealing with obfuscation if modding was anywhere near the top of their priority list. I can't think of anything that was ever added that was meant specifically for the sake of the modding community, not even recently when they left in a tad more obfuscation data related to inner classes and such. Even something like launchwrapper; yeah, it's improved modding to some degree, but more importantly, it allows them to tweak older versions to run in their launcher which they couldn't do previously, while simultaneously providing a way to mod Minecraft that lets them officially frown on distributing JAR mods nowadays. There always seems to be some greater benefit to them. And I don't hold any of it against them, it's not in their interest to do us any favors, and I'm not forgetful of the fact that they don't have to update the game at all and could have cracked down on modding a long time ago. Though I don't confuse a lack of acting against something as approval of it, either.

So, just as it's always been, it's up to the community to make the game easier to mod. Luckily we have some competent people working on Forge again so I'm hopeful of it making strides to improve this kind of thing, just like it used to.
 

FyberOptic

New Member
Jul 29, 2019
524
0
0
I first noticed this 1.8 vanilla bug a while back, which I decided to try to track down recently after I picked up working on a 1.8 API again, with somewhat entertaining results. Basically, chunk segments vanish under certain circumstances, in every version of 1.8.x. I seem to have tracked the issue toward the mess of new code that apparently determines if a chunk segment has any block faces facing in a particular direction, so that it can decide whether to render the segment even if it's inside the viewing frustum. This isn't an occlusion query, mind you, it's more a bit array which is set when an opaque cube is found, as well as extra stuff related to the outer edges of the chunk segment. It's not the most intuitive code, MCP hasn't provided names for most of it, and I've had a tricky time trying to think my way through it to find the bug. You could bypass the final result through an isVisible call and avoid it, but that's obviously not a proper solution.

What I did find is that Mojang added a global debug toggle that will disable the entire system. This implies to me that perhaps they had trouble developing it, and allowed it to be turned off so that the other devs could still actually play the game properly while adding in other stuff. The downside is that if you do disable it then you lose some of the performance gains of 1.8's engine, which ultimately seemed to bring it down, on average, to slightly below that of 1.7.10. Though it was by no means a controlled test.

It's apparently been on the bug tracker for over a year with Grum assigned to it but apparently they either can't figure it out or don't consider it serious enough to focus on. At this point if I were them I would have added a config option to disable it rather than leave such a glaring issue unattended.
 
  • Like
Reactions: gattsuru

Type1Ninja

New Member
Jul 29, 2019
1,393
-7
0
I've already posted this elsewhere, but I'll put it here as well because it seems fitting.
Apparently, when creating an ArmorMaterial, giving it a negative durability both makes the armor invincible and somehow makes the player take more damage. I think it has something to do with "taking damage" meaning to both have the armor itself absorb damage AND take durability damage; those being confusingly entwined with each other... Is confusing and results in weird behavior with negatives. :confused:
It could be useful for troll armor/special effect armor, but I still #BlameMojang. :p
 
  • Like
Reactions: FyberOptic

FyberOptic

New Member
Jul 29, 2019
524
0
0
Execution of events in Minecraft is different when you break a block in survival and creative. onBlockClicked is called in survival, but it's not called in creative. Meanwhile, vanilla offers no solution for overriding blocks being broken in creative, making it impossible for them to have any kind of sub-objects that you can break without destroying the entire thing.

So you might think no biggy, you can just slip in a hook somewhere and be done with it. Forge for example uses removedByPlayer to handle this. But even that's not that simple, because you have to hook two different methods in different classes in order to handle the event on both the client and server, because even that ultimately doesn't go through the same pipeline of events as one another either.

This may work fine for all that Mojang does with it, but from a design standpoint, it's not the most reasonable. I can only assume that it's still a remnant from the older days when there was no such thing as creative mode, so they tacked it on from a lower level to avoid modifying a bunch of other stuff.

This became an issue since I had to do the hooks in my API so that individual Redstone Paste elements could be broken in creative mode. Though rather than rewrite Minecraft like Forge has done, I'm implementing the removedByPlayer-like method in the block class via an interface, then the hook I inserted checks if the block in question is an instance of it before calling the block's method.
 
  • Like
Reactions: Type1Ninja

Lethosos

New Member
Jul 29, 2019
898
-7
0
Opening the thread back up, this time for 1.9: Given some of the new mechanics coming out, what's your opinion about 1.9?

Sent from my Puzzle Box of Yogg-Saron using Tapatalk 2