Tileentity suggestion

[cdkrot]

Sometimes it is required to have stable block update ticks.

  Here we can use Block.updateTick, Block.setRandomTick(true) and tickRate(world)

  But it gives unstable, random updates.

So we are using tile entities, but they was designed to store data. So we have to add mapping for it and store in saves dummy structures like {id, x, y, z} (created by Tileentity.writeToNBT method), just to recreate timer after relaunching server.

 

And i am suggesting to add an api to Block class which will be like Random Tick, but stable; with fixed intervals.

[cdkrot]

This is not possible. There is a reason why TileEntities are a special case. What you suggest is ticking every single block in the world every tick. That's not possible without completely destroying performance (if the game would even run).

No.

I am suggesting to create a same callback, but not for random, for static ticking.

This can be as follows:

Block.setNeedsTicking(enum E)

enum E can be

1. FALSE

2. RANDOM

3. STABLE

 

with using tickRate() and updateTick() as input and callback

 

Quote from: cdkrot on Today at 12:28:11 PM

 

    So we are using tile entities, but they was designed to store data.

 

No.

TileEntities are designed to add more complex behavior to blocks. That may be processing ores (Furnace), simply storing data (Redpower Microblocks) or more complex rendering (Signs).

 

Maybe.

Anyway as I said before it is impossible to create a tileentity without saving function.

And even if you want to use it just as a tick handler you need to save - load it.

So the other way(also unavailable currently without modifying game src)  can be creating "unsaveable" tileentities. Without saving function; And  recreating completely new instance

Using BlockContainer.createNewTileEntity

after relaunching server.

[cdkrot]

    Anyway as I said before it is impossible to create a tileentity without saving function.

    And even if you want to use it just as a tick handler you need to save - load it.

 

And? I don't see any problem with that. Its just a few bytes. Don't worry about it.

But, depending on your situation, you might want to use a TickHandler.

I founded that TileEntity is more useful and handy way for timering a single block;

 

You may want to look at save procedure in AnvilChunkLoader

        while (iterator.hasNext())
        {
            TileEntity tileentity = (TileEntity)iterator.next();
            nbttagcompound1 = new NBTTagCompound();
            try
            {
                tileentity.writeToNBT(nbttagcompound1);
                nbttaglist2.appendTag(nbttagcompound1);
            }
            catch (Exception e)
            {
                FMLLog.log....
            }
        }

Here in tileentity just  given a tagCompounded inconnected with main tree and referenced from The Save Method.

So you can't remove it, and it will leave an empty tagCompound if you don't write id,x,y,z here;

A solution can be creating a method such as "boolean doSave()" in TileEntity and to skip saving if returned false

After relaunching server [mod/world loader] can scan world for BlockContainers unattended with Tile Entity, and create a new empty ones for those.

* This work is performed while saving.

And? I don't see any problem with that. Its just a few bytes. Don't worry about it.

Yes of course, But why should we always save this garbage to save? It is really don't needed often.

[LexManos]

Part of the reason tile entities are saved to disk more then it allows for extra data. Is that tile entites are not created except for when a block changes.

Your way would require us to loop through all block in every check and ask if they want to create a new tile entity. This simply isn't going to happen.

But either way, the simple answer is, use tile entities is you want 'reliable ticks'

Normal blocks shouldnt care about ticks like that.

[cdkrot]

Yes of course, But why should we always save this garbage to save? It is really don't needed often.

I'd consider this overkill. It's really just one single byte (the 0 termination for the empty NBTTagCompound).

Yes. The bigger problem creates loading. If it finds an empty element it will log like this:

WARNING "Skipping TileEntity with id "