Minecraftforge: TileEntity still should support canUpdate

[Speiger]

ITickable is a good feature but the problem is that it forces the Coder to add TileEntities to both sides.
The question is is there still a canUpdate function? or something close that you can make it based on a side?
If not that would be my suggetion.
Add something that allow sided injection of TileEntity Ticks.

[diesieben07]

Nothing is stopping you to return a different TileEntity class on client & server.

[Speiger]

@diesieben07 how does that work between sync? when world loads?

[diesieben07]

Server loads the TileEntity from NBT, so the server-side class would have to be the one that's registered to the GameRegistry. By default TEs do not sync, if you make it so they sync you have to ensure the client class can read the server's format.

[Speiger]

@diesieben07 i can make simply FakeTileEntities and register these. That is way easier then doing normal TileEntity ticks... But the problem is: That makes mods incompatible. Also same your solution make stuff incompatible... So please stop suggesting these bad things... It make me think not good about you...

[williewillus]

why would it?
And I don't see why you cannot implement your own "canUpdate" check

[diesieben07]

This makes _nothing_ incompatible. If you think it does, please provide actual info on what you mean. What the hell are "FakeTileEntities"?

[Speiger]

@diesieben07 never used that. XD the research it. You had this briliant idea of 2 TileEntities.
@williewillus think of that: Someone searches on the Server for the TileEntity class and finds it. Then he will not find it on the client. That brins us back to the old server client split in 1.2.5 mc.. or earlier...
So this is a stupid idea...

[williewillus]

that's not how it works. No one should be "searching" for anything.
Yes, stupid indeed. Can we close/lock until it's made clear exactly what's being asked? Preferably with CODE examples??

Terms like "FakeTileEntities" and "sided injection" are being thrown around without any regard for what they really mean

[Speiger]

@williewillus if you did not see it i request a canUpdateFunction for TileEntities so that you can better terms of additions to the world...
Because the current one is not good... Its horrible how mc handles it...
forge did it once so why not again...

[sham1]

As others here have said, there is nothing stopping you from returning a different TE in the client and the server (for instance, a ITickable TE on the server but not the client). So that raises a question, why would a method you @Speiger describe here? What would it add?

And most importantly, would adding it be worth the effort, and why?

[Speiger]

@sham1 because the can update function does not allow only side special addition it allows overrides it allows even more special conditions like validation then tick and all that stuff..
All this modularity is gone. And this stupid idea of 2 tileEntity classes stop suggesting a stupid idea like that... If i do that then i would rather hack the WorldClass or push fake TileEntities in

[sham1]

And why cannot you use those special conditions in your update-method, kind of like this:

@Override
public void update() {
  if (/* Your special conditions here */) {
    /* The code you want to execute here */
  }
}

[diesieben07]

You cannot do any fancy logic with canUpdate either. It is checked _once_ when the TileEntity spawns, otherwise it would be useless.

_Edit:_ So please, provide an actual use case (code!) that cannot be done with the current system and is not "it's different than before, I do not like it". Otherwise, go away :smile:

[Speiger]

@sham1 iterating through 1 tileEntity is faster then 1000 tileEntities (even through none logic)
Coding basics... SImply
So yeah... About spelling. Deal with it. I have a problem in that and can not fix it... Accept it or not i do not care...

@diesieben07 dissagree. Why should that be? I mean chests do not require ticks, Basic Chests do not require Ticks and also what about tileEntities require no ticks but extends a class to copy something easier that has that interface?

[diesieben07]

Yes, chests and "basic chests" (what are those?) do not require ticks. So they do not implement ITickable.
If a sub-class needs ticks and the parent class doesn't, then the subclass can just extend the parent class _and_ implement ITickable. It will then receive ticks.

I really do not see your problem.

[LexManos]

@Speiger Stop being a dick.
Explain what you want better everyone has stated what you can do to achieve what they THINK you're trying to say because you're horrible at explaining what you want.
If you're subclassing something that has ITickable then you're opting in to receive ticks. That's simply how it works. As stated this decision on if it ticks or not is done once, on world add. That's it. Anything dynamic would be more costly then just leaving it in the list.

[Speiger]

@LexManos well if you can not see the problem then i think forge is in hell trouble... oh well...
I mean modularity is important... Even in tick requirements... That is broken now.... So i have to make a hacking system that hacks mc... Thanks

[LexManos]

"I can't explain myself but YOU ARE WRONG! I'll make my own with blackjack and hookers!"
Yes yes.. a classic result when legitimately inquiring for more details. Awesome... @Speiger you've done this quite a few times. I'm getting tired of seeing my issue track spammed with stupid inarticulate issues from someone who doesn't seem to grasp how programming works.

I'm gunna leave this unlocked, to give you the opportunity to redeem yourself. If I have to lock this due to you still being a argumentative/inarticulate twat then it's going to be accompanied with a ban.

[Speiger]

can update is required to allow modular adding of the TileEntity to the World. Beause there are TileEntities that load only on client or only on the server... But the new system does not allow that. And their suggestion are bad... and since @Optional does not allow custom cases where you could remove that interface.... Which means you have to hack into minecraft or do fake TileEntities into the TickList to make that happen. But that is also a stupid idea because that messes both with the stable versions of asking for classes.... Same as the 2 Differend classes between server and client. Tell me a modular way of adding a TileEntity to the world based around a couple senarios without hacking into MC? canUpdate was perfect for that... I know you did not add updateEntity but you did add canUpdate why did it get removed? Answer me that.

[LexManos]

canUpdate was a hack that was designed to do exactly what ITickable is doing.
Explain better what you want. Stop using "I'll hack YO SHIT" as a threat it makes you sound like a moron.

What EXACTLY are you trying to accomplish, and why?
It seems you suck at articulating what you want to say in English, try code. Code usually speaks better in these occasion.

[diesieben07]

Here you go:

class BaseTe extends TileEntity { ... }

class TickingTe extends BaseTe implements ITickable { ... }

Then in your Block:

TileEntity createTileEntity(World world, IBlockState state) {
    return world.isRemote ? new BaseTe() : new TickingTe();
}

The logic in createTileEntity is just an example, it can be anything you want.

[Speiger]

@LexManos if you do not understand the difference then write a mod that uses a modular baseclass thing... Then we talk again...
@diesieben07 and what if someone ask for the TickingTe? then they will not find it... Which means they can not access stuff....

[gigaherz]

why would someone "ask" for the TickingTe? anyone who's using this "API" should be aware that the BaseTe is the right one, and that trying to compare against TickingTe is wrong.

(and by ask, I am assuming you mean "if (te instanceof TickingTe)", since it doesn't make sense any other way)

[diesieben07]

What do you mean by "ask for"? This ticking behavior should be an extension to the existing TileEntity class you have that is non-ticking. The ticking stuff should be an internal detail, not exposed to other mods. If those other mods use that internal class (it could even be package-private) it is their problem, not yours.

[Speiger]

Well since the Ticking TileEntity has the ticking logic in it which means that the access would be on that... Even on sync the base tile still there is always a possible case where they can access it. I would prefere the FakeTileEntity solution more... Then i can have the Same TileEntity on client and Server and make the ticks from the Fake Tile into the basetile that requires ticks only on the 1 side. Difference is: I Controll where and when the TileEntity requres ticks and not a system that has just a interface for ticking.... And since it is just in the TickingList then it will receive only Ticks... And not get injected into the chunk....

[williewillus]

Please just give us a code example of what you want

[LexManos]

@LexManos if you do not understand the difference then write a mod that uses a modular baseclass thing... Then we talk again...

Strike 2, I asked you to articulate yourself, I _THINK_ I know what you want but you're failing to communicate properly.
I've given you advise to move to code instead of English because you're German and it may be difficult for you. However you keep going back to the "Screw you" approach. Hence Strike 2.

And just so you know, I HAVE written and worked with systems that use modular tile entities and dynamic tickable components. It's almost like i've been doing this job for 4 years and have a lot of experience in how Minecraft, modders, and the engine works....

[cpw]

@Speiger What is a "modular baseclass thing". Please link to an example.

[Speiger]

@cpw i can not do that. IC2 Sourcecode... Closed source... you can access it yourself.
Path is: ic2.core.block.tileEntity:
TileEntityBlock,
TileEntityElecMachine,
TileEntityAdjustableTransformer...
The transfomer did extend a short time TileEntityElecMachine... I did change it because it did not needed a Inventory but the Ajustable transfomer did override the function from TileEntityElecMachine which would be a useless tickcall...
But all these machines do tick only on the Client side. And to do a 2 sided system would be bad...
What i could do is make a sided proxy but wait that does not work either... sry

[williewillus]

no, as in make a small code example, not post your actual code
As in, open pastebin or sublime or gist or notepad, make a tiny example of what you want to see in Forge, and link it
You've been asked to do that multiple times now

[Speiger]

@williewillus let me example this:
Why should a TileEntity tick a useless call when it is not needed and take speed away?
It does not effect normal clients when it is 1 TileEntity. not if they are 10, not if they are 100, not if they are 1000. But do you all think of weak computer that has to do its work...
Also client sided worlds have to do then the work twice... A useless call + a usefull call... So explain me how that is good?

[Speiger]

Its as good as letting a player calling the same Event 3 times a row... per tick.

[williewillus]

again, use code not text

[diesieben07]

If it's not needed, don't implement ITickable then.

[Speiger]

@diesieben07 learn reading... @williewillus you saw that code already you released a modversion of that... So how did you solve it? (IC2 Classic)

[diesieben07]

I know how to read. If your code does not support that, your code is bad and needs to be refactored. It's not forge's job to provide workarounds for your broken code.

[Speiger]

@diesieben07 i the code is able to work around that but i try banner here a problem which could cause huge lag on stuff and also sync problem between tileentities.... But as i understand you do not see a problem..

[diesieben07]

Yes, because you do not provide us with _code_ that shows the problem, but instead throw buzzwords around like a maniac without actually saying anything _factual_ or _helpful_.

[Speiger]

@diesieben07 i can not open my mind and drag my head code out like a computer... sorry thats out of my range...

[diesieben07]

So you don't actually know what you want except some vague idea in your head? I'm sorry, but that's not how feature requests work.

[Speiger]

Not a vague idea... its from actuall mc code which you have accessable... just look at it or are you that lazy?

[shadowfacts]

If the code you're referring to is the IC2 code, that's not we've asked for. We are asking for a small isolated example that shows a case where this is the only viable option, not a giant mod that we'd need to decipher.

[LexManos]

And I'm back, still refusing to provide code to explain what you want.
I'm gunna call that strike 3 you were asked nicely.

As for the 'issue' at hand. IF I understand you correctly you are trying to figure out how to disable ticking of tile entities on the client, but not on the server.
This can be done as @diesieben07 described with multiple Tile Entities. One for the client and one for the the server.
As the client doesn't do any saving or loading it doesn't care what your TE is so having them different between server and client IS NOT an issue.

The crux of this is, if you extend a object you get EVERYTHING. Including all interfaces it extends and mechanics it relies on. Stripping our your super's ticking because you don't feel like doing it could be extremely harmful. Depending on how it's done.

You've been given multiple solutions to the issue you have raised. I have no plans on re-introducing the canUpdate method because all use cases have been covered by the mechanics we have in place.

So we're gunna close this, and sorry as this is strike 3 from this thread with multiple warnings.
If anyone else has an issue that they can not do in the system related to ticking TEs that is able to articulate what they want better instead of arguing. Feel free to open another Issue. As it sits. Goodbye @Speiger

On top of that, you're working with decompiled code that isn't yours, Did you get permissions for that? But meh anyways that's a different subject.