Flower's Dev Diary (Week of December 31st)

[FlowerChild]

This recent discovery is not a good indication, it is an outlier case - an example worthy of note because it is so far removed from normal. Minecrafts code is really good and it's DNA will be found in games for many years to come.

Yup, exactly. Also, as in all things: Jeb + Dinnerbone != Notch

Honestly, I'm a little worried about the future performance of MC given all the abstractions that Mojang seems intent on making for the sake of the "mod API". We'll see what happens, but as a rule of thumb, general purpose code is hardly ever as fast as specific purpose, and they seem to be going *exceedingly* general purpose with the direction they're taking. I'm a tad worried that the same thing that happened with the client/server merger in terms of most people's performance suffering for the sake of the exception case if they don't handle this well, and I haven't seen a lot to give me confidence that they will.

Like the blockID thing. They could have just given us the twelve bit blockIDs that they started implementing and called it a day. 4K some odd blockIDs would have been plenty by any practical standard. Now I'm hearing that they're restructuring the whole way metadata and blockIDs interrelate to create some kind of variable data format where you can assign bits arbitrarily to either purpose, and my only response to that is: wtf?

Massive fucking overkill man. Somebody seems to have skipped the class on the K.I.S.S. principle.

[Shengji]

Now I'm hearing that they're restructuring the whole way metadata and blockIDs interrelate to create some kind of variable data format where you can assign bits arbitrarily to either purpose, and my only response to that is: wtf?

Massive fucking overkill man. Somebody seems to have skipped the class on the K.I.S.S. principle.

Just... why? I can just see some popular mods out there abusing that, crippling lower end users and frustrating everyone else with slowdowns. 12 bits was perfect, even the most compound of installs packed to the brim with every mod under the sun would struggle to use them all up! You wouldn't get them all installed before the next update came out anyway!

[FlowerChild]

Just... why? I can just see some popular mods out there abusing that, crippling lower end users. 12 bits was perfect, even the most compound of installs packed to the brim with every mod under the sun would struggle to use them all up! You wouldn't get them all installed before the next update came out anyway!

I can only assume that the kiddies over on MCF that try to out compete each other in terms of how many mods they have simultaneously installed (I've routinely seen figures bragged about well over a hundred) have Mojang's ear.

Granted, I like the idea of having the ability to reassign those extra bits to metadata, but do I think it's worth doing something like this for? Not at all.

IMO, it's the danger of having "pure" programmers running a project like that, in that they have a tendency to go for pretty code rather than pretty functionality. There's a certain theoretical appeal to convoluted solutions like that, even if they don't have enough of a practical purpose to justify the work involved.

Honestly, I think in developing this modding API, Mojang is killing off a lot of the MC modding scene in the process. As I've said before, I really wish they had just gone for addressing people's immediate problems (much as the early Forge did), rather than this route of basically rewriting the entire code-base from scratch in bits and pieces to fit some theoretical ideal. I have no doubt I can keep up with their changes given a lifetime of programming experience to back me up, but how many others have already dropped by the wayside in this? Also, the time they're taking to actually get things done is absolutely absurd as a result. I have my doubts as to whether the mod API will be even vaguely functional before MC modding ceases to be a "thing", especially given that they are hastening its decline in the process.

[SterlingRed]

Boundary region for beacons checking entity collisions? What the hell?

I'm not a programmer at all and as soon as I read your explanation of what mojang had done my first thought was " why not check for player location?" before I got to your solution.
Seriously Jeb/dinner bone. Stop and think for two seconds. That's all this would have taken.

[Panda]

Oh my goodness a reason to kill the wither <3

[thedeepestblue]

It turns out that in checking the range, they basically create a massive bounding volume and then check if players are within it. The thing is, they use the standard MC collision test methods, which means that each individual chunk within that volume is checked, a list of ALL entities in each chunk is returned, then an "instanceof" test is made against each and every one within range (and yes, that's a potentially massive number), to check if it's a player.

Wow. I know that it's easy to get locked into a certain train of thought when you're dealing closely with a bit of code, and not see solutions obvious to somebody looking at the problem from the outside. But Mojang isn't an individual, and it boggles the mind that either only one person in that team actually dealt with the code or none of the people that worked on it actually thought to address the basic problem (as you say, the radius of affect and update frequency suggest they were aware of performance issues).

The only possible explanation I can imagine is that you could(?) easily make beacon effects for non-player entities using Mojang's method. You could do some neat things with that, performance drag aside - especially if the update time was a little faster. You could imagine, say, a beacon which messes with nearby projectiles - making them fly in slow motion, or veer upwards or away in strange directions. Using a beacon as a lightning rod also occurred to me (now I'm wondering how your lightning rod code works). It's remotely plausible that Mojang had something like this in mind - most likely a beacon effect to debuff non-player mobs in some fashion - and that it got dropped in the dev process.

EDIT: (But even if that were the case, you'd still be using a general method where a better optimized solution might be available to track the specific entities you're dealing with.)