V0idWa1k3r

Please remove the formatting of the text in the post(when you paste the text in there is a "remove formatting" popup) or do not color it. Your post is impossible to read on the dark theme. 1. This is correct. If you really want you can register your particle with ParticleManager::registerParticle. You can add your own enum constant to EnumParticleTypes with EnumHelper but that is not necessary. 2. Your way is correct. To get an instance of a particle you either instantinate them, or get their IParticleFactory(if it is present) and invoke it's createParticle method. 3. That is the only particle registry. If a mod doesn't register their particle there - you can't. At that point the best you can do is reflection. A Particle is not a IForgeRegistryEntry - there are no registries for them. 4. Please clarify this point a bit more. A TextureMap is not your regular texture - if a sprite is not registered onto it it won't be there - TextureMap does not support dynamically adding textures to it. If you want to add your own texture to it you need to use TextureStitchEvent.Pre and TextureMap::registerSprite. The later returns you a TextureAtlasSprite object.

You can calculate your rotation angles using any other variable. For example the amount of ticks your entity has existed for.

Why are you using 1.8.9? Update, that version is nearly 3 years old. Please clarify You need to build your mod using gradle(gradlew build) to create a distributable jar file, you can't export(I assume you mean Eclipse's export feature) it. In the future please consider using online services such as gist or pastebin to host your code snippets, or at least use the Code(<>) BB tag.

Afaik forge provides no built-in .obj support(apart from block/item models) so you have to write your own obj parser and renderer. Wikipedia will help you with parsing an obj file, it's not that complex, and rendering is also pretty straight-forward, depending on how exactly you are handling the model. I also have a very inefficient yet simple example of a custom obj parser here.

EntityPlayer::isCreative EntityPlayer::isSpectator Or if you want to be more thorough: PlayerInteractionManager::getGameType

Erm... You store it in a field and get it from that field? You do know what fields are, yes?

No. registerSprite already returns you the TextureAtlasSprite object you need, there is no need to get it again.

That TextureAtlasSprite object that you recieve as a result of this method. There is no regular stitch event. TextureStitchEvent has 2 sub-events - pre(as the map is being setup) and post(after everything was loaded in).

TextureMap::registerSprite returns you a TextureAtlasSprite object. This method must be called during TextureStitchEvent.Pre

partialTicks is the amount of a single tick that had passed. Using it depends on the way your animation is done. For example if you have a wheel a rotation of which equals to the amount of ticks the GUI is open you would get it's rotation angledeg like this: ticksExisted + partialTicks. You don't need to store a previousTick in this case as previousTick always equals currentTick - 1.

TextureAtlasSprite has nothing to do with particles. It is simply a 'pointer' to a location of a specific image on a texture sheet(or if we disassemble the name - it is a sprite of a texture atlas(aka map)). Forge just allows custom loading of your sprites with those methods. By default there is only 1 texture map in the game - the blocks+items textures map. Particles have that field avaliable mostly for block/item crack/break particles, as they need to know what texture to be rendered with. This field is null for other particle types and theirt textureIndex determines their location on their texture map(default vanilla particles.png file). If you need a custom texture for your particles you can return 1 in your Particle::getFXLayer to use the blocks+items map as your texture and then call Particle::setParticleTexture with a TextureAtlasSprite object that would point to your custom texture on the blocks map. You will need to load that texture yourself using TextureStitchEvent and TextureMap::registerSprite.

As @Earthcomputer said GuiScreen::updateScreen gets called each tick so operate on your timer there. You still have to render each frame obviously.

See how BlockFurnace does this. Custom particles are a thing that is not easily done afaik. You either need to add an enum constant to the EnumParticleType using EnumHelper and register your particle factory for the particleID you specify in your enum constant or you need to build your own particle system from the ground.

Could you please elaborate on that? You can't render anything as a tick happens as rending must happen each frame due to buffers being cleared. A tick is a semi-constant 1/20th of a second. A frame is any numerical value depending on a magnitude of factors.

For one your renderer does absolutely nothing. As you are extending Render and not any of it's child classes you must manualy render the model of your choice in there. It most likely will be the ModelBrianade I see a commented out reference to. Rendering registration must be done in a client-only class like your proxy. Your current implementation will crash the server. No, your SideOnly here will not save you. It in fact will be the cause of your crash. Why is the override commented out? If your IDE/compiler throws an error you can't just comment out the Override and pretend that it never happened. This is the purpose of the override - to throw an error if the thing you are overriding can't be overriden for one reason or another. You are doing something weird with types. If your renderer renders an EntityBrianade just use the EntityBrianade as it's type, not <T extends EntityBrianade>

As this is a TESR simply translate by x,y and z given to you in the method parameters, they are your position in view-space anyway, you don't need to translate by negative position of your TE in the world. I'll test it a bit more right now and tell you if everything is indeed correct. EDIT: Okay, this took a bit longer than I expected. The problem lies in the way BlockModelRenderer applies transformations relative to the position you give to it, so you have to offset by negative position of your TE to account for that but then you can't rotate properly because the translations are messed up relative to view-space. This took a bit of time to figure. I managed to make it work via a simple "hack" of separating my translations into 2 passes: First I translate by viewspace xyz(the arguments passed) Then I rotate Then I translate again by negative position of my TE to account for BlockModelRenderer's translations. And then it works. Mostly. Here is the code I came up with: BlockPos blockpos = te.getPos(); IBlockState iblockstate = Blocks.STONE.getDefaultState(); Tessellator tessellator = Tessellator.getInstance(); BufferBuilder bufferbuilder = tessellator.getBuffer(); BlockRendererDispatcher blockrendererdispatcher = Minecraft.getMinecraft().getBlockRendererDispatcher(); GlStateManager.pushMatrix(); GlStateManager.disableLighting(); this.bindTexture(TextureMap.LOCATION_BLOCKS_TEXTURE); bufferbuilder.begin(GL11.GL_QUADS, DefaultVertexFormats.BLOCK); GlStateManager.translate(x, y, z); GlStateManager.rotate(45, 1, 0 , 0); GlStateManager.translate(-blockpos.getX(), -blockpos.getY(), -blockpos.getZ()); blockrendererdispatcher.getBlockModelRenderer().renderModel(te.getWorld(), blockrendererdispatcher.getModelForState(iblockstate), iblockstate, blockpos, bufferbuilder, false, MathHelper.getPositionRandom(te.getPos())); tessellator.draw(); GlStateManager.enableLighting(); GlStateManager.popMatrix();

Translate to your xyz first, then rotate.

You only call proxy.registerRenderers, but not proxy.preInit as @Animefan8888 said. And don't use unlocalized names for model registering, use Block::getRegistryName.

It depends on the matrix state before you are applying your rotation to it. I have an example in my mod here, where I render a collection of blocks rotated around both Y and X angles.

You need to call OBJLoader::addDomain with your modid as an argument before registering your models.

%youritemblocklocalnamehere%.setRegistryName(%yourblockfieldnamehere%.getRegistryName());

Extend on BlockRotatedPillar. That class contains everything needed for your blocks to be axis-aligned.

The substitution system will work with ObjectHolders, but won't with straight up declared fields. Think about the mess that would be created if someone creates a substitution for your block/item/registry entry but you are still using the old reference that won't even be in the registry! At best all you equality checks will fail. At worst you will have crashes all over the place. At forge's git Lex mentioned the possibility of dynamically reloading all registries, including blocks and items. Plain fields references won't work good with this idea either. Yes technically it won't matter too much. However if you are referencing another field in your constructor(like ItemSeeds for example) - yet again, practically N1. It is just the preferred way of doing it.

You need to set the registry name for the itemblock you are creating too. You are not using the new registry system correctly. You should not put anything into the fields(blocks/items) and let ObjectHolders do that for you. ModelLoader is a client-only side class and references to it should be performed at a client-only class aswell. The SideOnly annotation is not something to be trusted.

Don't create a new instance of your model in your entity class, models should be singletons. Models are also client-side only. If your model class haven't changed since you've last posted it then the problem lies in the fact that you need to handle both cases on your AwakeAnimation method - if the entity is awake, and if they are not. Currently you are changing the rotation angles on the model if the entity is awake... which changes them for all entities as models are singletons.