Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Removing final on classes (Access Transformers)


HashtagShell
 Share

Recommended Posts

Some classes in Minecraft are final, probably the most commonly used being ItemStack. I need to subclass this class. Reflection cannot be used for this. So I added a line in my AT file

public-f net.minecraft.item.ItemStack

and rebuilt the workspace. ItemStack was not final. The AT file is being loaded, I successfully used it to make a field public. I looked through FG's and SS's sources, and it would seem to me that this should work, seeing that the final flag in the JVM is the same for classes and members. Making a class nonfinal should be possible with bytecode modification, so unless there is an explicit reason to disallow such ATs or there is a mistake on my part somewhere, I would see this as a bug.

I am essentially trying to get a callback on any edits that happen to a specific instance of an ItemStack (that I create), that is changes in the contained item, and, more importantly, its size. Usually, the way to do this is by creating a subclass. If there is any other way I will be happy to use that instead.

Edited by HashtagShell
Link to comment
Share on other sites

Please explain what you actually want to achieve (from an end-user perspective). Not how you intend to code it.

Subclassing ItemStack is a very bad idea, since your subclass instance will vanish as soon as the ItemStack is cloned, split, serialized, transferred to the client or any other mod starts interacting with it.

Link to comment
Share on other sites

I am afraid not. I am giving out an ItemStack to some unknown automation function, and if it makes any changes to it, I need to know about it to act upon those changes. The function also doesn't return execution to me (rather it calls my function through an interface call, and I return execution along with the ItemStack to it), so I cannot check for any changes, it has to be a callback on the setCount or whatever methods. Note that even if the function stores the instance around for a few years, and then changes it, I still want to act upon it.

 

I would see my subclass looking something like this:

public class ReflexiveStack extends ItemStack
{
  //Constructor
  
  @Override
  public void setCount(int count)
  {
    //Handle change
    super.setCount(count);
  }
}

 

Link to comment
Share on other sites

I actually want my subclass to vanish as soon as the item is serialised, cloned, etc.

Picture the following:

  1. Function gets an ItemStack instance from me
  2. It expects a reference to the same instance to exist in my code (ie. the stack is passed by reference)
  3. So it can edit the stack without the need to give it back to me
  4. Usually, this is fine, but I need to do extra things when it edits this particular instance, to simulate the "passed by reference" contract
  5. Once it clones, serialises, etc. the stack, the function can no longer expect the "passed by reference" contract to be kept, so I don't want to take any actions.
  6. If it needs this contract, it will re-query the instance from me, at which point #2 applies.
Link to comment
Share on other sites

7 minutes ago, HashtagShell said:

I am afraid not.

Not... what?

 

7 minutes ago, HashtagShell said:

I am giving out an ItemStack to some unknown automation function, and if it makes any changes to it, I need to know about it to act upon those changes.

As a last resort you can create a clone of the stack before you pass it in and then compare stuff later. What is this "automation function"?

 

8 minutes ago, HashtagShell said:

Note that even if the function stores the instance around for a few years, and then changes it, I still wa

This is not possible unless the "function" provides callbacks. Again, what is this magic function you speak of?

Link to comment
Share on other sites

1 minute ago, HashtagShell said:

I actually want my subclass to vanish as soon as the item is serialised, cloned, etc.

This contradicts what you said before. "After a few years" means even after the chunk was unloaded and loaded again. It is not possible to keep your subclass through that serialization process.

Link to comment
Share on other sites

"I am afraid not" and the rest of the comment was in response to loordgek's question, if it was an inventory that I had created.

 

This "automation function" is any function that can make changes to the ItemStack in general - usually this is a method in some TileEntity.

Picture me having a TileEntity, which a hopper is pumping into. The hopper will query for a stack in my slot, and directly make changes to it, without returning it - it expects that I passed the stack by reference. I need to complement this by reference passing with some extra functionality.

Link to comment
Share on other sites

No. If I meant after the chunk was reloaded, I would say I needed it be persistent or something like that. "A few years later" means that even if this instance (instance requires no serialisation, cloning, etc.) of the ItemStack was kept around for years, I still would want the callback. This was a very unreal and impractical example of a chunk that would be kept loaded for years.

Link to comment
Share on other sites

So, specifics:

I am making an IInventory that doesn't store its contents as a whole but shares contents with another tile in the world.

You are of course familiar with the getStackInSlot function, which (by reference) returns the ItemStack in a slot. I need to return the unity of two stacks to this function, so I create a new one with its count being sum of the counts of the two input stacks. Say, that any tile (picture hopper, etc.) can query this stack, and because it expects the by reference thing, it will directly modify it. But, because I created a new stack in the getStackInSlot function, the changes will not be automatically reflected in my inventory. Plus, I need to split the change evenly between the two original ItemStacks, which is what I hoped to do in the overridden ItemStack class.

Essentially, I am trying to have an inventory act as a unity of two, but machines expecting ItemStacks to be passed by reference are making this painful.

Link to comment
Share on other sites

No. IInventoy and ISidedInventory are old and should not be implemented. IItemHandler is the way to go. As for sided-ness: Capabilities are inherently sided, you can expose a different IItemHandler instance for every side, if you want to.

 

2 minutes ago, HashtagShell said:

Why can the IItemHandler#getStackInSlot function return null, all (at least Mojang's) code uses NonNullLists and ItemStack.EMPTY everywhere?

That's just outdated docs, the method is marked @NonNull and you must not return null from it.

Link to comment
Share on other sites

So I don't implement anything, but create IItemHandler instances for every side that I want to handle, store them in instance fields, and if <T> in getCapability is of type IItemHandler (for which I check by reference comparing the queried capability with net.minecraftforge.items.CapabilityItemHandler.ITEM_HANDLER_CAPABILITY) I return the IItemHandler instance for the appropriate side, but I need to do an unchecked cast to <T>, because the compiler doesn't know I verified <T> though the capability?

 

This capability system looks cool, also appreciate the unified energy storage capability

Link to comment
Share on other sites

2 minutes ago, HashtagShell said:

but I need to do an unchecked cast to <T>, because the compiler doesn't know I verified <T> though the capability?

There is the Capability::cast method, which does not do a runtime check unfortunately, but it removes the need for the unchecked cast in your code.

Link to comment
Share on other sites

2 minutes ago, HashtagShell said:

but I need to do an unchecked cast to <T>, because the compiler doesn't know I verified <T> though the capability?

no do it like so

@Override
    public <T> T getCapability(Capability<T> capability, EnumFacing facing) {
        if (capability == CapabilityItemHandler.ITEM_HANDLER_CAPABILITY)
            return CapabilityItemHandler.ITEM_HANDLER_CAPABILITY.cast(fuelSlot);

        return super.getCapability(capability, facing);
    }

lets post this for fun

Link to comment
Share on other sites

Hmm... that method is just doing an unchecked cast and suppressing the warning - which I can also do. A suppressed unchecked cast seems more readable to me. Besides, Forge (in the Furnace for example) just casts it directly. Not that there is a big difference, except maybe a method call overhead, which is like nonexistent these days.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.