yooksi
-
Posts
112 -
Joined
-
Last visited
Posts posted by yooksi
-
-
Hi
Do you mean transparent as in "it has holes I can see through" - like glass pane, or as in "I can see other things through my textures" - like ice?
In general the answer is 'no' except in some special cases.
You could consider using a dynamic item model to assemble your item from pieces, depending on what type of item it is.
This tutorial project has some examples of that, which you could adapt with a bit of effort.
https://github.com/TheGreyGhost/MinecraftByExample
see MBE15 - you could modify the quads on one of the layers to have a different texture depending on which item is being rendered.
see also MBE05 for a similar approach combining models together.
-TGG
Thanks for the reply, I will take a look at your example in a moment. I have a feeling though that you're talking about blocks, while I am thinking about items. I know that blocks can have translucent textures, but can items have them too?
-
I did not set the max item damage to 0 and I also do not change the metadata at any point in my code, the only difference between these seven item blocks is the type value stored in the NBT tab of the itemstack.
The easiest solution would be to stop using NBT to store metadata, and use the local metadata value in Item for that, like it was meant to be used.
-
Is there a way to render a texture layer transparent, even though the texture itself is not transparent? This would really help me in reducing the amount of model files that share almost exactly the same properties. Every time I create a new item variation that has an extra layer, I have to create a new model file for it, and since it's a bow, this means it has to come with three more pulling models as well.
-
I did really forget that, but it unfortunately doesn't fix my problem.
Did you set item max damage to 0, and are you changing item damage at any point in your code?
-
OK... you override getSubItems, but did you set hasSubtypes to true?
From what he has shown us I would say no.
@XFactHD In order to get your subtypes to work and call
getSubItems
you have to call
setHasSubtypes(true)
from inside your
ItemBlockRFCapacitor
ItemBlock class constructor.
-
You'll probably want to create a class that extends an existing implementation of
IRecipe
like
ShapedOreRecipe
and then override
IRecipe#getCraftingResult
to call the super method, add the NBT and return the
ItemStack
.
Use
GameRegistry#addRecipe(IRecipe)
to add an instance of this recipe class.
After taking a look at
ShapedOreRecipe
and
RecipeFirework
, I realized that setting up this class manually is going to be a pain in the ass, and for some reason I don't feel comfortable extending
ShapedOreRecipe
out of pure convenience in the moment. If it gets changed and becomes incompatible with my recipes, I will have to rewrite them. Makes more sense to set it up manually, right?
EDIT: I figured out that
ShapedOreRecipe
is actually a Forge implemented class, and in order to have a custom recipe class I need to register it and all that. Think I will stick with the native Forge class for now.
-
Set the NBT from
IRecipe#getCraftingResult
instead of
ItemCraftedEvent
.
Events should generally only be used when dealing with things from vanilla or other mods, overriding the appropriate method should be preferred.
I am guessing that I have to declare my recipe as an IRecipe and then make it override
IRecipe#getCraftingResult
, correct? If so, I don't know how to do this, any examples?
-
I suspect the problem is that the color is coming from NBT and he's using the onCrafted to apply the NBT, rather than in the recipe output declaration.
Or something similar.
Spot on, that's exactly what I am doing.
When should create a new NBTTagCompound for the item to make this work?
-
The colour returned by
IItemColor
is always used to render the item's model, regardless of where it is. You can see this by crafting a leather helmet with dye, the output item will be rendered with the appropriate colour.
Post your
Item
and
IItemColor
.
Ah, you are right. Now that I checked it again
getColorFromItemstack
does get properly called even when the item is in the crafting output grid. I must have been setting my debug breakpoints in wrong places, because I could have sworn it was never called.
However, my next problem is that because I store the colour values (or to be more precise dyeColor metadata values) in item NBT, I am unable to retrieve them when crafting because the item did not have a chance to initialize it's NBTTagCompound. I do the initialization when the ItemCraftedEvent is fired. I would like to do the initialization in getSubItems but unfortunately that is not called until after the item has been crafted (pulled out of the crafting output slot). Any idea on how I should handle this?
-
Can you please explain further? What do you expect to get as a crafting result? And show relevant code, we need it to help.
I want the ItemStack that is the result of the crafting (displayed in the crafting output slot) to be coloured, much the same way as it would be after it leaves the crafting output slot - via the use of
IItemColor#getColorFromItemstack
. The mentioned method works for all cases except when the item is residing in the crafting output slot, then a default texture is used (from metadata).
So let's say I've got a test item that has a model file and a custom texture all set up. I register a ColorHandler for it, and return
Color.RED
from
getColorFromItemstack
. The item is properly colored red in my inventory and in the creative tabs. Everything works fine until I decide to craft that item, in which case the item is displayed un-colored (using the default texture, without custom color applied to it) in the crafting output slot. When removed, the item is rendered normally again.
In order to fix this I would need to abandon the subtype system of handling this item and split it up into separate items (one for each color), each with it's own model and texture file. My question is, is there a way of forcing the item in the crafting output slot to be rendered with a color applied to it (just like we do with
getColorFromItemstack
) WITHOUT resorting to dedicating separate item classes, model and texture files? Hope I made more sense this time =)
-
After a lot of experimenting I've learned the basics of setting up item subtypes and making them display in different colours via ColorHandlers. This however does not work for items that are displayed in the crafting output field when crafting (they are displayed with their default non-coloured textures). The only way I know how to fix this is to make an item model and texture file for every colour I want (not to mention registering separate classes). This will bring a lot of redundant files, is there a way around this?
-
I found out that deprecated does not mean do not use. Deprecated rather means more like "i'd rather you not use it but if you have to go then go ahead."
In my code I have a block which has multi textures and FACING so orientation matters. One of the functions there getStateFromMeta(int meta) is marked as deprecated.
@Deprecated
public IBlockState getStateFromMeta(int meta)
{
return this.getDefaultState();
}
Now if you don't use this function the block resets position every time you reload the game so in this case is deprecated but YOU HAVE TO USE IT. So what do I do? I use it. There's no other way
Point is if it says deprecated is because original MC team are trying to move away from this function so expect it to go away in the future but doesn't mean you can't use it now.
Makes sense, but if it's going to go away in the future, isn't it better to avoid using it before your code gets so dependent on it that it requires a complete rewrite to make it compliant to the new changes?
-
As long as you register the event handler before the event is fired, it doesn't really matter when you do it.
You can annotate a class containing static
@SubscribeEvent
methods with
@Mod.EventBusSubscriber
to have it automatically subscribed to the Forge event bus at mod construction time (i.e. before preInit and before the registry events are fired). On the rare occasion that you need non-static event handler methods or a different event bus, you can still manually register your event handler.
Thank you, I definitely didn't know that we can register our event handler classes with a simple annotation. Basically I should use
@Mod.EventBusSubscriber
for all my event handlers, as they all contain only static methods and fields.
-
I've seen people register them in all three initialization phases, but which way is the correct one? I myself register it in the pos-Init phase and I've never had a problem with it. That raises the second question: is it really important when we do it?
-
Vanilla never calls
Item#onUpdate
with a negative slot number. Is the method being called from another mod?
It's called by other methods beside
Item#onUpdate
. I still believe we should have a method that edits the item of an ItemStack, all this effort seems like hacking to me. We also have to allocate new objects all the time when all we want to do is replace the Item and leave other ItemStack properties the same.
-
You don't need to know whether the stacks are equal to each other (i.e. same
Item
, metadata, NBT and capabilities), you need to know whether they're the same object (i.e. use
==
).
You're right, that's a better idea, I was overthinking it.
You already know which slot the item is in, so you shouldn't need to scan every inventory slot; just check that slot of each section.
I don't know this in every situation, the itemSlot method argument will sometimes be passed as -1.
-
Bumpy ol' bump!
Can anyone help me with this issue?
Can we see the updated whole class?
Let me know if you need me to provide more information.
-
It allows you to simulate inventory changes and treat it the same as any other inventory, e.g. use it in a wrapper like
CombinedInvWrapper
or
RangedWrapper
.
I don't know what
CombinedInvWrapper
and
RangedWrapper
are, can you give me a simpler explanation? I am not a really experienced modder.
CombinedInvWrapper
combines multiple
IItemHandler
inventories into one.
RangedWrapper
exposes a range of slots from an
IItemHandler
inventory.
Aha, so for example, it merges all player inventories into one?
-
This is how my method code looks after I've tried to work around ItemStack#setItem: NewItemTorch.java.
Notice that I am forced to call ItemStack#areItemStacksEqual quite often, and from what I've seen in the code belonging to the methods called, this might get really expensive after continued use. Especially since I have to scan the whole player inventory, and if the player is carrying a lot of items... you see my point.
I am very sensitive about code optimization and even though I try not to fall into the pit of premature optimization, I'm still often worried about my code performance. Do you think I am overreacting in this case?
-
It allows you to simulate inventory changes and treat it the same as any other inventory, e.g. use it in a wrapper like
CombinedInvWrapper
or
RangedWrapper
.
I don't know what
CombinedInvWrapper
and
RangedWrapper
are, can you give me a simpler explanation? I am not a really experienced modder.
-
The
onUpdate
method has a parameter for the slot in the player's inventory. No need to search anything.
The difficulty is that
Item#onUpdate
will be called for items in any of the player's three inventory sections (main, armour and off hand), so you need to check which section it's in before trying to interact with that section.
You can do this by checking if the
ItemStack
in the provided slot of the inventory section is the same as the provided
ItemStack
.
I do this here. This doesn't handle the item being in the player's off hand.
I see you use IItemHandler to interact with player inventory. What are the advantages of manipulating the inventory that way over using PlayerInventory?
-
Well the old method has one major problem. If you had model variants you would have to explicitly register them with ModelBakery. The new method automatically registers all moddles with the ModelBakery which is fine. The old method also had issues if you called it in pre initialization method which either didn't load the models or other strange issues like the client blowing up on me one or twice because I didn't put them in the Initialization phase. Thats pretty much sums up the differences between the old way and the new way.
All really good reasons to start using the new method.
-
lol, oh yes there will be problems if you call the old way in pre initialization for example the client exploding or models not loading correctly. That pretty all the issues I ran into while using the old method of loading them models. The method is just the opposite. Its needs to be handled in pre initialization with the added benefit of adding information the the ModelBakery too. So you don't have to worry about variants it is already handled for you for the most part lol.
Are there any advantages of using the old method over the new one?
-
Bumpy ol' bump!
Can anyone help me with this issue?
[SOLVED] Render texture layer transparent
in Modder Support
Posted
I was manage to accomplish what I wanted with a custom item model class, thanks to your example on GitHub. Marking this thread solved.