-
Posts
5117 -
Joined
-
Last visited
-
Days Won
75
Posts posted by Choonster
-
-
-
You're calling
ItemStack#getItem
before checking if the
ItemStack
(returned from
player.getCurrentEquippedItem()
) is
null
. When it's
null
, you'll get a
NullPointerException
because you tried to call a method of a
null
value.
getHeldItem
and
getCurrentEquippedItem
do the exact same thing, you should really only use one.
Don't use
System.out.println
for output that the player is supposed to see in-game. Use
EntityPlayer#addChatComponentMessage
to send a chat message to a player (make sure you only do it on the client or server, not both). For general logging output, use
FMLLog
or a wrapper around it.
-
For the stats to be incremented, the class to ID mapping is needed. For the egg to work, the ID to class mapping is needed. For the
/summon
command's auto-complete to work (not a big priority), the string (name) to ID mapping is needed (though the IDs are never actually used).
Should I let FML create the class <-> name mappings with
EntityRegistry.addModEntity
and then manually add the three ID mappings and the egg?
-
Is the basic premise of what I'm doing (using IDs >= 256 with vanilla spawn eggs) correct? Is there a specific part of my code you think is unnecessary?
EntityRegistry.registerGlobalEntityID
will log an ERROR message when the ID isn't an unsigned byte, though it will still add the mapping and the egg with
EntityList.addMapping
. My code calls the same method.
-
This is only for a test mod which I don't plan to update to 1.8, I have a separate test mod for each version.
I ended up going with a slightly different solution, but your reference to invalid IDs pointed me in the right direction. Thanks.
The solution I ended up with was using IDs in the range [256,
Short.MAX_VALUE
] and calling
EntityList.addMapping
instead of
EntityRegistry.registerGlobalEntityID
to add the spawn egg. You can see the code here.
In the process of testing this, I realised that Biomes O' Plenty was already using IDs >= 300 for its own entities; so I found its implementation here. This is simpler than mine, but it doesn't add the class to ID mapping so kill statistics don't work.
-
Following the comments from diesieben07 in this thread, I thought I'd try and implement my own spawn egg that didn't use global IDs.
I quickly ran into an issue: the entity kill statistics rely on
EntityList.EntityEggInfo
, which is tied to the global ID list. I can create my own stats for each of my entities and increment them myself; but they won't show up in the vanilla statistics GUI (the mobs section of which also relies on global IDs).
Is there any way to have kill statistics that display in the vanilla GUI without global IDs?
-
You need to call
setHasSubtypes(true)
on your
Item
, otherwise the metadata will be ignored when the player picks it up.
-
Don't you still need a global ID if you want an egg for the entity? Recent versions of Forge for 1.8 removed this requirement, but I don't think it was backported to 1.7.10.
-
Allright after i came home i changed it so it would rotate around itself to connect with each-other. I don't know if that is the most efficient way but it certainly works. However i still don't know why that first one didn't work. You can mark this post as solved.
Your initial code didn't work because you never change the values in the
TileEntity
's
dir
array once it's detected a connecting pipe on each side at least once (so it still thinks it's connected to a neighbouring pipe when you remove the pipe next to it); and even if you did, you ignore the values in the array when rendering it.
I'm not sure why you were storing an
int
array in the first place, wouldn't a
boolean
array make more sense?
-
You need to send an IMC message to
"ThermalExpansion"
by calling
FMLInterModComms.sendMessage
before the postInit phase or
FMLInterModComms.sendRuntimeMessage
during the postInit phase. The reason you can use both methods is because TE subscribes to
IMCEvent
(fired between init and postInit) and also explicitly checks for runtime IMC messages when
FMLLoadCompleteEvent
fires (after postInit). Some mods only subscribe to
IMCEvent
, so they won't process runtime messages.
As far as I can tell there's no formal documentation of TE's expected IMC format, but you can download a recent dev version and view the
IMCHandler
class in a decompiler to see how it handles each message.
You'll need to use
ItemStack#writeToNBT
and
FluidStack#writeToNBT
to write the inputs and outputs to the NBT message you send to TE.
Edit: I forgot some words.
-
MineMaarten has tutorials on multiblock structures
and.This is a fairly advanced topic, so you'll need have a good understanding of Java and Minecraft/Forge to understand it completely.
-
Look at
RenderFallingBlock
to see how it's done for anvils, gravel and sand.
-
DamageSource
is simply the base class.
EntityDamageSource
and
EntityDamageSourceIndirect
are used for damage caused by entities and correctly override
DamageSource#getEntity
and
DamageSource#getSourceOfDamage
.
-
IBlockState
s are immutable.
IBlockState#withProperty
returns a different
IBlockState
instance with the property set to the specified value rather than modifying the existing instance.
If you want to change the state of a block in the world, you have to use
World#setBlockState
. Simply calling
IBlockState#withProperty
and not doing anything with the result does nothing.
Your code will correctly preserve any properties except the ones you change, though.
-
If it's your own
Item
class, use the
ItemStack
argument of
getMaxDamage
to determine the max damage (e.g. store the Blacksmith level in the NBT when crafted, read it back in
getMaxDamage
).
-
Are you getting any crashes or errors in the log?
Have the gem ores been instantiated and registered properly?
-
This is easier if you extend an existing recipe class like
ShapedRecipes
or
ShapelessRecipes
(or the equivalent ore recipe classes), this way you only need to override
getRemainingItems
to return the appropriate array and don't need to re-implement the
matches
method.
I have an example of this here.
-
Set the hammer's container item to itself with
Item#setContainerItem
. If you need to preserve anything like metadata or NBT, override
Item#getContainerItem(ItemStack)
to return the appropriate
ItemStack
of the hammer instead.
-
I have a working solution here.
The
BreakSpeed
handler should prevent a log from being broken by a player without the correct tool (the block will never actually start to break, like bedrock), but if that somehow fails the
BreakEvent
handler will revert the block to its original state when broken.
If you only cancel
BreakEvent
, the player will appear to be able to break the block and the block breaking particles will be spawned; but the block will revert to its original state immediately after it's broken.
I haven't tested this in every possible situation, so I can't guarantee that it will always work.
-
Block#getDrops
adds the return of
getItemDropped
(which is the
Item
form of the
Block
by default) to the drops list, so you're adding the same drop again with the NBT.
Override
getItemDropped
to return
null
and prevent the drop without the NBT from being added.
Side note: if you create a compound tag with the key
"BlockEntityTag"
in an
ItemStack
's compound tag and your
Block
has a
TileEntity
,
ItemBlock
will call
TileEntity#readFromNBT
with it after placing the
Block
.
-
The issue is that you're using the localised name instead of the unlocalised name to register
mango_leaf
and
mango_leaves
with
GameRegistry
. Since you haven't localised these names, it's using the unlocalised name with the
.name
suffix.
If all of your blocks are going to be registered using their unlocalised name, I'd recommend making a method that takes a
Block
argument and registers it using its unlocalised name so you don't need to write the same code over and over.
-
That should work for Oak, Spruce, Birch and Jungle leaves (
Blocks.leaves
); but it won't work for Acacia, Dark Oak (
Blocks.leaves2
) or any modded leaves.
You should use
Block#isLeaves
to determine if the
Block
is a leaves block.
-
It's hard to help without seeing your code. Post it on Gist with syntax highlighting or post a link to your repository (e.g. GitHub, BitBucket).
-
Are you still comparing
event.state
directly to a
Block
, or have you fixed that? If you've fixed it, post the latest
HNEvents
code on Gist with syntax highlighting (give the file the .java extension).
[1.7.10] Entity Kill Statistics Without Global IDs
in Modder Support
Posted
Okay, I thought I could use the vanilla spawn egg; but I'll implement my own egg and manually increment the stats.