Info about coming 1.13 changes

[Draco18s]

Thought I'd share this here.

https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a

 

Skimming over it I see that there have been some (for the better) MCP name changes (BlockSnow -> BlockSnowLayer, BlockSnowBlock -> BlockSnow) and that non-lower-case registry names will now throw an error instead of silently converting it.

 

Lang files are now json (along with some other changes to the folder structure that are easily automated to update)

 

Advancements, functions, loot tables, recipes, and structures moved from assets/ to data/.

 

ALL metadata (magic numbers) is gone. e.g. Tool damage is now handled via NBT. Item variants that used metadata should be flattened (new Item instances); don't NBT hack your way to victory.

 

Remove your getMetaFromState/getStateFromMeta methods, they are no longer needed.

 

If you were saving blockstates using registry name + meta, you should now use NBTUtil.read/writeBlockstate. See how Endermen save their carried block for an example.

 

Worldgen is now its own separate thread(s). This may be a huge issue for some mods, as it will require a check for thread safety.

 

Block attributes (material or hardness) are now final. This is a bit of a disappointment for me, as while in 1.12 I wasn't fiddling with them, my old (un-updated) Harder Underground did increase the hardness of every shovel-diggable block. And I would like to do that again some day.

 

There's lots of superinterfaces on world now representing different things you can do (e.g. there's an interface for read-only access to the world). If possible, try using the least specific one. This makes sense to me and I support that notion. It'll probably be tough to get used to, but will be better in the end, as it reduces the reliance on World as a a hard reference and allows for alternate implementations without breaking stuff.

 

Multiple kinds of air. If you weren't already using IBlockState.isAir, now you have to.

[jabelar]

45 minutes ago, Draco18s said:

Advancements, functions, loot tables, recipes, and structures moved from assets/ to data/.

 

This is to support the concept of server-side "resource packs" right?

 

Thanks for the summary!

[Draco18s]

18 minutes ago, jabelar said:

This is to support the concept of server-side "resource packs" right?

I believe so.

There's also a note in there about custom recipes need to be synced with the client, but I'm unsure what that means exactly. It says "don't just send the JSON file to make the client reparse it," but there's no good information on what you should do.

[V0idWa1k3r]

I personally am more interested in forge changes although these changes are pretty big too.

Like I've heard that Lex wants to drop support for forgeblockstates and while that is understandable due to vanilla blockstates becoming a lot smarter with their predicates it is still sad for me as I've personaly been using forge blockstates everywhere. And submodels are a useful feature too.

Or for example that according to this quote "SidedProxy annotation will probably not be maintained. Replaced with using SidedExecutor." It sounds very interesting to me but I imagine it would be quite difficult for modmakers to drop using proxies and start using something they are not used to instead.

But going back to 1.13 generic changes there is now a tegs system that looks really promising. I wonder if it could in theory replace OreDictionary if handled properly.

1 hour ago, Draco18s said:

my old (un-updated) Harder Underground did increase the hardness of every shovel-diggable block. And I would like to do that again some day.

Couldn't you still kinda do that with a PlayerEvent.BreakSpeed? While it's not the same you could achieve identical functionality.

Edited July 19, 2018 by V0idWa1k3r

[Draco18s]

7 hours ago, V0idWa1k3r said:

Couldn't you still kinda do that with a PlayerEvent.BreakSpeed? While it's not the same you could achieve identical functionality.

Yes, its just that you have to do a lot of backwards math in some cases. You need to divide out the player's current tool (this is not a simple thing to do), modify the value, then multiply it back in.

 

Oh, and you can't modify...

Mining machines that don't use a fake player

Explosion power (e.g. the block resistance property)

"3x3" tools that don't (correctly / at all) fire events for secondary blocks

Edited July 20, 2018 by Draco18s

[jt9]

Having flattened all my mod's blocks, I welcome the removal of metadata! Holding variants and properties in one block and having to deal with that was a total pain. Also hoping for flexibility in waterlogged blockstates, I will be using that a lot. I can definitely see how it might be tough to get used to multiple superinterfaces for the World, but shouldn't be much of an issue once people get used to it.

 

That said, would having world gen on separate threads be much of an issue if you're only dealing with small additions? GameRegistry.registerWorldGenerator() has an argument for generation weight, that should be useful in avoiding issues, yes?

 

 

[loordgek]

one thing that is not in there

forgegradle is getting a complete rewrite

https://github.com/amadornes/ForgeGradle

 

https://discord.gg/SvwkCaa

the discord channel where you can get info about

[jabelar]

It all sounds pretty good .... except the fact that it means major rewrites for any mods you want to port forward. I'm really, really hoping that the interfaces settle down so that the maintenance of existing mods becomes less of a chore. Anyone that has more than a couple mods literally has to spend weeks, even months (if you include thorough testing and assume that hobbyists can only spend a couple hours per day working on it) to bring them up to each upgrade. For example, the flattening makes a lot of sense but I can imagine a person with a mod with dozens of sophisticated blocks will have significant work in front of them. 

 

My dream is that someday any big updates to Minecraft or Forge are simply content and not the API mechanisms. Then we would truly have a proper API. 

 

Thanks to everyone on the Forge team though doing the work to keep up with all this!

[Draco18s]

I rarely used variants when the variants were actual variants.

The flowers in my Ore Flowers mod is pretty much the only thing at this point, and flattening it won't take too much work. Everything else is actually a property (Facing, Value, etc)

[Pheenixm]

On 7/19/2018 at 12:51 PM, Draco18s said:

  

Block attributes (material or hardness) are now final. This is a bit of a disappointment for me, as while in 1.12 I wasn't fiddling with them, my old (un-updated) Harder Underground did increase the hardness of every shovel-diggable block. And I would like to do that again some day.

 

 

I've been updating my old mod lately, and I just finished work on a chunk injection system you may find interesting. Rarely, it'll cause a crash due to strange ticking issues, but if you wanted to play around with the code, I'd be happy to share it with you, especially if you have any ideas on how to fix the crashes that occur if you try to process anything north of 500 chunks at a time. Premise is copying a chunk's data with reflection in separate threads, making whatever changes you want in a multithreaded system, then re-injecting them back into the chunk map with entity tick events such that it's completely thread safe. You could theoretically use that to replace blocks on demand.

 

https://bitbucket.org/Pheenixm/explosivesplus/src/master/Explosives%2B/src/main/java/com/pheenixm/explosivesplus/common/chunker/

Edited July 24, 2018 by Pheenixm
Expanded link to specific folder