
Starless
Members-
Posts
107 -
Joined
-
Last visited
Everything posted by Starless
-
I need to know which blocks around my block are inventories. This is what I have so far: for(EnumFacing facing : EnumFacing.VALUES) { TileEntity te = worldObj.getTileEntity(pos.offset(facing)); //What else goes here? if it was before the capabilities thingy I'd do: //if(te instanceof IInventory) //but now I don't know how it's done. }
-
Since OreDictionary is not part of minecraft, there's no mapping for its fields, and I had to hack it a little bit (I don't change its state, I just hack it to obtain a particular set of information a bit faster). To do that, I had to use reflection to get a MethodHandle getter for field OreDictionary.stackToId. Does it changes to something else when running outside eclipse?
-
Do I have to register the Buckets for every fluid as Items? for example: Fluid nitric_acid = new Fluid("fluid_nitric-acid", new ResourceLocation(TheMod.MODID, "fluid_nitric-acid_still"),//I don't really know what to put here in these resource locations new ResourceLocation(TheMod.MODID, "fluid_nitric-acid_flowing")); FluidRegistry.registerFluid(nitric_acid); FluidRegistry.addBucketForFluid(nitric_acid); Now if I need to register in the oreDictionary something like OreDictionary.registerOre("bucketNitricAcid", [what goes here?]); Oh, and also, what should be the resource locations there?
-
[1.10.2] what's the purpose of INBTSerializable?
Starless replied to Starless's topic in Modder Support
Ok, so just to see if I understood you correctly, we no longer need to implement readFromNBT and writeToNBT , as long as we implement INBTSerializable? -
Does the interface INBTSerializable<T extends NBTBase> obsoletes Entity#readFromNBT and Entity#writeToNBT?
-
So, to make it clear, because the forum post got a bit confusing. a high value to modifier in your method replaceModifier increases the damage in case the attribute is ATTACK_DAMAGE and it decreases the weapon cooldown in case the attribute is ATTACK_SPEED ? Looking into Entity#rotationYaw I found out there's a method Entity#getAdjustedHorizontalFacing() , which will make it even easier.
-
I want to make an ItemKnife , that will inherit from ItemSword . I want a few things from this item: [*]the main one is I want to make it attack faster. (have a lower cooldown). Is it possible. If so, how? [*]Also, I suppose the best way of reducing it's damage is using Reflection to change ItemSword.attackDamage just for the knife, correct? Or should I override ItemSword.getDamageVsEntity instead? (not sure which of the two options is less hacky. What is usually prefered by the community?) [*]I want the item to be used in craft recipes but not get consumed in the process, how can I do that? [*]I want this item to deal more damage when used from behind the enemy if the attacker is sneaking. And an even greater damage if the attacker is behind the target, is invisible and is sneaking. I believe the best place to implement this logic would be in a handler of AttackEntityEvent , right? Handling events can be expensive, but I don't see an alternative. [*]still, the problem is, how do I know the target has its back turned to the attacker?
-
Official documentation seems to be outdated. The mod that Ernio linked is poorly documented (as in not a single comment in the entire file, let alone a javadoc comment). I will check what you linked. EDIT: I still cannot make sense of this. Capabilities are the most unintuitive and esoteric programming constructs I've ever came across in my life. I know "what" they are, but the code just looks like random memory dump turned to Java. Nevermind this. I can live without it. Until someone writes a tutorial about it, I'm staying as far away from this thing as possible.
-
I believe now I have a much better understanding of it. So I can basically attach capabilities to whatever I want, this is what they are good for. Under normal circumstances we stick to Java, unless it is something that feels like it is "attachable" to anything. So if I had an interface like this: public interface IFireExtinguisher { //looks around in a 5x5x5 cube around it for fire and extiguishes all it finds. public void extinguish(); } That could be attached to an Item or a TileEntity or an EntityLiving, for example, in an ItemStack it could be the onRightClick effect. On a Block it could be invoked during a the random tick, and so on. Is this correct? Edit: How would I create the Capability for that?
-
Ok... Is this necessary for TileEntities or can I just worldIn.getTileEntityAt(pos) instanceof IAccountableInventory What I mean is, is this the de facto pattern for everything? Will other mods look for Capabilities instead of interfaces? or is the capability system more like a replacement for IEEP? I really mean it when I say I'm completely lost. I couldn't totally misunderstand the point of Capabilities, because I have not formed an understanding of them yet.
-
I'm sorry, I thought I edited the word "Item" out of the original post. It's just a class. It's an abstraction of an inventory, and plays a similar role to ItemStackHandler, I think. If you want to have an inventory with the extra functions of an IAccountableInventory you can simply put an object of my class that implements it and expose the methods by delegating them. Like This: public class AGameObject extends [TileEntity or Entity, or whatever] implements IAccountableInventory { IAccountableInventory interntalInvetory = new InventoryMapped() @Override public ItemStack implementationOfInterfaceMethod() { return interntalInvetory.implementationOfInterfaceMethod() } }
-
My object is like an abstraction of an inventory, much similar to ItemStackHandler, but it adds fuctionality like it always knows where to find an Item stack of a certain type, and etc. It implements an interface I created called IAccountableInventory. This object will play the role of the internal invetory for every Tile Entity that requires the extra functionalities it adds, The tile entity will expose this inventory by implementing the Interface and delegating all the method invocations to the underlying object. So should I create a capability to mirror IAcountableInventory? Who should expose the capability: the object that implements it? the Entity/TileEntity/ItemStack wrapping the object? And how would that be done?
-
I have an Item that implements IItemHandler, IItemHandlerModifiable, INBTSerializable<NBTTagList> It's not a TileEntity or an actual object in the game. It's an inventory that a TileEntity could use as its internal inventory. Should I implement a capability for it? how? I'm still completely lost in this capability thing (even after reading the documentation), so, please, if possible, explain it to me like I'm retarded.
-
How to use the OreDictionary to see if an ItemStack matches an OreDictionary entry? For example, imagine I have a mob that drops a different kind of slimeballs, but I want them to have all uses other slimeballs have, so I register it OreDictionary.registerOre("slimeball", MyModItems.MySlimeBall); Now imagine I have a slime shooting rifle or something, with an internal inventory where I can put only slimeballs, but I want to be able to put any item that is registered as "slimeball" in the OreDictionary. public class SmileBallRifleInventory { public boolean isSlimeBall(ItemStack stack) { //what would go inside this method? } }
-
Is there something like this: int burnTime = FuelRegistry.getBurnTime(ItemStack stack); If not, it would be great if there was. And also, how do I achieve the same as the code above in case there is no equivalent to it.
-
implementing IWorldGenerator (this will be my first time doing this) makes me able to influence a chunk when it is first loaded, right? Is there a way to affect a chunk that has already been loaded, but only once? Is there a way place where all already generated chunks get stored? If there is, I think I could probably iterate through this list once and manually generate my ore according to some algorithm, and then create byte of data signaling that post world generation ajustments already been made. So the post generation algorithm will never be called again. This is my first idea on how to approach the problem, but it depends on having already visited chunks stored in a list. Any help?
-
it's not that complicated, but it was perfectly good the way it was, and it just added extra steps to something that could be done easily. maybe the idea behind capabilities is the right way to go, and their implementation just need better a designing. Like when networking used to be so complicated and then became this beautiful elegant system it is now. Capabilities might get there too.