target.san

Hello! I'm curious why FML's remapper translates obfuscated names to SRG names (field_NNNNN_l) and not to sensible names available in MCP/Forge during development. This leads to 2 sets of method/field names, one for development and one for packed mod. So I'd like to ask: 1. Is this some kind of Minecraft/MCP license limitation? Because having that direct remapping should be pretty straightforward. 2. If it's not a licensing limitation, then I have only two options in mind: a. There are naming clashes for SRG names in certain cases. b. There's another remapper I couldn't locate which does the trick. I suspect this question was answered somewhere before. Unfortunately, my google-fu wasn't enough to locate answer. Would be grateful for a link. Thanks

I suppose you've used proper tutorial for deploying Forge 1.7 build environment. Then you should know that Eclipse project is generated from Gradle and thus changes to it won't do any good. Next, you'd have build.gradle look this way: repositories { ... // repos config, not our case } apply plugin: 'scala' // Here our hero comes apply plugin: 'forge' ... // rest of Gradle config and then re-generate Eclipse project with gradlew eclipse Also, you need to respect default source layout for Scala or override it http://www.gradle.org/docs/current/userguide/java_plugin.html http://www.gradle.org/docs/current/userguide/scala_plugin.html Last, to see Scala cookes in Eclipse you need to use Scala perspective. Though you should know this if you intend to write in Scala. One of good examples would be ForgeMultipart: https://github.com/Chicken-Bones/ForgeMultipart It's in Scala, it's a coremod, it's for 1.7 and it's using ForgeGradle. Last advice. Store your launch config as shared and keep it versioned. ForgeGradle doesn't create proper run configurations for you. If you gonna learn Scala by writing your first mod then I wouldn't recommend doing this because Scala is rather complicated and has steep learnring curve. I'd recommend attending these Scala courses on Coursera: https://www.coursera.org/course/progfun https://www.coursera.org/course/reactive

Hello! There's JSON file http://files.minecraftforge.net/maven/net/minecraftforge/forge/json with all info about Forge builds past 953 It would be really nice to have a field with supported ForgeGradle version there - as a way to specify only Forge build number as dependency and then have all dependencies versions deduced from it. Thanks.

Hello everyone! I wanna add some special code which is executed when redstone block is ignited via flint'n'steel. So my question is, which place is more appropriate for this code - redstone block's onBlockActivated or flint'n'steel's onItemUse. The exact way of doing this via ASM is out of scope. Thanks!

Hello Forge team! There's been JSON file at http://files.minecraftforge.net/json2 with all available Forge versions, tagged by MC version, build number etc. What I've discovered is that it contains data only for versions up to 953. Is there some replacement and/or other source of such info? I'm asking this because, frankly speaking, I'm not a big fan of specifying full Forge version in my build scripts, and I wanna almost all version data be deduced from Forge build number, including required version of ForgeGradle. It should be much easier to do with Gradle now. Thanks!

Thanks! Actually I was stupid enough to not call super's read/write NBT from my overrides

Hi! I'm having following issue: 1. I'm setting a block in non-loaded dimension (Nether in my case) to the one having tile entity. The whole thing is done on server side, so it's properly loaded. 2. Added logs show that TE is set and properly stored 3. Then I go to nether... and voila! My TE is re-created, and obviously not configured as I expect it to be. I know that it's re-created because I checked both entity IDs, and they're different. 4. markTileEntityChunkModified doesn't help So can anyone please give some help on how to properly force save TE in such force-loaded chunk? Because block IDs and metas are stored just fine without additional efforts. Thanks.

Dunno if it would in your case, though the first one should be preferrable to players as it explicitly sends packet about position change to player which controls player entity. Also I've checked that my code doesn't impose any 'damage' status over player. UPD: fixed stupid bug in code, I forgot to perform standard onEntityRemove and chunk removal. Also I faced some really strange bug with total desync on another PC. This could be result of no onEntityREmove, or something else. UPD2: I must warn you from using my algorithm. In some cases it causes player's total desync, where player is left floating in void at client side. As for mount/dismount, I'm having an idea on lending the whole work to TileEntity, so it would allow both mount and rider to have one update tick in new world and then re-unite them. P.S: Heck, that player removal/addition for worlds is pretty nasty. I don't even think there are any state invariants for client-server. Couldn't those guys just add utility "teleport anything anywhere" func?

Okie, so here's where I am. I've solved almost all issues with teleport code. Except one. You guess it - teleporting a riding player through a portal. When this happens, player is left like desynced with server - no minecart, standing at destination point, and can't trigger block collision reaction - at example he can't teleport back, as teleportation is triggered by colliding a block. But if you re-login, you'll appear at the point where minecart should end, properly riding it. Code is here: https://github.com/target-san/Gateway/blob/master/src/targetsan/mcmods/gateway/Teleporter.java Any help with that last bug would be greatly appreciated.

UPD: I've figured out what was the case. It's that nasty removePlayerEntityDangerously. Guess what it does? It removes player from the list of loaded entities. So here's what happens: 1. A player riding minecart touches my portal. Teleport function runs as a result of onEntityCollidedWithBlock. Which happens - you guessed, as a part of entity update, thus inside World.updateEntities(). Also note that teleport is triggered by minecart. 2. Teleport function breaks mount-rider binding and teleports both entities. Order seems to not matter. 3. When a cart is teleported, it's just marked as dead and dropped from chunk it's registered in. 4. Then, a player is teleported. Here comes removePlayerEntityDangerously - it removes player from the list of loaded entities - effectively breaking its indexing. 5. After entity update tick, dead flag is checked for a minecart. And we're trying to remove minecart from the loaded entities list already changed by player. Then Kaboom happens. I changed the logic by using ordinary removeEntity and then adding player to unloadedEntitiesList - it should effectively drop player from world's loaded entities on next tick. The only trouble I'm having for now is the exit position flicker for minecart with player.

Fun fact: I have the same problem: my players are dismounted to(same with horses). I decided to just ignore it. Tell me if someone has an (easy) idea how to do it. The first algo from Enhanced Portals seems to remount entities properly, it just dupes player's mount. I'm working on this issue now. Seems there's some trouble with how mounts are stored in NBT - as they're part of their riders' NBTs. Also I'm experiencing random 'backflips', i.e. entity is immediately teleported back. The only idea I'm having for now is to handle per-portal entity list with timestamps, so any given entity can't come through the same portal immediately. I personally don't like idea of per-entity teleport cooldown. UPD Backflips were for players jumping into portal, and it seems I've solved them. As for cart doubling, it happens for any minecart with a riding entity. And I'm assuming this is due to how ridden entities are updated. It could've been solved by marking entity as dead. The problem is, this makes game crash when a player rides minecart. Any entities like sheep ride minecarts just fine through a portal.

Hello guys! I'm implementing another type of cross-dimension teleporter. And I'm having issues with actual teleportation. Actually, I've tried two versions of teleportation code so far, and none of them works as expected. This code: https://github.com/ShadedDimension/enhanced-portals/blob/master/src/main/java/uk/co/shadeddimensions/ep3/portal/EntityManager.java has issues with ridden minecarts - when player comes on a minecart through portal, there's another minecart appearing behind. This code: https://github.com/StevenRS11/DimDoors/blob/master/src/main/java/StevenDimDoors/mod_pocketDim/core/DDTeleporter.java results in player being dismounted at exit point. So here comes a question. Can anyone please point me out towards precise entity teleportation code, which can move entity both inside dimension and between them, handling mounts, riders and mounts properly? Only entity and its 4D destination. No biometrics, orientation change etc. Thanks.

Thanks, I've checked them. Per what I've seen there, there's nothing unusual - language adaptor for Scala actually just handles Scala's companion objects. In theory, any mod developer could circumvent this by using pure Java class for mod entry point. That's why I've asked if Forge workarounds some other Scala-specific things. There's no necessity, I'm just curious.

Could you please tell in short what hackery did you need to support besides different layout of main mod class? AFAIK two main problems with Scala when interoping with Java are raw Java types and companion objects instead of static data members.

(sigh) Ok, so you're about using Class as key in hashmap. It's a kind of service locator pattern. We have one such map per TE instance. When TE is asked to return some behavior, which is a type, it searches for such mapping in that map using class it received as a key. If it finds some type, it returns that value. If not, it falls back to superclass behavior. So yes, there mapping from type to object is unique, but it's unique per TE instance. So I see no problem at all, since TE can't have two behavior implementors for the same type. It's not an event processing, where you can have several event handlers per event type. You're going too far by talking about block geometry. My approach doesn't break TE into sides. It allows TE to behave differently on different sides. There's no break since behaviors aren't independent objects. The pattern of having different behaviors on the sides of block is pretty common in Minecraft mods. You're checking if some TE can, at example, send or receive items from a certain side, or send/receive some power. And some sides just don't provide such a function. To achieve this, mod authors usually add methods to interfaces like: public int putItem(ItemStack stack, ForgeDirection direction); Approach with sided behaviors would eliminate this need. Wanna your block work as inventory on a side? Just return inventory interface from there. Wanna check if the block is an inventory on a side? Just request behavior and check it for null.

Yes, because it's an example implementation. Derivatives might expose different behaviors on different sides if they want. There's no static modifier, so it's an instance variable. If I didn't add access modifier, it wouldn't make map static. See prev item, it references instance map. It doesn't. Because, depending on real TE type, it might return behavior which isn't TE's implemented interface or superclass. And my main point is that we'll have single way to access both inheritance-based behaviors and aggregation-based ones. Yup, you are. As another example, proposed approach would allow to implement multipart blocks with inherent support for parts with complex logic. At example, ordinary multiparts form one tile entity type. But if you need something like multipart wire, you have to make your own tile entity - because you need several behaviors exposed as interfaces, statically. With proposed approach, there would be no need for separate TE class - only some code which allows block parts to expose their behaviors on block sides. Modularity in action. BTW, this is one of many places for side argument which you thought as excessive.

So, let say we are in this case: TileEntity tileEntity = world.getTileEntity(x,y,z);//some random code to get a TileEntity instance Object obj = tileEntity.getBehavior(SomeBehavior.class, Side.WTV);//you call that method you suggested obj. //? now what ? And compare it with the current situation: TileEntity tileEntity = world.getTileEntity(x,y,z);//some random code to get a TileEntity instance if(tileEntity instanceof SomeBehavior){ ((SomeBehavior)tileEntity).doSomething(Side.WTV); } I don't see any improvement from your suggestion... I'm not good at generics. Sketch solution for TileEntity with more proper signature would look like this: public <T> T getBehavior(Class<T> clazz, ForgeDirection side) { if (clazz.isInstance(this)) return clazz.cast(this); return null; } public final <T> T getBehavior(Class<T> clazz) { return getBehavior(clazz, ForgeDirection.UNKNOWN); } Next, we're having some class with dynamic set of behaviors Map<Class, Object> behaviors = new HashMap<Class, Object>(); public <T> T getBehavior(Class<T> clazz, ForgeDirection side) { Object obj = behaviors.get(clazz); if (obj != null) return clazz.cast(obj); return super.getBehavior(clazz, side); } And that's how we can use this: ISomeBehavior b = tileEntity.getBehavior(ISomeBehavior.class); if (b != null) ... do some nifty stuff ... The main advantage is that we'll be using single approach for all cases. It won't matter whether that behavior is a superclass of TE or some internal aggregate - we'll need to call getBehavior. Next, let's remember about such a block as Transfactor Interface from Thaumic Tinkerer. With current approach, author needed to implement every possible interface by hand. With getBehavior, he can just delegate to linked entity's getBehavior - less than 10 lines of code to rule them all.

As I wrote earlier, the main benefit is the ability to modify set of behaviors TE supports in runtime. For now I'm mostly looking at LogisticsPipes as an example. There, chassis pipe should support _all_ possible interfaces beforehand. Actually, any entity which can or cannot be something depending on state would benefit from such change.

Upping this for the first and the last time. Anyone interested?

Dammit, MC crashes when I enable jvisualvm's profiler, and jvisualvm dies itself when I try to dump server thread state. @Draco18s, seems I have no other option than playing binary search. Anyway, it wold be interesting to know on how to run the whole set under Eclipse. EDIT: Seems it's some kind of really unpleasant lag spike. Disappears if Biomes'O'Plenty are removed, or if some worldgen mods are removed, so there aren't many of them.

@Draco18s First of all, I'm not so fond of doing monkey job. Second, my search shows that it's some kind of cross-mod issue, as disabling each half of mod list results in issue disappearance. @luacs1998 Thanks for advise, I'll try this.

Hello everyone Couldn't find anything useful on Gogle, so posting here I'm trying to run a set of mods locally in SSP. Unfortunatelly, internal server shuts down due to lack of resources, either right after initial world gen, or several seconds afterwards. Actually, it doesn't shut down, but rather eats 100% CPU and stops responding. Sure, it's one of mods doing that mess. The problem is, I'm having following alternatives to find out who's the one eating my jam in the kitchen. 1. Disable mods one by one, or via binary search. Not very handy, and I'm a bit lazy to play with ~30 mods. 2. Use some experimental WinDbg plugin which can attach to ava process. Looks like not so promising. 3. Run the whole stuff from source distribution. Would be my salvation, but mods don't like to run in this environment. So my question: is there some kind of recipe to run Forge 965 with a bunch of mods in debugger properly? I don't have intention to decompile one of mods, just to check who's the CPU eater. Thanks.

Okay, here are some notes on why that getBehavior would be useful. First, you won't see benefits from this on basic TE's - only on compound ones. Second, I don't think I would be able to give some short and clean code samples due to 'first'. Here's rough, stripped version of TileGenericPipe class from BuildCraft. It implements 10 interfaces. Issues I can personally see here: 1. All pipe responsibilities in one class 2. All pipes need to be potential item, liquid and power pipes. Or, this part should be split into three separate TE's. 3. All pipe behaviors are statically described in class contract, i.e. you can't add new responsibilities without modifying class. If getBehavior or something like is present, all interfaces which aren't directly related to how pipe works can be extracted to separate classes. This will: 1. Lighten up core class 2. Allow each ppe to implement only interfaces it really needs, i.e. power pipe won't need to be item and fluid pipe at the same time Moreover, let's check LogisticsPipes pipe. Let's imagine we need chassis module which provides BC power to connected blocks. With current state of things, you'll need a) Add IPowerEmitter interface to TE class b) implement it directly in TE class c) Process both cases when we have module and when not, even for pipes which aren't chassis. To sum up, + Allows to split TE implementation into several independent parts, and add such parts more easily + Allows to modify TE behaviors at runtime, depending on TE state, without need of stub imterface implementations + Allows one block to mimick another, like Transfactor Interface from Thaumic Tinkerer, but without limiting number of mimicked behaviors - Requires one more method - Might require to use class->handler map internally * Migration might be easened with following code in default implementation: if (this instanceof clazz) return this; * The idea might be extended object getBehavior(Class clazz, ForgeDirection side) This will allow to have different behaviors on sides, and side-independent ones for UNKNOWN direction

My apologies, I don't have enough time for complete answer for now. Will answer in a few days.

In your example you can't make same object become instanceof clazz on current tick, and then unbecome on next tick. Please be more specific. If you're telling about some existing implementations, then I'm not arguing that. I'm just suggesting a more centralized mechanic for this. The problem is, if mod A provides modular TE's, and mod B provides modular TE's, then these are two different kinds of modular TE's.