Jump to content

Minecraft 1.7 - News


LexManos

Recommended Posts

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?

Link to comment
Share on other sites

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 :)

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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)?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

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)

ItemBlock is not a Block

ItemStack is not an Item

Damage value is not metadata

 

Stop confusing them.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

 

 

 

 

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :P

Link to comment
Share on other sites

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.

The difference between stupidity and genius is that genius has its limits. - Albert Einstein

Link to comment
Share on other sites

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.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

Announcements




  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • Update your AMD/ATI drivers - get the drivers from their website - do not update via system  
    • As the title says i keep on crashing on forge 1.20.1 even without any mods downloaded, i have the latest drivers (nvidia) and vanilla minecraft works perfectly fine for me logs: https://pastebin.com/5UR01yG9
    • Hello everyone, I'm making this post to seek help for my modded block, It's a special block called FrozenBlock supposed to take the place of an old block, then after a set amount of ticks, it's supposed to revert its Block State, Entity, data... to the old block like this :  The problem I have is that the system breaks when handling multi blocks (I tried some fix but none of them worked) :  The bug I have identified is that the function "setOldBlockFields" in the item's "setFrozenBlock" function gets called once for the 1st block of multiblock getting frozen (as it should), but gets called a second time BEFORE creating the first FrozenBlock with the data of the 1st block, hence giving the same data to the two FrozenBlock :   Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=head] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@73681674 BlockEntityData : id:"minecraft:bed",x:3,y:-60,z:-6} Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=3, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=2, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} here is the code inside my custom "freeze" item :    @Override     public @NotNull InteractionResult useOn(@NotNull UseOnContext pContext) {         if (!pContext.getLevel().isClientSide() && pContext.getHand() == InteractionHand.MAIN_HAND) {             BlockPos blockPos = pContext.getClickedPos();             BlockPos secondBlockPos = getMultiblockPos(blockPos, pContext.getLevel().getBlockState(blockPos));             if (secondBlockPos != null) {                 createFrozenBlock(pContext, secondBlockPos);             }             createFrozenBlock(pContext, blockPos);             return InteractionResult.SUCCESS;         }         return super.useOn(pContext);     }     public static void createFrozenBlock(UseOnContext pContext, BlockPos blockPos) {         BlockState oldState = pContext.getLevel().getBlockState(blockPos);         BlockEntity oldBlockEntity = oldState.hasBlockEntity() ? pContext.getLevel().getBlockEntity(blockPos) : null;         CompoundTag oldBlockEntityData = oldState.hasBlockEntity() ? oldBlockEntity.serializeNBT() : null;         if (oldBlockEntity != null) {             pContext.getLevel().removeBlockEntity(blockPos);         }         BlockState FrozenBlock = setFrozenBlock(oldState, oldBlockEntity, oldBlockEntityData);         pContext.getLevel().setBlockAndUpdate(blockPos, FrozenBlock);     }     public static BlockState setFrozenBlock(BlockState blockState, @Nullable BlockEntity blockEntity, @Nullable CompoundTag blockEntityData) {         BlockState FrozenBlock = BlockRegister.FROZEN_BLOCK.get().defaultBlockState();         ((FrozenBlock) FrozenBlock.getBlock()).setOldBlockFields(blockState, blockEntity, blockEntityData);         return FrozenBlock;     }  
    • It is an issue with quark - update it to this build: https://www.curseforge.com/minecraft/mc-mods/quark/files/3642325
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.