V0idWa1k3r

Actually it's the reverse. First create the framebuffer, bind it, setup the matrices and the viewport and render your stuff. Then use the resulting texture in your GUI. Framebuffers are opengl's way of "offscreen rendering". Instead of drawing onto the main draw buffer you would draw onto a custom framebuffer which results in a texture you can render somewhere else.

Don't change the parameters you pass to the setTextureSize method. Leave it at 64x32 but pass a higher-resolution texture.

Just make your armor texture's resolution higher. You don't need to change anything within the code. Obviously you'd need to make the resolution of the entire texture higher, not just a select part, say make it from 64x32 to a 128x64.

Well, here is the official binding: Doing this should be enough.

Why? You should update to 1.12.2 The camera is usually a collection of 2 things - the viewprojection matrix and the frustrum. The ViewProjection matrix is a combination of a View matrix and a Projection matrix (as evident by name). The view matrix governs how vertices are transformed based on the position and the rotation of your "camera", or a view entity, or whatever it is, and the projection matrix governs how vertices are transformed based on the FOV, the aspect ratio and the width and the height of a viewport. This matrix is the minimal information that defines a basic camera. You can go without a frustrum but you must have the viewprojection matrix. There are helper methods that allow you to construct both the view and the projection matrices in the lwjgl library and then you just multiply them together to get the viewprojection matrix. However I unfortunately don't know whether the matrices in lwjgl are row-major or colomn-major so I can't tell you the order in which you multiply them. The frustrum is a collection of 6 planes defined by the viewprojection matrix used to do "culling" - basically not rendering anything that the camera can't see anyway. So here is the theory. In practice minecraft still uses old opengl for it's shaders and so you have to tell opengl which matrix to use. To do so you would need to first specify the viewport(the rectangle that defines, well, the viewport, the area of the screen the rendering takes place within) using GlStateManager.viewport. Then you switch to a GL_PROJECTION matrix mode with GlStateManager.matrixMode and load your projection matrix. Then switch to the GL_MODEL_VIEW matrix mode and load your view matrix. You load the matrix using GL11.glLoadMatrix, or set the matrix to identity with GlStateManager.loadIdentity and then multiply it by respective matrix using GlStateManager.glMultMatrix. However this topic of yours will require you to use a framebuffer aswell. You can ask me more about using that but it is a pretty advanced topic, even with minecraft helpfully providing the Framebuffer class.

Forge has nothing to do with this. You just need an SMD parser in java. You may use an existing library and use forge's jar-in-jar feature to package it with your mod or you can write a parser yourself. It looks like smd is a plain text file describing a model so you should not have many issues with parsing it. Here is the format specification. However note that since minecraft has no notion of skinning or even armatures/bones you will have to build everything from the ground up. This is not really a forge issue though and you might find more help with that on gamedev forums rather than here. Nobody here is going to write code for you but you are free to ask questions if you have any troubles with the matter at hand.

None, they return the same object. You can't do this since key presses are a client-only thing. It works on the physical client but it will crash the physical server. Also you are reaching across logical sides which is never good.

https://mcforge.readthedocs.io/en/latest/networking/simpleimpl/

As a side note events are not guaranteed to run on both logical sides. If the event only fires on a logical server then world.isRemote will always return false and your code will never execute. In this case you would either need an event that does fire on the logical client or you will need to use packets.

The proxies separate physical sides, you need to separate logical sides. You need to show more of your code.

Well for starters I can tell you that this tutorial is total BS if only because it claims that it works for 1.13 right there in the title... Forge for 1.13 isn't out yet. How can the author be so sure that it will work for forge that isn't out yet is beyound me. Likely it is just there as clickbait. You should never follow a coding tutorial that uses clickbait. CommonProxy makes no sense. Proxies exist to separate sided-only code. If your code is common it goes anywhere but your proxy. IHasModel is stupid. All items need models, no exception, and nothing about model registration needs access to private/protected data. Register your models directly in the ModelRegistryEvent. ItemBase is an antipattern. There is already ItemBase, it's called Item. Don't ever use static initializers. Instantinate your stuff directly in the registry event. Do you see why this tutorial is crap? Literally everything it told you to do is wrong and now you have to redo everything. Congratulations, this tutorial just wasted a bunch of your time! As for the actual issue: Registry names must be entirely lower-case

Make sure you are on the client. Spawning particles on a server has no effect - the method is a noop for WorldServer.

You will need to detect when the entity is damaged of course, set some kind of a timer somewhere(in your capability), and while that timer is valid spawn your particles at the entity's position.

This is exactly wht I am talking about

From forge's code I can deduce that you should be able to use a propery by a key of "transform" in your variants. It's value can be 1. a string which is the pointer to a transform specified in code. The defaults are forge:default-block - the block transformation forge:default-item - the item transformation forge:default-tool - a handheld tool-like transformation I don't think you can have your own custom transforms like this though since the map is immutable. 2. a primitive that's not a string. I can't find out how it is deserialized in that case though. 3. a json object that contains keys that specify the transform type (like thirdperson for example) with the values of a TRSRTransformation. I assume those would look like your transforms that you use in json files.

Plugins can't do that since the server doesn't have any particle data whatsoever, only the client does. You are likely confused. The particle won't follow anything but it's motion. You can though continuously spawn particles at the entity's position thus making the entity a "particle emmitter".

Then I am afraid you will need a custom particle implementation. Default particles don't follow anything but their motion values. Use a for loop.

The motion is the change in position each tick. 0,0,0 means that your particle is stationary. Could you elaborate on this? What number?

It probably does but since your motion is 20, 20, 20 they instantly "teleport" 20 blocks to the right, front and up. Also, what's intID here? Is it the blockstates id or something else?

I don't know how to make this more obvious.

That API is a web API. This means that you would use it exactly in the same way you would in a standalone applet. Look at examples at their github. That said while I don't know the version of the game you are modding for it is likely 1.8.x since afaik hypixel is stuck there. Anything below 1.9 is not supported on this forum and you won't get help untill you update.

Could you please elaborate on your issue? I don't think I understand you here. Lighting code is completely unrelated to models.

Scale down your model in your model editing software. This actually looks to me like your model editing software used the wrong metrics.

 Only through World#spawnParticle. The arguments parameter is the one you need. Put the blockstate ID as that parameter.

https://mcforge.readthedocs.io/en/latest/concepts/sides/#sidedproxy public static void init() { OBJLoader.INSTANCE.addDomain(SlimeRancher.MODID); indigonium = new SlimeRancherItem("indigonium", CreativeTabs.MATERIALS); vacpack = new ItemVacpack(); } Don't instantinate your stuff in pre-init. This is much, much better than using static initializers but you still should instantinate them in the appropriate registry event. Since ObjLoader is a client-only class this code will crash the client server. You must use a proxy. public void registerRender() { ModelLoader.setCustomModelResourceLocation(this, 0, new ModelResourceLocation(this.getRegistryName(), "inventory")); } IHasModel(yes, it is one even though there is technically no interface like that) is stupid. All items need models, no exceptions and nothing about model registration requires access to private/protected data in the item. Register your models directly in the ModelRegistryEvent. As for your actual issue: From what I can tell the game is looking for the item's json file. I don't know if you can trick it into looking for the obj file directly by manipulation the ModelResourceLocation but you can still use obj models for items if you use forge's blockstates since they can be used for items too.