Alpvax

What is the recommended way to sync capability data if it needs to be synced each time the entity is loaded from NBT?

Ah, thanks a lot!

I am recieving a NullPointerException when sending a packet to the client, but I'm not sure what is actually null. I know that my pipeline works, as I have sent packets the other way without a problem. My packet system uses the Mantle library to simplify things. Exception: addAbility: public void addAbility(Ability ability) { if(!MinecraftForge.EVENT_BUS.post(new AbilityEvent.Add(this, ability))) { UUID id = ability.getID(); Preconditions.checkArgument(!abilities.containsKey(id), "Already an ability with that id: %s", id); ability.onEquip(); abilities.put(id, ability); if(getAttachedObject() instanceof EntityPlayerMP) { CharacterNetwork.sendTo(new AbilityChangedPacket(id, ability), getAttachedObject()); } } } Packet: public class AbilityChangedPacket extends AbstractPacket.Threadsafe { UUID id; Ability ability; public AbilityChangedPacket() {} public AbilityChangedPacket(@Nonnull UUID id, @Nullable Ability ability) { this.id = id; this.ability = ability; } @Override public void fromBytes(ByteBuf buf) { id = new UUID(buf.readLong(), buf.readLong()); String name = ByteBufUtils.readUTF8String(buf); System.err.println(name);//XXX /*if(!name.equals("ability.remove")) { ability = ClientObjectFactoryRegistry.createAbility(name, CharacterOverhaul.proxy.getClientCharacter()); if(ability != null) { ability.readClientData(ByteBufUtils.readTag(buf)); } }*/ } @Override public void toBytes(ByteBuf buf) { buf.writeLong(id.getMostSignificantBits()); buf.writeLong(id.getLeastSignificantBits()); /*if(ability != null) { ByteBufUtils.writeUTF8String(buf, ability.getClass().getName()); ByteBufUtils.writeTag(buf, ability.getNBTForClientSync()); } else {*/ ByteBufUtils.writeUTF8String(buf, "ability.remove"); //} } /*@Override public IMessage handleClient(NetHandlerPlayClient netHandler) { FMLCommonHandler.instance().getWorldThread(netHandler).addScheduledTask(new Runnable() { @Override public void run() { //CharacterOverhaul.proxy.getClientCharacter().updateClientAbility(id, ability); } }); return null; } @Override public IMessage handleServer(NetHandlerPlayServer netHandler) { throw new RuntimeException("AbilityChangedPacket recieved on server! How did this happen!"); }*/ @Override public void handleClientSafe(NetHandlerPlayClient netHandler) { //CharacterOverhaul.proxy.getClientCharacter().updateClientAbility(id, ability); } @Override public void handleServerSafe(NetHandlerPlayServer netHandler) { throw new RuntimeException("AbilityChangedPacket recieved on server! How did this happen!"); } }

You are checking whether the whole block is solid, you want to just check the side that is facing your lantern. It used to be a method along the lines of isSideSolid(facing, pos) but it might have changed.

My use is holding a map of classess for an RPG style mod, with the potential for other mods to add classes. The classes are required on both sides, but will be set via a GUI. How should I go about syncing the data, I am currently sending the ResourceLocation of the class as a string in my packets.

I understand the difference in general terms, it is for synching and sharing data across client and server. But for my own registry, which would be better to use and why? If possible could I have some use cases for each.

First time I have heard of the mod list json. Out of curiosity, would it also load mods from the mods directory, or just those specified by the list?

Would a better solution not be to do an item.isvalidforslot check of some description? That way the player couldn't click the item into the offhand slot either.

My only suggestion would be YAML. I know it isn't perfect, I would rather have the braces there to show the hierachy, but it allows comments in addition to everything JSON allows (as far as I am aware). Alternatively someone could write a custom format (probably JSON-based) that allows comments. It could even be as simple as a custom JSON parser.

When I have done this previously, I had to shrink the collision box fractionally, as the collision wouldn't register unless the entity was inside the block space. I am not sure if this has been changed or if it is still the case. I am also unsure how that would work with the new model system, as the last time I did it was around 1.3, so I could easily have the textures remain the full block, but the collision fractionally smaller.

So I will be instantiating some of my classes from NBTTagCompounds as well as from other methods, and I need to be able to pass in a variable number of variable-type arguments. I could either pass them in as a Map<String,Object> or pass in an NBTTagCompound, and just keep a reference to the nbt inside my instance. Obviously the latter would be easier, and is what entities and itemstacks do, but what is the additional overhead vs a HashMap?

Sorry for a bit of a Necro, but I am now having the same issue. Could you please tell me how you solved it

The scale and the abuse are two reasons why I haven't written an implementation. However I like the idea, and would use it if it was implemented.

I think the plan from here would be to create the API then submit a PR. The issue with a standalone API is that no-one hears about it for a long time.

The "not all may want to support it" argument is pointless, you could say exactly the same thing about forge itself. If they don't want to support it they won't, but what reason would they have not to? The macerator dictionary would be useful for a single (or maybe a couple of) blocks from a few mods. A heat dictionary would allow for better control and differentiation between light level and heat for melting blocks like ice. It would also simplify mechanics such as factorizations furnace heater. And where is the logic in a standard torch being hot enough to heat a crucible but a furnace heater isn'? This would become a compatibility layer, which makes forge the perfect place for it

I would imagine any calculation would be done when the heat level is checked, so if no mod uses it no processing is done. Not quite the same as light. However if it was implemented alongside light it wpuld allow for a better implementation of ice melting. (Based on heat level as opposed to light level) and wouldnt need to constantly check heat level

I did not even think of that, I was just basing it purely off the vanilla code, but you have a good point. maybe it should just be a new method in Item, that way it could be called for any "visible" Item.

Within World.getClosestVunerablePlayer there is an invisibility check (if mobs can't see you they won't attack) which also calls EntityPlayer.getArmourVisibility: /** * When searching for vulnerable players, if a player is invisible, the return value of this is the chance of seeing * them anyway. */ public float getArmorVisibility() { int i = 0; ItemStack[] aitemstack = this.inventory.armorInventory; int j = aitemstack.length; for (int k = 0; k < j; ++k) { ItemStack itemstack = aitemstack[k]; if (itemstack != null) { ++i; } } return (float)i / (float)this.inventory.armorInventory.length; } I think there should be some check for the armour being invisible (mmmPowersuits comes to mind), or semi-visible. /** * When searching for vulnerable players, if a player is invisible, the return value of this is the chance of seeing * them anyway. */ public float getArmorVisibility() { float f = 0; ItemStack[] aitemstack = this.inventory.armorInventory; int j = aitemstack.length; for (int k = 0; k < j; ++k) { ItemStack itemstack = aitemstack[k]; if (itemstack != null) { //new function that returns the opacity of the ItemStack. default implementation would return 1.0F (i.e. fully opaque). f += itemstack.getItem().getVisibility(itemstack); } } return f / (float)this.inventory.armorInventory.length; } I would have suggested adding this check to ItemArmor, but due to the fact that any item can be armour, it would have to be a general method. Alternatively it could be part of a new interface IArmor, and the isValidArmor method would return if the item was an instanceof IArmor public interface IArmor { public ItemArmor.ArmorMaterial getArmorMaterial(); //various other armor-related methods could be moved across public float getArmorOpacity(ItemStack stack); } and the check would become: Item item = itemstack.getItem(); f += item instanceof IArmor ? ((IArmor)item).getArmorOpacity(itemstack) : 1.0F;

Heat would work similarly to light, it would decrease depending on distance travelled, and certain blocks would decrease it more than others (based on hardness and material) the numbers need to be worked on, and there would have to be some agreement between modders, but the idea itself would be useful

Sorry to bother you, but how would you define the path? from which directory? or just using the package structure?

Solved it, My .zip was actually a .rar with the extension changed

Hate to revive a dead thread, this is marked as solved, however I don't see a solution. Could somebody point out whatever I'm missing, as I have the same problem.

Everywhere I look, people are referencing the "forge folder" which forge folder would this be? I cannot see any forge folder, only ".gradle", "build", "eclipse", "gradle" and "src". (of course, .gradle doesn't show up in Eclipse)

Thanks for the confirmation, I didn't think so. GUI class (will be re-written at some point, its a tad messy, but I know it works as it appears when I kill myself (EntityJoinWorldEvent launches it)) And my proxy/ GUIHandler methods

Which means it should always open at this point ? I guess there is something wrong in your gui handling code, then. Correct, it should always open the first time a player logs into a new world / server. My server-side gui element is returned as null, is that what is causing the problem? Do I have to make a blank container as the gui consists of nothing but buttons, which send a packet to the server when clicked, and close the GUI