GotoLink

I don't get why you don't extend EntityEnderman.

OP specifically said he didn't want someone to suggest reflection.

//get some random coordinates int x = chunkX*16+random.nextInt(16); int y = 50+random.nextInt(50);//between 50 and 99 included, change according to the actual terrain and height desired int z = chunkZ*16+random.nextInt(16); //check for 5 air blocks in vertical pattern around y (3 below, 2 above) for(int h=y-3;h<y+3;h++){ if(!world.isAirBlock(x,h,z)){ return; } } //build the vertical pattern, break if something happened for(int h=y-2;h<y+3;h++){ if(!world.setBlock(x,h,z,100,0,2)){//change block id and metadata as wished return; } } //decorate some, break if something happened if(!world.setBlock(x-1,y,z,100,0,2)||!world.setBlock(x+1,y,z,100,0,2)){ return; }

Update your videocard drivers, check your windows event log for any hard disk fatal error, disable firewall and/or antivirus software...

Using an access transformer. The *_at.cfg file will be detected by ForgeGradle on setup, and the changes will be applied to the source.

The definition of a "floating object" is that it has air blocks under it, right ? Try to check for air blocks, then set your blocks above them.

Probably the "power" value is always 0. All the power variables things shouldn't be in a block class.

You don't need metadata if you have a TileEntity. Store the subtypes into the TileEntity. If you don't want the TileEntity, you'll have to switch to a different block id, as metadata is limited to 16 values.

It was renamed getIcon. No, it isn't going to loop, unless you call your own block getIcon method. Block.blocksList[id].getIcon(side, meta);//don't use this.blockId, or infinite loop it is

If you have an item to place your block, it should extend ItemBlock and its class should be registered with your block. GameRegistry.registerBlock(Block, Class<?extends ItemBlock>, String); You also don't need to initialize and register this item yourself.

With IVillageCreationHandler, you can add new structures to villages. There is only one MapGenBase for villages. Either you accept vanilla, or you replace with your own.

IVillageCreationHandler ? Though if you want to replace completely, InitMapGenEvent with Village EventType. Just do event.newGen = yourCustomMapGen. That works like any event. Except, it is a terrain event, with its own event bus to register to. (MinecraftForge.TERRAIN_GEN_BUS)

It is pretty much done completely in the TileEntitySkullRenderer, for example. AbstractClientPlayer.getLocationSkull(String) bindTexture(ResourceLocation) Then ModelSkeletonHead#render(...)

You mean something like this ? AbstractBehavior behavior; public void tick(){ if(behavior instanceof DefaultBehavior){ behavior = new RandomBehavior(this); }else{ behavior = new DefaultBehavior(this); } behavior.behave(); } Take my example, i don't get how your method would help you or anyone else to "communicate" with it.

Then why are you using Forge ? Obviously, if you mod is made to be alone, you can go crazy and change everything. By the way, the changes you made can be done without any base edits thanks to Forge. Use Events.

Your idea is not better than object instanceof clazz //or clazz.isAssignableFrom(cls) And you can already change "Modular tile entities" behavior at runtime.

Vanilla Enchantment page doesn't allow this. You should replace the page by your own GUI with the GuiOpenEvent.

Did you run the "idea" task with gradle ?

The same as Forge, in the build.gradle "dependencies" body. You'll need a public remote repository, or a local one, with the jar in.

There are packet tutorials on the wiki. Tring to guess what data you need to send...maybe Packet103SetSlot ?

The great changes in 1.7 are the network, the sounds, and the Block/Item ids. I'd say you are fine working with 1.6, as long as you don't rely too deeply on those aspects. You can even start with ForgeGradle in 1.6.4, so you won't have to learn it afterwards. The porting difficulty really depends on experience, and you already have more than enough.

Submit those to the MCP bot on irc, that would help a lot more people.

I'd recommend you to learn how to code. Learning "how to mod" is not enough. MCP is deobfuscated-decompiled Minecraft. Meaning it is different than the original source. I'd personally hope that Mojang javadoc is much more complete. Only Mojang has access to Minecraft code, per Mojang terms of use. If Searge were to publish Minecraft official code through MCP, he would be fired, and could be sued.

There is a custom model loader in Forge (AdvancedModelLoader), but it certainly doesn't work with files from spoutcraft.

So your setup should be like: Forge \EclipseTest ->build.gradle ->settings.gradle \someproject ->build.gradle (optional) Make sure the 'allprojects" body is between the "buildscript" and the "processResources" bodies. Try to gradlew clean cleanEclipse cleanIdea once before next attemp. Old build attempts could screw things. You can have a try with the "Independent" setup. I'd recommend using Eclipse with Gradle plugin to import as a Gradle Project. Then run gradlew clean setupDecompWorkspace eclipse It is less clumsy that IntelliJ, IMHO. @larsgerrits Running the Forge gradlew things is only needed once, to cache the libraries. The "eclipse" task is not needed here, AFAIK, because you are not using the Forge folder to import into Eclipse. The "independent" setup only needs a valid build.gradle file inside your project (not forge, the mod one). Then, either import your project (not forge, the mod one) with the Gradle plugin, or, run gradlew clean setupDecompWorkspace eclipse at your project, then import it.