Jump to content

coolAlias

Members
  • Posts

    2805
  • Joined

  • Last visited

Posts posted by coolAlias

  1. No, the Capability is for storing which skills the player has and what skill level they are.

     

    The actual skill system can be totally separate and simply query the player's Capability when they interact with it.

     

    If your skills need to store any information on a per player basis, that should be stored in the player's Capability.

  2. public static SoundEvent SOUND_LEVELUP;
    
    // Called from main class during FMLPreInitializationEvent
    public static void registerSounds() {
    	SOUND_LEVELUP = registerSound(new ResourceLocation(ModInfo.ID, "levelup"));
    	// etc.
    }
    private static SoundEvent registerSound(ResourceLocation location) {
    	final SoundEvent sound = new SoundEvent(location).setRegistryName(location);
    	return GameRegistry.register(sound);
    }

     

    During the loading process just before the SoundSystem starts, I receive an error message like the following for every single sound listed in my sounds.json file:

    File minecraft:sounds/special/levelup.ogg does not exist, cannot add it to event dynamicswordskills:levelup

    Note how it appears to be searching for the file with the 'minecraft' domain rather than my mod id, even though it shows the correct resource location just after that.

     

    I'm using Forge 1.9.4-12.17.0.1976.

     

    What am I doing wrong?

  3. If I recall correctly, the Container should have a reference to the Inventory, which should have a reference to the TileEntity in use, which should have a reference to the BlockPos.

     

    But if that's not the case, then yes, you'd have to resort to a raytrace to fetch the current block, but that's not totally reliable in this case - what if another player or mob interposes itself between the player and the open chest while they are perusing, for example? Container will still be open, but now the MovingObjectPosition will probably contain the mob. Or a player might place blocks between them. Rare, certainly, but it may happen.

  4. java.lang.IllegalArgumentException: Attribute is already registered!
    [16:00:35] [server thread/INFO] [sTDERR]: [java.lang.Throwable:printStackTrace:-1]: 	at net.minecraft.entity.ai.attributes.AbstractAttributeMap.registerAttribute(AbstractAttributeMap.java:34)
    
    // your code:
    this.getAttributeMap().registerAttribute(SharedMonsterAttributes.ATTACK_DAMAGE).setBaseValue(0.5D);
    

    EntityMob already registers the ATTACK_DAMAGE attribute - you can set the value like you do the others, but you cannot re-register it.

  5. No worries - that's the reason they finally consolidated the event buses, it was a mess keeping track of them.

     

    @OP As we've said, you have to check if the DamageSource#getEntity is an EntityPlayer, then cast that entity to EntityPlayer so you can call I believe #addChatMessage to send them a chat - it's been a long time since I've looked at 1.6.4 and the chat methods have changed a lot since then, so you may have to look for it yourself.

  6. The first version you posted should be printing to the console each time a zombie dies. To test if your event handler is working at all, you can put a println at the very beginning of it:

    @ForgeSubscribe
    public void onEntityDeath(LivingDeathEvent event) {
      System.out.println("Entity died: " + event.entity);
    }
    

    If you're not getting any output at all, make sure you actually call that random static init1 method you posted... it'd be simpler just to register directly during one of the FML events.

     

    Edit: No, don't use FMLCommonHandler event bus - that's the wrong bus for this event. Here's a tutorial  - please read it so we don't have to repeat the same information over and over again.

  7. // during pretty much any of the mod init phases:
    MinecraftForge.EVENT_BUS.register(new YourEventClass());
    

    A quick Google search will bring up a lot of information on using Forge events that would be cumbersome to reproduce in forum posts.

  8. Implementing ITileEntityProvider instead of extending BlockContainer is the recommended method of adding a TileEntity to your block.

    No.
    ITileEntityProvider

    sucks, maybe not as much as

    BlockContainer

    , but it still sucks. Simply override

    hasTileEntity

    and

    createTileEntity

    from the

    Block

    class.

    Ah, my mistake - for some reason I thought ITileEntityProvider was responsible for those two methods. What's the point of that interface, then?

  9. Implementing ITileEntityProvider instead of extending BlockContainer is the recommended method of adding a TileEntity to your block.

     

    Having the block teleport any entity that walks on it sounds like a very griefer-friendly mechanic... click block above lava, destroy block, set teleporter block coordinates, and sit back and watch everyone and everything to fall into the lava... You may want to consider requiring players at least to activate the teleporter themselves, rather than automatically when touching it.

  10. What is the Item going to do with the Block coordinates? Is the Block going to be responsible for doing anything? The answers to those two questions will determine whether you need a TileEntity or not, at least with respect to this particular interaction.

     

    Note that Blocks by themselves are incapable of storing NBT data - additional data is typically stored in a TileEntity, though NBT data such as vanilla lockable containers are probably stored somewhere else.

  11. I'm pretty sure #onBlockClicked is only for left click and #onBlockActivated is only for right click. Easiest way to find out for sure is to put a System.out in each of those methods and test it ;)

     

    Note also that some  types of Items may not pass the click on to the block under certain circumstances.

×
×
  • Create New...

Important Information

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