Jump to content

Choonster

Moderators
  • Posts

    5117
  • Joined

  • Last visited

  • Days Won

    75

Posts posted by Choonster

  1. The

    Fluid

    constructor takes a

    ResourceLocation

    each for the still and flowing icons. To change the colour of the fluid, you'll need to extend

    Fluid

    and override

    Fluid#getColor

    .

     

    You'll need to register the forge fluid model for your

    BlockFluid

    . You can see an example of this here and here.

  2. 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.

  3. 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?

  4. 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.

  5. 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.

  6. 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?

  7. 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?

  8. 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.

  9. 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.

  10. 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.

  11. 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

    .

  12. 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.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.