1.9 Preview

[FyberOptic]

Can we expect any kind of performance impact from the AABB bounding?

I'd say it might improve things a bit. You could cache bounding boxes for specific states and return them more easily, I suppose.

EDIT: I'm going to add to that to say that it does mean creating a lot of junk for the garbage collector to clean up when a block needs very many bounds changes, since a new AxisAlignedBB has to be created for absolutely any change during rendering or whatever. But Mojang has already been heading in this direction of lots of spillage of this sort, so it's status quo at this point.

Searge and Dinnerbone were tweeting about how they worked so much, so I was guessing this snapshot would have been awesome anyway, yet they were also talking about how their work could break the game....

Yeah Searge said something about reducing the number of times a chunk potentially needs to be generated. I don't know what specifically was changed there yet.

 

[ratchet freak]

Custom block rendering appears to be here to stay, no matter how many times certain people may have tried to convince us otherwise as one of the many excuses to not allow custom rendering in 1.8. getRenderType() now returns an enum. It's also one of the methods abstracted into the block state. They wouldn't go to this trouble if they planned to remove it. The downside is that being an enum rather than a simple integer means either a different style of render hook is necessary, or the enum itself has to be modified at runtime. Not a big deal though, personally I'll just change my 1.9 render hook to use the block instance as the key in the custom renderer map rather than use the getRenderType value from now on.

unless there is an enum for "custom" or "composite"

where composite is for animated blocks like the enchanting table with a static table and a book with turning pages.

 

[Hlaaftana]

unless there is an enum for "custom" or "composite"

where composite is for animated blocks like the enchanting table with a static table and a book with turning pages.

Isn't the book a particle?

 

[FyberOptic]

unless there is an enum for "custom" or "composite"

where composite is for animated blocks like the enchanting table with a static table and a book with turning pages.

The enchanting table uses a tile entity special renderer to do that fancy stuff. Even 1.8 mods can still use those, and is another one of those things that makes Lex's "modders shouldn't be able to do direct rendering so that I can't get blamed when they break something" argument completely moot. But expecting him to know how the game works is apparently asking a lot.

As for the render type being an enum now, it doesn't really matter. Like I said, another means of registering custom block renderers can be used. I already changed mine to register to the block instance instead and it works just as well.

 

[FyberOptic]

A few misc things to point out.

I went through and looked to see if anything other than potions was updated to an object registry, and it turns out enchantments are as well. It should be safe to assume that Forge will do to them what it did to blocks and items in 1.7, eliminating the need for the user to mess with IDs. Other stuff, namely biomes, are still not updated in this manner. I assume they will be eventually, I just don't know yet if that'll be 1.9.

I noticed that in RegistryNamespaced that the underlyingIntegerMap object is no longer the same class. I've been hesitant to call it ObjectIntIdentityMap yet since it's so different, in case the original still exists somewhere, though it does carry out basically the same task (at like twice the size). Maps and lists replaced with arrays, maybe for better performance.

ExtendedBlockStorage has been changed. What used to just be a char array named "data" to store the blocks is now a class. ExtendedBlockStorage itself is smaller, with some of the functionality moved into that new class. If I had to guess, this might be the first step towards merging the block ID and metadata fields into one large field for storing just block states. Or it's just them abstracting more stuff for the sake of abstracting it, who knows yet.

Mojang said the structure blocks were only going to be for internal use, but they store NBT tags for stuff like "author". I think it'd be a waste if they don't eventually provide a way for people to share structures with others.

Specific to the later snapshots, 15w38a reverted and/or changed some of the Block changes that they just added in 15w37a, related to the AABB stuff. Blocks suddenly don't get their own instance of an AABB variable anymore, there's just a couple of static ones now, one of which a standard 0,0,0,1,1,1 block, the other is set to null (not sure what this one's for yet). The block subclasses allocate their own variable(s) to store their AABB when needed.

 

[FyberOptic]

Maybe I should mention this before I forget again.

Something big in 15w41a/b isn't just the new boats or wings, it's the revamped player movement code. Vehicle movement was stripped out and put into its own method, complete with its own packet. One can hope that this leads to much more reliable vehicles as we move forward.

Unfortunately these movement changes, some of which designed to prevent cheating I believe was said, had some repercussions. After spending two days tracing through everything trying to figure out why my JourneyStone mod wasn't working (which lets you teleport to a saved location), Jeb told me that the chorus fruit was also broken (which teleports you to a random location nearby). Oddly it's only teleportations issued in onItemUseFinish, but I was able to do so in others like onPlayerStoppedUsing and onItemUse. Hopefully they'll track that down soon.

They also broke the recipes for the new boats by specifying the metadata for the various wood types without specifying a stack size first, so it used the metadata value as the stack size instead. I didn't even realize that you couldn't craft them initially, I was just digging around trying to see why MeddleGuide was showing the recipe all screwy. Easy mistake to make though. At least the oak one can still be crafted!

 

[SatanicSanta]

They also broke the recipes for the new boats by specifying the metadata for the various wood types without specifying a stack size first, so it used the metadata value as the stack size instead. I didn't even realize that you couldn't craft them initially, I was just digging around trying to see why MeddleGuide was showing the recipe all screwy. Easy mistake to make though. At least the oak one can still be crafted!

Do they just not test their code before they push or something?

 

[FyberOptic]

Do they just not test their code before they push or something?

My understanding is that they run it just long enough to see if anything crashes terribly, then push it out for the community to find the problems. Though there's been various instances where it still crashes terribly.

 

[SatanicSanta]

My understanding is that they run it just long enough to see if anything crashes terribly, then push it out for the community to find the problems. Though there's been various instances where it still crashes terribly.

So the answer would be "no"... Coders that don't test their code...

 

[FyberOptic]

So 15w43a happened, which added some new things like igloos and loot tables. But it also added a sound registry, a Sound class, and a Sounds bootstrap class, all similar to how items and blocks work starting with 1.7, and how potions, status effects, and enchantments already were as of previous 1.9 snapshots.

This means you have to register your sounds now. Sounds aren't played by their string ID anymore, you pass the Sound object. It seems like a slight inconvenience but I guess it's a performance benefit in the end. It sure threw my DynamicMappings for a loop, because I used a lot of those sound string IDs to help verify classes. But I'll figure something else out.

 

[RenzosNips]

I'm curious to what you think of the loot tables, and how they'll affect the modding community. While mods have been able to change the drops for blocks and mobs for a while, I'm guessing it'll be easier then listening for the event, canceling it if you are changing the drop, and returning your own drop.

 

[FyberOptic]

I'm curious to what you think of the loot tables, and how they'll affect the modding community. While mods have been able to change the drops for blocks and mobs for a while, I'm guessing it'll be easier then listening for the event, canceling it if you are changing the drop, and returning your own drop.

I haven't even had a chance to hardly look at them. I spent so much time getting things sorted to work on this new snapshot that I closed it all for the day.

From what I make of it though I think loot tables is just a good idea. We'll see if they implement it as well as one would hope, and I'll look over the format when I get a chance. But there are some potential downsides, like if two mods want to change a loot table. A mod API will still have to provide some mechanism to modify the tables, and preferably maintain a way to handle it programmatically for instances where that's still desired by a mod.

 

[HeroWing2]

Hey.
I didnt red all the changes cause im sure i wont unterstand them.
But There is one question which im insterested in. Is it already clear if 1.9 modded mc is gonna happen?

 

[lenscas]

Hey.
I didnt red all the changes cause im sure i wont unterstand them.
But There is one question which im insterested in. Is it already clear if 1.9 modded mc is gonna happen?

No one will know until it comes out and even then it might take a while before we know the answer.

 

[FyberOptic]

Hey.
I didnt red all the changes cause im sure i wont unterstand them.
But There is one question which im insterested in. Is it already clear if 1.9 modded mc is gonna happen?

I can't speak for Forge but I've been modding it for months.

 

[HeroWing2]

Ok thanks for Your answer .
I hope it will because of all the things that changed.
But if it doesnt happen, it wont happen at all.
What do you think

 

[FyberOptic]

Ok thanks for Your answer .
I hope it will because of all the things that changed.
But if it doesnt happen, it wont happen at all.
What do you think

I think it's safe to say that 1.9 will be the next big thing. 1.8 just didn't offer enough to motivate anyone to update, on top of the various issues involved. It's more a matter of how long it takes the Forge team to patch the decompiler they use to successfully recompile the game. Last I heard, they weren't even able to recompile 1.8.3 or later yet.

 

[ljfa]

Afaik right now they're putting their effort into making the decompiler work for 1.8.8. And then hopefully, decompiling generics will work as well.

 

[FyberOptic]

Hey I haven't posted anything here in forever.

I mentioned before how 1.9 changed how sounds are played, to use objects that you get from registering sounds, rather than specifying a string. They changed it slightly further now to where you also have to specify a sound category (aka a channel) that I suppose the sound plays through. The enum has entries like MASTER, MUSIC, RECORD, WEATHER, BLOCK, HOSTILE, etc. It's probably good to do such a thing, so that certain sounds could have a certain priority, or maybe to set the volume of certain things independently, etc.

Meanwhile, some other client-related things were moved out of the Block class. Things like colorMultiplier and getRenderColor are kind of merged now and handled in an entirely different way. There's an interface now with a single method that returns this value, however it's not implemented in the block classes themselves. Minecraft also now has a class that's kind of a block color override registry, and it has a method that registers a bunch of anonymous classes for various blocks to implement the interface's color override method for them. So basically, color override is independent from the block entirely.

They did the same thing with the Item class's getColorFromItemStack. It's in its own separate registry class, with its own separate interface for the override method, etc.

I guess I can kind of see minor advantages to it, but at the same time it's just one more thing to overcomplicate it all and have to do map lookups for. And of course one more thing to make porting mods more of a pain.

 

[Type1Ninja]

It's probably good to do such a thing, so that certain sounds could have a certain priority, or maybe to set the volume of certain things independently, etc.

It's not entirely clear whether you're aware of this, but you already CAN set channel volumes independently. I forget which version it was introduced in, but for sure in 1.8 and beyond the audio menu has separate sliders for each category.