Jump to content

Recommended Posts

Posted

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?

Posted

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

Posted

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?

Posted

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

Posted

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

Posted

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.

Posted

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

Posted

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.

Posted

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.

Posted

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

Posted

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.

Posted

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

how to debug 101:http://www.minecraftforge.net/wiki/Debug_101

-hydroflame, author of the forge revolution-

Posted

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

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

Posted

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

Posted

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

Posted

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

Posted

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

Posted

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.

Bumper Cars!

Guest
This topic is now closed to further replies.

Announcements




  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • Version 1.19 - Forge 41.0.63 I want to create a wolf entity that I can ride, so far it seems to be working, but the problem is that when I get on the wolf, I can’t control it. I then discovered that the issue is that the server doesn’t detect that I’m riding the wolf, so I’m struggling with synchronization. However, it seems to not be working properly. As I understand it, the server receives the packet but doesn’t register it correctly. I’m a bit new to Java, and I’ll try to provide all the relevant code and prints *The comments and prints are translated by chatgpt since they were originally in Spanish* Thank you very much in advance No player is mounted, or the passenger is not a player. No player is mounted, or the passenger is not a player. No player is mounted, or the passenger is not a player. No player is mounted, or the passenger is not a player. No player is mounted, or the passenger is not a player. MountableWolfEntity package com.vals.valscraft.entity; import com.vals.valscraft.network.MountSyncPacket; import com.vals.valscraft.network.NetworkHandler; import net.minecraft.client.Minecraft; import net.minecraft.network.syncher.EntityDataAccessor; import net.minecraft.network.syncher.EntityDataSerializers; import net.minecraft.network.syncher.SynchedEntityData; import net.minecraft.server.MinecraftServer; import net.minecraft.server.level.ServerPlayer; import net.minecraft.world.entity.EntityType; import net.minecraft.world.entity.Mob; import net.minecraft.world.entity.ai.attributes.AttributeSupplier; import net.minecraft.world.entity.ai.attributes.Attributes; import net.minecraft.world.entity.animal.Wolf; import net.minecraft.world.entity.player.Player; import net.minecraft.world.entity.Entity; import net.minecraft.world.InteractionHand; import net.minecraft.world.InteractionResult; import net.minecraft.world.item.ItemStack; import net.minecraft.world.item.Items; import net.minecraft.world.level.Level; import net.minecraft.world.phys.Vec3; import net.minecraftforge.event.TickEvent; import net.minecraftforge.eventbus.api.SubscribeEvent; import net.minecraftforge.network.PacketDistributor; public class MountableWolfEntity extends Wolf { private boolean hasSaddle; private static final EntityDataAccessor<Byte> DATA_ID_FLAGS = SynchedEntityData.defineId(MountableWolfEntity.class, EntityDataSerializers.BYTE); public MountableWolfEntity(EntityType<? extends Wolf> type, Level level) { super(type, level); this.hasSaddle = false; } @Override protected void defineSynchedData() { super.defineSynchedData(); this.entityData.define(DATA_ID_FLAGS, (byte)0); } public static AttributeSupplier.Builder createAttributes() { return Wolf.createAttributes() .add(Attributes.MAX_HEALTH, 20.0) .add(Attributes.MOVEMENT_SPEED, 0.3); } @Override public InteractionResult mobInteract(Player player, InteractionHand hand) { ItemStack itemstack = player.getItemInHand(hand); if (itemstack.getItem() == Items.SADDLE && !this.hasSaddle()) { if (!player.isCreative()) { itemstack.shrink(1); } this.setSaddle(true); return InteractionResult.SUCCESS; } else if (!level.isClientSide && this.hasSaddle()) { player.startRiding(this); MountSyncPacket packet = new MountSyncPacket(true); // 'true' means the player is mounted NetworkHandler.CHANNEL.sendToServer(packet); // Ensure the server handles the packet return InteractionResult.SUCCESS; } return InteractionResult.PASS; } @Override public void travel(Vec3 travelVector) { if (this.isVehicle() && this.getControllingPassenger() instanceof Player) { System.out.println("The wolf has a passenger."); System.out.println("The passenger is a player."); Player player = (Player) this.getControllingPassenger(); // Ensure the player is the controller this.setYRot(player.getYRot()); this.yRotO = this.getYRot(); this.setXRot(player.getXRot() * 0.5F); this.setRot(this.getYRot(), this.getXRot()); this.yBodyRot = this.getYRot(); this.yHeadRot = this.yBodyRot; float forward = player.zza; float strafe = player.xxa; if (forward <= 0.0F) { forward *= 0.25F; } this.flyingSpeed = this.getSpeed() * 0.1F; this.setSpeed((float) this.getAttributeValue(Attributes.MOVEMENT_SPEED) * 1.5F); this.setDeltaMovement(new Vec3(strafe, travelVector.y, forward).scale(this.getSpeed())); this.calculateEntityAnimation(this, false); } else { // The wolf does not have a passenger or the passenger is not a player System.out.println("No player is mounted, or the passenger is not a player."); super.travel(travelVector); } } public boolean hasSaddle() { return this.hasSaddle; } public void setSaddle(boolean hasSaddle) { this.hasSaddle = hasSaddle; } @Override protected void dropEquipment() { super.dropEquipment(); if (this.hasSaddle()) { this.spawnAtLocation(Items.SADDLE); this.setSaddle(false); } } @SubscribeEvent public static void onServerTick(TickEvent.ServerTickEvent event) { if (event.phase == TickEvent.Phase.START) { MinecraftServer server = net.minecraftforge.server.ServerLifecycleHooks.getCurrentServer(); if (server != null) { for (ServerPlayer player : server.getPlayerList().getPlayers()) { if (player.isPassenger() && player.getVehicle() instanceof MountableWolfEntity) { MountableWolfEntity wolf = (MountableWolfEntity) player.getVehicle(); System.out.println("Tick: " + player.getName().getString() + " is correctly mounted on " + wolf); } } } } } private boolean lastMountedState = false; @Override public void tick() { super.tick(); if (!this.level.isClientSide) { // Only on the server boolean isMounted = this.isVehicle() && this.getControllingPassenger() instanceof Player; // Only print if the state changed if (isMounted != lastMountedState) { if (isMounted) { Player player = (Player) this.getControllingPassenger(); // Verify the passenger is a player System.out.println("Server: Player " + player.getName().getString() + " is now mounted."); } else { System.out.println("Server: The wolf no longer has a passenger."); } lastMountedState = isMounted; } } } @Override public void addPassenger(Entity passenger) { super.addPassenger(passenger); if (passenger instanceof Player) { Player player = (Player) passenger; if (!this.level.isClientSide && player instanceof ServerPlayer) { // Send the packet to the server to indicate the player is mounted NetworkHandler.CHANNEL.send(PacketDistributor.PLAYER.with(() -> (ServerPlayer) player), new MountSyncPacket(true)); } } } @Override public void removePassenger(Entity passenger) { super.removePassenger(passenger); if (passenger instanceof Player) { Player player = (Player) passenger; if (!this.level.isClientSide && player instanceof ServerPlayer) { // Send the packet to the server to indicate the player is no longer mounted NetworkHandler.CHANNEL.send(PacketDistributor.PLAYER.with(() -> (ServerPlayer) player), new MountSyncPacket(false)); } } } @Override public boolean isControlledByLocalInstance() { Entity entity = this.getControllingPassenger(); return entity instanceof Player; } @Override public void positionRider(Entity passenger) { if (this.hasPassenger(passenger)) { double xOffset = Math.cos(Math.toRadians(this.getYRot() + 90)) * 0.4; double zOffset = Math.sin(Math.toRadians(this.getYRot() + 90)) * 0.4; passenger.setPos(this.getX() + xOffset, this.getY() + this.getPassengersRidingOffset() + passenger.getMyRidingOffset(), this.getZ() + zOffset); } } } MountSyncPacket package com.vals.valscraft.network; import com.vals.valscraft.entity.MountableWolfEntity; import net.minecraft.network.FriendlyByteBuf; import net.minecraft.server.level.ServerLevel; import net.minecraft.server.level.ServerPlayer; import net.minecraft.world.entity.Entity; import net.minecraft.world.entity.player.Player; import net.minecraftforge.network.NetworkEvent; import java.util.function.Supplier; public class MountSyncPacket { private final boolean isMounted; public MountSyncPacket(boolean isMounted) { this.isMounted = isMounted; } public void encode(FriendlyByteBuf buffer) { buffer.writeBoolean(isMounted); } public static MountSyncPacket decode(FriendlyByteBuf buffer) { return new MountSyncPacket(buffer.readBoolean()); } public void handle(NetworkEvent.Context context) { context.enqueueWork(() -> { ServerPlayer player = context.getSender(); // Get the player from the context if (player != null) { // Verifies if the player has dismounted if (!isMounted) { Entity vehicle = player.getVehicle(); if (vehicle instanceof MountableWolfEntity wolf) { // Logic to remove the player as a passenger wolf.removePassenger(player); System.out.println("Server: Player " + player.getName().getString() + " is no longer mounted."); } } } }); context.setPacketHandled(true); // Marks the packet as handled } } networkHandler package com.vals.valscraft.network; import com.vals.valscraft.valscraft; import net.minecraft.resources.ResourceLocation; import net.minecraftforge.network.NetworkRegistry; import net.minecraftforge.network.simple.SimpleChannel; import net.minecraftforge.network.NetworkEvent; import java.util.function.Supplier; public class NetworkHandler { private static final String PROTOCOL_VERSION = "1"; public static final SimpleChannel CHANNEL = NetworkRegistry.newSimpleChannel( new ResourceLocation(valscraft.MODID, "main"), () -> PROTOCOL_VERSION, PROTOCOL_VERSION::equals, PROTOCOL_VERSION::equals ); public static void init() { int packetId = 0; // Register the mount synchronization packet CHANNEL.registerMessage( packetId++, MountSyncPacket.class, MountSyncPacket::encode, MountSyncPacket::decode, (msg, context) -> msg.handle(context.get()) // Get the context with context.get() ); } }  
    • Do you use features of inventory profiles next (ipnext) or is there a change without it?
    • Remove rubidium - you are already using embeddium, which is a fork of rubidium
  • Topics

×
×
  • Create New...

Important Information

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