[1.7.10]Unknown TileEntity Knowledge?

[BuddingDev]

Problems Arise when i am trying to do this:

 

Block Class:

http://pastebin.com/h53PLwTU

 

TileEntityClass:

http://pastebin.com/UjbkFE1w

 

Detection Logic:

http://pastebin.com/177kbh8K

 

Anyone know what i have done wrong? No message came up when the TileEntity "update".

[TheGreyGhost]

Hi

 

You forgot implements ITileEntityProvider on your block.

 

@Override will can save you endless pain from these errors...

http://stackoverflow.com/questions/94361/when-do-you-use-javas-override-annotation-and-why

 

-TGG

 

[BuddingDev]

Oh so i missed out an addon to the block class

Anyway, thanks!

[BuddingDev]

What does it mean by

class stuff is missing a mapping!

[TheGreyGhost]

It means you haven't registered your TileEntity properly.

 

Which tutorial are you following?

 

-TGG

[BuddingDev]

Oh...

Which registry this time?

[TheGreyGhost]

 

For example:

In your preInit event (FMLPreInitializationEvent )

    GameRegistry.registerBlock(blockTileEntityData, "mbe20_tileentity_data_block");
    GameRegistry.registerTileEntity(TileEntityData.class, "mbe20_tileentity_data_te");

 

-TGG

[BuddingDev]

I still dont know if I am able to make a truly working TE.

When it ticks, it crashes.

Something bad must lie within the AABB checking.

(Refer to the source pasted above, will you?)

[BuddingDev]

(I actually stumbled upon the idea to mimic the vanilla spawner code and came up with this.)

 

The stacktrace:

"Something must be wrong with the AABB algorithm in the TE / Detection class."

[BuddingDev]

If you really want that stacktrace...

(The "problem" was resolved (EDIT: thanks diesieben for the help!!!), but there is another one.)

There is another problem:

I intended to use some DIY funcs to print info for either debug or implementation.

But it seems the Detection / TE cant print them properly.

I mean, everytime it would just be like Radar at 0 0 0 detects 0 (this is OK) nearby.

I am not testing this at the origin point.

 

Detection:

http://pastebin.com/aysAtXB1

 

TE:

http://pastebin.com/RsJU4NBv

 

BTW, why there was 503 error just now?

[BuddingDev]

int RadarRange; Range of radar (in blocks)

RadarRangeHoriz and RadarRangeHorizontal is same (did not clean up)

the same applies to RadarRangeVerti

 

public void updateRadar(int range) {...}

called every tick from mother TE class.

is it possible tha there is problem in line 39-41?

 

Line 50: DEBUG use only

 

public boolean getDanger() {...} and public int getEntityCount() {...}

called when nessesary from mother TE class to collect info

 

EDIT: The code may be messy, but I am trying to list out everything I was doing before simplifying the code into smaller functions. (and also try to construct a usable class.)

[TheGreyGhost]

• Don't implement

  ITileEntityProvider

  . Override

  hasTileEntity(int meta)

  .

Any particular reason why not?  They look equivalent to me in this case?

 

The javadoc from hasTileEntity() looks like it was written many versions ago and is no longer true.

    * Called throughout the code as a replacement for block instanceof BlockContainer

    * Moving this to the Block base class allows for mods that wish to extend vanilla

    * blocks, and also want to have a tile entity on that block, may.

 

The only reason now is to allow you to have TileEntity or not depending on the block metadata (block state)?

 

-TGG

[coolAlias]

What about ITileEntityProvider#createNewTileEntity(World world, int metadata), though?

 

I see Forge has added Block#createTileEntity(World, int), but if your Block doesn't implement ITileEntityProvider and return a valid TileEntity, wouldn't you always just end up with null?

[coolAlias]

The root for "does this block+meta have a TE" is forge's hasTileEntity(World, int). If you implement ITileEntityProvider (or extend BlockContainer, comes down to the same thing) the default implementation for hasTileEntity checks that.

I understand that; my question was regarding your statement "Don't implement ITileEntityProvider" - if you don't, then your Block will not have a TileEntity regardless of what you return for hasTileEntity, so you are still stuck with either implementing ITileEntityProvider or overriding Forge's Block#createTileEntity method to return a valid TE, are you not?

 

Is there a reason, then, NOT to implement ITileEntityProvider?

[BuddingDev]

So:

This newb requests a summarised answer.

This newb wants a block that only checks if there are nearby entities.

If there is some, this newb wants the block to print its location and the count of entities.

This newb wants just that.

[coolAlias]

You already have the logic part of it handled in your radar class, it looks like, though you shouldn't use Minecraft.getMinecraft().thePlayer - that's CLIENT side only player and will crash your game when run on a server.

 

So how is your block supposed to work? What I mean is, if I place one of these blocks, the way you have it now it will be alerting EVERY player in the game when entities get close to that block. Shouldn't it only alert me or some other player who activates the block at least?

 

What I would suggest is overriding onBlockPlacedBy in your Block class and storing the player who placed the block in your tile entity class, then you have a server side instance (which you can also send chat messages to, btw) and your block will only notify that one player. If you want, you could make it store a list of players and activating the block (right click) would add or remove you (the player) from the list.

 

Anyway, if you registered your TileEntity / Block classes and your Block overrides both hasTileEntity and createTileEntity (both Forge methods), then you should be golden.

[BuddingDev]

Well, I am planning it to activate when a player right click on it.

So everyone coming by can have a look at its status.