Hi All, just a quick one to get some opinions prior to me going off on one 

 

I am thinking of making a block that when you hit it does stuff then changes state so it cant be hit again for an hour. I have had a look at how furnaces work with regard to timing the baking process etc. and switching visual state and it basically looks like a counter that counts the ticks and when this gets to Y it triggers the functionality to reset the block to its original state.

 

Before I crack on I wanted to check with you guys (who are way more experienced than I on such matters) what the impact of this might me when it scales. If in the hour 1000 blocks are set off, would these 1000 counters cause server performance issues?

 

This may be me being overly paranoid but I'm throwing it out there just in case.

 

Thanks as always,

 

HammyD.

In 1.8 TileEntities have been nicely split into "dead" ones that don't tick, just hold data and the "ticking" ones.

 

You want to use ticking ones. (IUpdatePlayerListBox)

 

Now - if you are planning on having SIMPLE incrementation and if check in onUpdate() then, what can I say...

Having even 10000 blocks like that would be literally 10000 iterations (world.tickableTileEntities) and few light operations.

 

Performance hit? Nah. Should you do that? If you must. TE shouldn't be used for super-common blocks like e.g cobble.

 

Other suggestions:

Have look at Block.randomTick(...) used by e.g crops to grow. You might want to randomize your timer to work with "close to hour intervals".

Don't tick - use a 'long' to save the next time it will become active, and when the player tries to interact with it, check if the current world time has surpassed the stored time and you're golden.

 

Unless, of course, you need your block to reset immediately when it next becomes available (visually, for example), then you will unfortunately need to tick, but you can still use the world time implementation so you don't have to increment / decrement a counter.