target.san

Hello everyone. As I understand, the common way to add some custom logic to TileEntity and expose it as API is to add static interface. It's a common way to add behavior at compile-time. The problem is, there's no common way to add such behavior in runtime. If some mod gives such opportunity, it adds its own interface with method like getEUSink or like. What I propose is to add such method to TileEntity at the Forge level. So we'll have something like: object getBehavior(Class clazz) Which will return required projection or adaptor for tile entity, if it exists. If TileEntity implements required "clazz" directly, then this is returned. Pros: 1. Unified way for tile entities to communicate 2. Modular tile entities can change their behavior in runtime easily Cons: 1. Theoretical performance degradation due to more type casts

Hi! It's obvious that Forge is versioned as A.B.C-X.Y.Z.BBBB, where A.B.C is Minecraft version, X.Y.Z is forge version. And BBBB is a build number that increases monotonically and doesn't repeat throughout versions. So my question is, can I somehow infer full Forge version knowing only its build number? Case is for simplifying build scripts, nothing more. Thanks.

Not all of them actually. That's the source of my initial confusion. I've been imagining how pretty this API could be revamped and mapped onto component-based model. Like add Collidable component to block to make it collidable. Ah, dreams, dreams It would require to write Minecraft almost from zero though

Okay, from your responses I understood that there's no such thing. I thought that 'public layer' is a rather stable term. My bad then. Anyway, my initial question arose from multiple methods in Block class that are declared as public and used only internally.

@GotoLink Thanks for pointing typo. Of course, override. Fixed OP. Although, the question persists. Is there any list of methods that are part of true public layer, excluding ones that are public and used only by Block/Item classes themselves?

Hi! As you might know, almost all methods in Block/Item classes are public. Although, many of them in reality provide only shortcut overloads, like "idDropped", which is called only by other Block's method that returns actual list of ItemStacks to drop. So my question is, is there some list of methods that are part of true public layer, i.e. they're called by Minecraft engine? This would make life much easier, so you don't need to override tons of aux methods that won't be called anyway. Thanks. EDIT: fixed terms; not overload, override of course

Look for Immibis' Microblocks mod - it's the simplest coremod sample I've seen so far. People usually recomment ChickenBones' core, though it has much wider functionality and thus harder to fully understand.

Hi! I'm reinventing the wheel writing directed lamps mod - light panels that spawn several light-emitting phantom blocks. So I'm curious, would it be more proper to perform block spawn immediatelly in event handlers --or-- postpone this kind of update 1-2 ticks? Actually, I played test version of my mod on my world and once encountered strange glitch. I was placing panels on ceiling, to light down, and it appeared like I've become block-like obstacle to them. This could be my glitch, and could be not mine. Development world showed no such behavior. Thanks

Thanks for info, though I'm aware of this. I was looking for some more details, on where's this code resides.

Hi everyone! Could please someone point me on these topics: 1. Where's vanilla inventory background is drawn 2. Where's vanilla GUI handling/crafting logic is located 3. Is it actually legit to take vanilla inv. background and modify it The reason for all this - I want to make armor upgrade (or like), which, when worn, converts standard 2x2 crafting grid to 3x3 one. Thanks, Target-san

How to write coremod with access transformers: http://www.minecraftforge.net/wiki/Using_Access_Transformers Immibis microblocks (his mod packages also contain sources; see mods.immibis.microblocks.coremod package there, start from MicroblocksCoreMod class): http://www.minecraftforum.net/topic/1001131-15-immibiss-mods-smp-tubestuff-5400-core-5402-da-5400-infinitubes-5401-liquid-xp-5401-microblocks-5408/ Also check CodeChickenCore, though it's vast and not so easy to understand.

I don't think it would be a good idea for me to use instrumentation and like, as i highly doubt that other people would be grateful for such a hack Anyway, many thanks for confirming my suspicions. [EDIT] At least, TileEntity retrieval can be hooked by wrapping getChunkBlockTileEntity via instrumentation. Still requires ASM toolset and a coremod, though can partially solve issue with posing one entity as other one.

Hi everyone! I'm constructing kinda strange entity container block, which contains one other item/block (like pipe or wire) for each of its sides. What I wanna is to make my container simulate like it's one of its contained items. Example: I'm putting glass cable into my container's west slot, then put regular glass wire adjacent to it, and when glass wire block looks up for the neighbour wire blocks, my container pretends to be glass wire and the two happily connect. Per my investigation on MC code, there's always World.getBlockTileEntity that returns exact raw entity for the provided coordinate, without any notion of requester's identity. So my crazy idea seems to be impossible to implement. But I'm pretty new to Minecraft modding and might be mistaken. Thanks