target.san

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

@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.

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.

@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.

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

Hi! A question to Forge network gurus. Would it be okay to construct EntityPlayer's clone in another dimension and just leave old one marked dead? Or should the existing entity be moved? Then, if full cloning is okay, would it be okay to fire dimension change event instead of respawn one? Why am I asking? I've found that usual cross-dimensional travel procedure fails with mounts, because player entity is usually forcibly removed from World.loadedEntityList, thus effectively shifting the whole list and breaking it badly in some cases. Adding it to unloadedEntityList isn't an option because it might accidentally receive tick in first dimension when being already located in another one. Moving TPX procedure to TileEntity phase seems to produce desync glitches. So I'm searching for a full cloning like with non-player entities. Thanks!

Up. For the first and the last time.

Start at: net.minecraft.entity.Entity.travelToDimension Actual teleport for player happens at net.minecraft.server.management.ServerConfigurationManager.transferPlayerToDimension All portals in MC are implemented inside-out, i.e. not the portal block inits teleportation, but the entity itself travels to dimension. IMHO it introduces responsibility mixing, along with some other problems. Also, there's no simple func which would safely and reliably move specified entity, along with possibly present rider, to a specified 4D location. I'm fighting myself with mount+rider teleport. And I must say it's a complete hell. Sad but true.

The other potential method is to override player's collision function and replace collision bounding boxes of certain blocks. Though it might require bytecode manipulation.

2. Precise error text. If you wanna mod, you gonna learn programming. If you wanna learn programming, you gonna describe any issue in details to anyone, especially if you wanna some help. When you see a fire, and you call 911, you're asked where it happens. And the right answer is the precise address, not "Aww! It fires! Near some corner shop! Help!". Check some existing dim-gen mod, like dimension doors. You're gonna read several times more code than you write.

I'm pretty sure dude you're doing it wrong. Being serious: 1. Code chunk where it happens, preferably with enclosing class and its ancestors. 2. Precise error text. Telepaths brigade is on vacation, ya know.

<sigh> replace World world = new World(); with World world = player.worldObj; Every entity instance has a field with reference to world it belongs to. And yes, go learn some basic Java. Learn to analyze Forge sources you already have at your hand.

First. Arrrgh, my eyes. There was that pic somewhere with Mickey Mouse tearing his eyes. Please dedupe code. I'd advise some kind of enumVolume func which returns iterable over some specified volume. I did the thing for myself (though in Scala): https://github.com/target-san/Gateway/blob/master/src/targetsan/mcmods/gateway/Mod.scala (see Utils.enumVolume function). Second, you didn't show isMultiBlock. Third, you need to notify neighbor blocks when one of them is changed/destroyed. So, when any part of multiblock pieces is destroyed, you need to notify _all_ other pieces and enforce their update.

Hi! I'm worling on a tiny mod which is around more convenient (than vanilla) and less cheaty (than Mystcraft etc.) portals. As of now, I'm still having one problem - it's with riders and ridden entities. Single entities work just well. 1. When non-player entity rides a minecart, one can observe a slightly mislocated position of a rider. Like sheep would be not exactly at the center of the cart. 2. When a player rides smth like a minecart, one can experience p.1 or a warped move. Like, we're having a curved track out of portal, and a minecart with a rider moves directly to the endpoint after curve, where it should stop. The similarity with these two mini-bugs is that they disappear if player re-logs server (or, in my case, restarts a game). That's why I think I need to enforce server-to-client synchronization somehow. Like send packet to client "This entity isn't where you think it is! Relocate it unconditionally to position XYZ!" Teleporter code (Scala): https://github.com/target-san/Gateway/blob/master/src/targetsan/mcmods/gateway/Teleport.scala Thanks!

Please note that Teleporter is completely ignored if you're travelling to the End. So for completely independent algorithm you'll need to copy-paste existing one and modify it. Sad but true.

IMO the reason you're having such trouble is because you've copypasted vanilla code almost 1:1. And we must confess to ourselves that cross-dimensional teleportation code in Minecraft is pretty bad. I cannot help you identify your problems exactly though here are several advices: 1. Separate portal construction. I mean, fill all necessary data for portal and construct its exitpoint when you create one, not when you travel through it. This will allow you to pinpoint any portal construction issues. 2. I would recommend add tile entity for your portal block and store exitpoint there 3. teleportPlayerToDimension, along with your teleporter code, should only perform teleportation and nothing more. 4. As of block's breakability, I'd propose override onBlockPreDestroy and do portal death there 5. Write your code in a readable manner. Remember that MC sources are in no way a reference to some 'good' style since they're product of deobfuscation. The first step is to give sensible names to function arguments and local variables.

Thanks man Though playing with coremod and bytecode was a rather interesting experience

Sorry, but I doubt anyone would help you with such decription. Some advices: 1. Rewrite your code so it would consist of autonomous parts, easy to read and debug. Now your code is a large blob of text no one would read. 2. Debug your code and identify part you're having trouble with 3. Formulate the problem in short and concise words and post it there if you haven't already solved it

Hello! I'm having a service block which can't be crafted or retrieved by any means. And I'd like to make this block to be not visible in NEI. Unfortunatelly I found no clues how to do this in NEI API. Can anyone please point me onto some sample? Thanks. EDIT: Damn I'm stupid. codechicken.nei.api.API.hideItem when world is loaded.

I need to patch Flint'n'Steel's onItemUse bytecode - add some pre-use call which would initiate multiblock's construction. I'm making a bit better version of normal portals and would prefer to add as little newly craftable blocks/items as possible.

Okay, got it. So is there a way to have single set of names for both dev environment and game runs? At example, some back-remapper which would remap MCP names to SRG ones? So I'll reference only one name in my code.

He's using Eclipse, Things will be a bit different there.

As I said above, Eclipse project is generated from Gradle. Assume it as some generated code. Next, re-check info on Gradle's Scala plugin. You'll see that your sources should be in src/main/scala. Or override Scala source location manually. Investigate ForgeMultipart's build.gradle. Otherwise, specify exactly what you do, what you expect to happen and what went wrong.

If you wanna just have these mods run in dev environment, place them into 'mods' folder. It's usually created at the project root. Look where 'saves' subfolder is created. Basically, devel Forge repeats most part of standard profile structure. If you wanna debug and code against several mods, it gets a bit more complicated. First, you'll need mod sources, of course. Next , you'll need to add these sources, including mod's assets, to the project. For ordinary mod, that should be enough. For coremod, you'll need to place stub loader jar into mods folder. Try check JAR file of the mod you're interested, extract METADATA folder from there and then re-pack it, so the new archive would look like old one, but contain only Java metadata. This JAR is required for Forge to recognize coremod and load it properly.

Check LivingSpawnEvent class. You'll need to work with Forge event bus to handle this event. Look for Forge event tutorials. One googled: http://minecraftforgetutorials.weebly.com/event-introduction.html