Minecraft 1.7 - News

[mrgreaper]

  On 10/30/2013 at 4:16 PM, LexManos said:

As the mojang blog post said, the major changes: IDs go bye bye, Networking System switched to netty, Sound system overhaul.

So yes when it comes to packets, things will change.

 

wait... IDs go bye bye? you mean block and item ids? that seems more then an update and more of a complete overhaul

are you sure? do you have a link to the source?

[mrgreaper]

(excuse the double post but when ever i go to edit my last one it blanks it)

 

I looked over the blog and see nothing about IDs being taken away.

[Mazetar]

Looking at the blog again, yeah it dosen't clearly state that IDs are gone, only that you will now use names for /give block and other commands.

Anyways IDs are finaly gone.

 

For a forge user and non-modder this just means that the update will take a while but also that there won't be anymore stupid id block conflicts to solve

[Morkeleb]

Indeed it will solve the Id conflicts, but there is quite some overlap between mods which means item names may be chosen the same.

This is for instance why the ore dictionary exists so the same ores can coexist between mods.

I think there will be a need for a unified dictionary of item names to avoid unresolvable conflicts between mods.

 

Has anybody thought about something like this yet?

[Joose]

  On 11/4/2013 at 10:46 AM, Morkeleb said:

Indeed it will solve the Id conflicts, but there is quite some overlap between mods which means item names may be chosen the same.

This is for instance why the ore dictionary exists so the same ores can coexist between mods.

I think there will be a need for a unified dictionary of item names to avoid unresolvable conflicts between mods.

 

Has anybody thought about something like this yet?

 

I got the impression that the idea was to use prefixes for different mods, atleast the default item names in Minecraft have a "minecraft:" prefix, eg. /give player minecraft:command_block

[thebombzen]

If Block and Item IDs are gone, I assume that in configuration files, users will have to use the unlocalized block name rather than the ID (which won't exist). However, previously there was a very easy way to specify both the ID and metadata of a block (Users could specify spruce logs using ID:Meta as in 17:1). Now, how will users specify both the ID and metadata of the block? Or is this not necessary because different variations of the same block (e.g. Spruce Logs) get their own identifier? If different block variations get their own identifier, how will we specify a global identifier (as in all wool blocks or all logs), and if each variation uses the same identifier, how will we specify specific variations or specific damage values (for items)?

[GotoLink]

Well, if IDs are gone, they should be replaced by "unlocalized names". Considering you can already prefix those with your modid, it is guaranteed to not conflict anymore...thus you no longer need to put them into a configuration file.

 

@thebombzen

Metadata support in configuration files is entirely on the modder's hands as of now.

If IDs are gone and replaced by unique names, metadata would be useless, due to "infinite" possibilities of different blocks.

That doesn't mean it will be removed, since it can help organize things like planks, logs, leaves...but no modder would need to use them to reduce the block ids used.

[LexManos]

Back from Minecon, catching up on BS that happened while I was gone.

Anyways to answer simple question. AGAIN Block IDs are moved into a central registry, and when it comes to how you REFERENCE blocks and items. Don't be stupid you should not query the registry for EVERY access, that would be a massive waist of time.

This is a example of vanillai:

    REGISTRY.register(256, "minecraft:iron_shovel", new ItemShovel(IRON)...);
    REGISTRY.register(257, "minecraft:iron_pickaxe", new ItemPickaxe(IRON)...);
    REGISTRY.register(258, "minecraft:iron_axe", new ItemAxe(Item.Tier.IRON)...);
    REGISTRY.register(259, "minecraft:flint_and_steel", new ItemFlintAndSteel()...);
    REGISTRY.register(260, "minecraft:apple", new ItemFood(4, 0.3F, false)...);

  public static final Item IRON_SHOVEL =  REGISTRY.get("minecraft:iron_shovel");
  public static final Item IRON_PICKAXE = REGISTRY.get("minecraft:iron_pickaxe");
  public static final Item IRON_AXE = REGISTRY.get("minecraft:iron_axe");
  public static final Item FLINT_AND_STEEL = REGISTRY.get("minecraft:flint_and_steel");
  public static final Item APPLE = REGISTRY.get("minecraft:apple");

And as such you simply do itemStack.getItem() == IRON_SHOVEL and you're done zero fucks to be given about ids.

IN Forge we will most likely completely and utterly ignore the first parameter to REGISTRY.register, vanilla adds it manually so they can keep old world compatibility. In Forge we can ignore it and assign IDs ourselves. NOWHERE else in code should IDs be referenced, ever.

 

If you guys dont get it.. then well ya.. try harder...

[Akjosch]

The problem is that the Anvil file format still saves just 12 bytes off a blockID, meaning we don't gain much of anything ... yet.

 

(See aor.class for details)

[Heltrato]

You know i like the way how did they did to ID so no shit same ID errors again =]

 

[thebombzen]

  On 11/4/2013 at 11:56 PM, GotoLink said:

Well, if IDs are gone, they should be replaced by "unlocalized names". Considering you can already prefix those with your modid, it is guaranteed to not conflict anymore...thus you no longer need to put them into a configuration file.

 

@thebombzen

Metadata support in configuration files is entirely on the modder's hands as of now.

If IDs are gone and replaced by unique names, metadata would be useless, due to "infinite" possibilities of different blocks.

That doesn't mean it will be removed, since it can help organize things like planks, logs, leaves...but no modder would need to use them to reduce the block ids used.

 

When I say metadata, I'm not talking about metadata in terms of a workaround designed to make different blocks fit in less space, but rather a way to specify block properties (piston direction, wool color, etc.).

 

This brings another question (using wool as an example):

Will all wool blocks be referenced by the same String identifier, or will each color have its own identifier? If they have different identifiers, how will a mod programmer ask the registry if a block is any wool block? If they have the same identifier, how will a mod programmer ask the registry if a block is red wool?

 

EDIT: Also, when I said specify blocks in a configuration file I wasn't trying to allow the user to change a custom blockID to prevent ID conflicts. One of my mods switches tools based on the block the player's mining and it allows players to configure its behavior for specific blocks (e.g. avoid using fortune pickaxes on coal ore), which requires the user to specify which block they're referring to in the configuration file.

[Mazetar]

Forge? I would guess for sometime in December

[LexManos]

1.7 is a MAJOR change to the internal code, everyone is going to have to re-write a large chunk of there code as is. We ran into a bit of an issue with how the Mojang team coded certian parts of the games {Anonymous inner enum classes u.u} which has forced us to write a new set of programs to handle that. So the MCP team, cpw, and I have decided to do a bit of house cleaning and code reorganization to move the code base that you deal with in minecraft, closer to the official code base. Namely with the reconstruction of inner classes.

However, as this is a major change, we are taking it seriously, and making sure things are put through there passes. Names are cleaned up. We don't get this opportunity often, to re-name classes.. There are also other changes going on with MCP under the hood, that I don't know if i'm allowed to speak publicly about yet. But, I assume you we are working on it.

 

Admittedly, it is kinda annoying me off that it is taking so long to come out, but I know it's for the better.

Also, big shout out to AbrarSyed, his work on ForgeGradle is pretty much complete {still has the actual end-modder decompile process to do but meh}. If you guys wanna go check that out. I'm sure he will be glad to have testers. It's a little complicated to setup right now but will be ungodly easy once we actually pull in and start building this stuff officially.

 

Combine the work, with me being hit REALLY hard by the con flu, ya not good.

Anyways, just wanted to give another heads up, things are being worked on. The MCP team are working there buts off to get a good release out. But remember, one of the major players, Searge, was hired by Mojang. So he's working on both ends to make Minecraft better!

 

 

 

 

[joebobcedar]

:)Thanks for the continued ststus updates !

[FlyingPenguin]

How will all this new code affect forge updates in the future?

[ShortBus]

  On 11/17/2013 at 8:05 PM, FlyingPenguin said:

How will all this new code affect forge updates in the future?

 

I would assume that everything should be as it was before this update, until Mojang decides to update another million lines of code again.  Once MCP gets set then Forge can do their thing.  Future updates should only be minor in comparison because the basic structure will be in place.

[hydroflame]

According to what you can see out of the 1.7 update, do you think mojang is working toward an official modding api ?

[Mazetar]

Removal of BlockID's and updates to the sound system to use the ResourcePacks properly along with the complete rework of the network code. I'd say yes

[hydroflame]

weeeeeeeeeeeeelll crap my mod seralizer is useless then

[Rimevel]

How will this update affect "coremods"? Will it still be possible to replace vanilla items/blocks, alter game settings directly etc? I'm currently doing this in my survival mod to change some of the core gameplay of the game. Ofc without directly altering any Minecraft classes directly.

 

I guess I'm just a bit anxious about the update

[Like_a_block2013]

I know that the 1.7 code is a bitch to mod compared to 1.5 and 1.6. Anyway I digress I would like to know if you can guess how long it could take to get a running and stable build out? With all the holidays I would not be surprised if you say something about it being in 2014

[BigDaveNz]

As always "When It's done" applies here. It could release tomorrow, or in 5 years time. We don't know, and personally I don't care. All I know is that the Forge/MCP team are doing what they can to release for 1.7. And from what I've heard, 1.7 is not a "bitch" to mod, In the long run, it makes modding easier. It's just the changes are massive, and adjustments take time.

[LexManos]

For those who haven't seen: https://mojang.com/2013/11/minecraft-snapshot-13w48a/

We are working on it, there is a LOT of changes going on behind the scenes to make the codebase saner. And give everyone the ability to work on things how they want to.

Combine that with the fact that we knew 1.7.3 was coming, you can see why we are taking our time to get things done correctly.

MCP wise everything is looking great, I'm hounding on Abrar to get the gradle side for the update done. Then it's time to work.

We'll see how stable 1.7.3 is, and see if there's gunna be a 1.7.4.

 

Sadly, as MCP is a closed source thing {though some of it has become open} you guys can't see all the work we're doing but trust me, we're working on it. But re-doing almost the entire modding process is not a easy task.

[ThatBenderGuy]

  On 11/4/2013 at 8:53 AM, Mazetar said:

there won't be anymore stupid id block conflicts to solve

 

That will be incredibly useful! I'm fine with Forge taking a while to update as that will be amazing to not have to worry about id conflicts.

[ShortBus]

  On 11/27/2013 at 8:18 PM, LexManos said:

But re-doing almost the entire modding process is not a easy task.

 

And we (or at least I) appreciate everything you and the MCP/Forge teams are doing and have done.  Thanks for everything you do for us and the rest of the community!