TileEntity revamp

[target.san]

Hello Forge team,

 

I have some thoughts on revamping tile entity model.

I'm offering to write a prototype.

And I'd like to hear if you're Ok with at least checking those changes or not.

My short list of ideas:

1. Make TileEntity class final and clean its interface a bit. You read it right. Close inheritance completely. The reason is, prohibiting inheritance from TileEntity, and most notably instanceof checks. I'll describe replacement and reasons below.

2. Create either interface or abstract class TileLogic, I haven't strictly decided yet. This thing will be the then returned by createTileEntity, instead of TileEntity instance.

3. TileEntity becomes container for TE's coordinates and some other basic things. Everything beyond this is delegated to TileLogic contained internally.

4. TileLogic will contain basic implementation of getBehavior method, as seen below:

public <T> T getBehavior(Class<T> clazz, ForgeDirection side) {
if (clazz.isInstance(this))
	return clazz.cast(this);
return null;
}

And this getBehavior will be used to cast TileLogic to IInventory, ISWidedInventory etc.

5. TileLogic reference will become a privete member of TileEntity, so no one can access it directly. Except reflection of course. TileEntity receives getBehavior delegation.

public <T> T getBehavior(Class<T> clazz, ForgeDirection side) {
return tileLogic.getBehavior(clazz, side);
}
public <T> T getBehavior(Class<T> clazz) {
return getBehavior(clazz, ForgeDirection.UNKNOWN);
}

6. With some possible trickery TE NBT storage might be made backwards-compatible, at least I don't see much problems.

 

Some reasoning on why I want to do this.

 

Zeroth, I clearly understand that this change is a deep intrusion into existing architecture. Though I think it's kinda right time to do such change, until Forge 1.8 is out to public.

 

First, I'm raising again this topic: http://www.minecraftforge.net/forum/index.php/topic,15339.0.html. So you can check previous iteration of discussion there.

 

Second. The current TileEntity design is rigid and inflexible with regards to current realities of modding. I see TEs with tons of methods, implementing tons of interfaces. Which are almost independent from one another. Second, I see many of those interfaces operating on TE sides. Some of them doing this in a strange manner. Let's just review IInventory and ISidedInventory. With sides operation moved into behavior logic, we're able to leave IInventory only and clean it, then just expose it on the sides we want.

 

Third. Aggregation vs inheritance. Yup, I'm raising this abstract criteria. Because I ate enough stuff in my programmer's career where inheritance created huuuge problems with extending systems. Though let's get to some more practical things. With TE behaviors implementation not restricted to inheritance, we can just create some container templates to serve us well. We create standard FluidHandler implementation, and a person can easily use it, without the need to inherit from it, just by adding member to his TileLogic. Ok, let's assume we need a tile which is both sided inventory and a tank. Today we need to implement all three interfaces, in one TE, by hand. Possibly with some help by inheriting from standard FluidHandler impl. With behaviors, we can aggregate standard FluidHandler, then aggregate standard InventoryHandler, then maybe create standard TankSlice/InventorySlice for one or both of them. Where those slice classes will present access to subset of inventory slots/fluid tanks, and then exposed to sides we need. Not writing and duping code, but composing already written pieces.

 

Fourth. Perfect forwarding. The case I'm doing now - a two-way spatial connector, which behaves like it's another entity adjacent to the opposite side of partner connector. I need to write tons of code. I need to reimplement every interface. I need to take into account internal logic. I need to do smart aggregation for IInventory. I think that other modders who implement any kind of indirect connection for other mods would agree. AE2's P2Ps as an example.

 

Fifth. No more @InterfaceList+@Interface+@Method annotations. Wanna make some behavior optional? Just return NULL when you don't want to return it. And of course aggregate, instead of inheriting it.

 

To sum up.

 

All this stuff might look too abstract. And the change to TileEntity looks really scary. As a downside, many vanilla interfaces will change. I hope they'll change for better. I'm not asking you guys to do this. I'm asking if you'll at least review this if I write the actual code, and move vanilla MC to this model. Because I'm not very eager to hear 'Nah, we won't be even reviewing that crap, not interested' in the end.

 

Again. I'm not asking for 100% approval. I'm asking if you're interested.

 

Thanks

 

[luacs1998]

Forge likes to keep patches small.

 

Just my personal opinion, but I think you'll just be thrown out the front door. Lex has stated repeatedly he does not like to screw around with vanilla stuff unless absolutely necessary.

 

Is there a good reason for why you want these to be done?

[GotoLink]

As a downside, many vanilla interfaces will change.

You actually mean all of them ? All the blocks and all the inventories related to them. Probably also mob AI, redstone logic, world saves...

And who is going to maintain all those changes between Minecraft updates ?

 

You'd also break all mods related to TileEntity.

 

Aggregating is not a bad design idea. I apply it from time to time.

Just don't make it into the TileEntity. Make a ForgeTileEntity. Then you could probably suggest it.

[target.san]

@luacs1998

 

I clearly understand this. Though IMO we're already at the point where we're stuck with Minecraft's architecture not suitable for modding. I just see how we're simply fighting with it. And we might change this. Or at least try this. Anyway it's better than to do nothing.

 

@GotoLink

 

I don't think that world saves would change. Or anything beyond TEs' structure.

Next, about what should change with such approach. All 'tile instanceof X' should be replaced with getBehavior. It would drop some interfaces like ISidedInventory, making them simply obsolete. Existing tile entities will be modified to accomodate.

 

ForgeTileEntity. We would need to enforce other modders to use it, instead of TileEntity. Enforce them to use method invocation instead of typechecks and casts. I guess you remember what happened with attempts to introduce dynamic block IDs not from core, but from side. Until Mojang moved to dynamic IDs in 1.6.

 

Frankly speaking, I don't expect that my changes will be accepted instantly. But this can be a good starting point to communicate with Mojang guys so they make these changes on their side. Not some 'idea', but an almost-ready prototype. We have Searge and Dinnerbone there AFAIK. We can try to speak with them. I remember that 1.6 update when we finally got block names instead of IDs. And I suspect this was not without LexManos or someone else.

[target.san]

I have a purely personal opinion that the Forge team could've already rewritten MC into a real eyecandy, if they had full ownership over sources. 'Cause modders community produces 1-2 orders of magnitude more content than Mojang guys. Unfortunately, not in this world, unless MS really closes all doors and Forge would just have no options than going rogue. Then it would just have no boundaries for evolving.

[target.san]

@diesieben07

 

I clearly understand the problem with rogue patches to code achieved via deobfuscation. And as I said, it's a 'would be' scenario. Unless Forge team decides to make their own fork, he-he.

 

Scala or Kotlin won't give you dynamic behavior change. And won't give you entity-wide siding support. And no proper composition. So ugly interfaces with 'side' parameter in each method will remain. As for Minecraft being as it is, IMO there's possibility to influence MC core team. Though you have more info I think.

[target.san]

@diesieben07

 

Anyway. Is there a reason to do prototyping? Are you interested?

[target.san]

A sample for TE which changes its set of behaviors is any multipart. Any multipart-enabled pipe or power conduit. See my prev. topic on this issue.

Basically, it's anything complex enough to be composed of several parts and thus having several behaviors which might appear and vanish.

 

As for neccessity. Sure, we can live without it... but it's a painful life. And the solution I propose won't only allow to do some new stuff, but also simplify existing stuff significantly.

[LexManos]

It is not Forge's job to re-write Minecraft into a Component system.

Would this be nice? Yes, if done right.

Would it ever happen in Forge? No.

[target.san]

Ok, thanks for your answer.