V0idWa1k3r

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.

Migrate the awake field to your entity class from your model then. Most likely your model is a singleton(and it should be) so a change to this field will change the model of all your entities. EDIT: haven't noticed all other classes you've posted with those changes. Could you please post your entity class?

Model part(legs/arms/ect) rotation is usually handled in the model class, to be precise it is usually handled in it's setRotationAngles method. Basically the idea is to set the rotate angle of your desired part to some value you calculate. See how vanilla does it in various classes, ModelChicken for example has this: this.rightLeg.rotateAngleX = MathHelper.cos(limbSwing * 0.6662F) * 1.4F * limbSwingAmount; this.leftLeg.rotateAngleX = MathHelper.cos(limbSwing * 0.6662F + 3.1415927F) * 1.4F * limbSwingAmount; Which sets the rotation of the legs based on the 'limbSwing' which is just calculated smooth entity movement delta. Something similar can be done for your legs/arms aswell. Unfortunately Blender models can't be directly used in the game as Forge does not have a native .obj support as far as I know. You can however create your own obj model loader and use it that way, it isn't very complicated. You would want to load your model(most likely into a list of vertices which you can upload to a BufferBuilder although if you are comfortable with using GL buffers it'll work too) and then render it in the render method of your model class.

Well, whatever program you are using to create models - it is not a good one and you'd be better of creating models yourself. Not only is it wasting CPU cycles with it's inneficiently generated code it is also the cause of your issue - GlStateManager.color(1.0F, 1.0F, 1.0F, 0.0F); These lines in your model code are making your entity invisible by setting it's alpha to 0. You have to manualy set the alpha to 1 in all of them.

RenderingRegistry.registerEntityRenderingHandler(EntityPhantom.class, new RenderPhantom(Minecraft.getMinecraft().getRenderManager(), new ModelPhantom(), 0 )); This is an outdated and a deprecated way to register renderers for your entities. Use the overload that takes IRenderFactory as it's second argument. This also must be done in pre-init. You can't have client-only code in a common class like this. Use proxies. You are not registering your mob on a server due to the fact that you are only calling register from your client proxy. Entity registration is common. Almost. Proxies are not for registering. Just register the entity in pre-init and a renderer for it in your client proxy's pre init handling. When you are using EntityRegisty::registerModEntity the IDs will never conflict with IDs from other mods/vanilla. As a matter of fact you should start with an ID of 0 and go up from there. I am not sure if 700 will even work as it is not a byte... I'll look into it. EDIT: It's fine, forge uses integers to sync entity ids. You do not need to use a separate method to register a spawn egg, EntityRegisty::registerModEntity has an overload that does this for you. This is just an advice, using the separate method is fine. The model code is ridiculously inefficient with GL state changes. Why is it enabling blend before rendering every part and then disables it just to enable it again a line later? You can enable all your GL flags at the beginning, render everything and disable them after that. Why are your model fields are named as if they were deobfuscated? This is your model, you can name them however you want. GlStateManager.scale(1.0F, 1.0F, 1.0F); Scaling anything by 1/1/1 is pointless. It's as pointless as it gets as it does literally nothing. I am not sure what is going on with the renderer itself. It might be a GL issue, might be a texture issue. Try fixing everything else that I've pointed out and see if that also solves it. If it doesn't post the updated code and your mob texture and I'll try debugging it to see what is the cause of the issue.

There is a RenderBlockOverlayEvent that allows you to handle the overlay and I remember there was a PR to address the "in-liquid fog" color too. Particles... Yeah, what Draco said. Hardcoded in the Entity::doWaterSplashEffect

Your RayTraceUtils::isHeadshot method is broken. If the entity passed is null it throws a NullPointerException that gets logged but due to the way the game processes the left click action it doesn't crash the game. And it is null because AxisAlignedBB::calculateIntercept has zero clues about any entities and thus is unable to pass one into the RayTraceResult's entityHit field value. You can safely pass the current entity being iterated into the method instead. As a side note: ItemMagazine::getSubItems is broken. As soon as you open the "search items" creative tab the game crashes because subItems contains all the items in the current tab, and for the search items tab it contains, well, all items added to tabs in the game. For some of them ItemStack::getMetadata will return a value greater than the size of your EnumMagazine enum.

Well, I'm not really sure why is it not working for you. I can suggest removing the adition of the [0, 1, 0] vector here as it only offsets the actual calculations Could you please setup a github repository of your mod so I can debug it with a bit more than just this portion of the code you are giving? Because it works for me, that must mean that there is an issue somewhere else.

That is strange. I used your code, corrected the following and it worked for the most part. Something must be wrong with something else then. Could you please show the Utils::getPlayerPosition method? Make sure that you are adding the result of Entity::getEyeHeight to the Y coordinate

Entity::getCollisionBoundingBox appears to return null in most cases, so this check will always fail. Use Entity::getEntityBoundingBox instead.

So a copy of Vec3d class? startVec.add(dirVecNormal.scale(length)).normalize(); World::rayTraceBlocks takes a start vector and an end vector, not a start vector and a ray. By normalizing this vector you are essentially raycasting from startVec to around 0,0,0 I assume this is a static predicate somewhere in this class? It would be nice to see this aswell. Again - normalizing a vector turns it into a [-1 - 1] vector. AxisAlignedBB's calculateIntercept method will pretty much always return null as long as the BB is not at 0,0,0(and it isn't as long as the entity itself is not at 0,0,0) because it compares the coordinates of the vector with it's coordinates. You can see how vanilla raytraces entities at EntityRenderer::getMouseOver or for a cleaner code example at EntityArrow::findEntityOnPath

You can't send a packet to the player as that player is being constructed(this is the stage the capabilities are attached at) as at that stage the player's connection field is null and that is used by fml to send the packet. And even if it wouldn't the player's uuid is not properly set from their GameProfile at that stage either. You need to send the packet later.

Oh, sorry, I haven't notice that I am quoting a quote in your message, derp.

This will surely crash you with an ArrayIndexOutOfBounds as i equals to the size of the array. Honestly I would say to drop this while loop completely here and instead either use streams return this.cards.stream().filter(e -> !e.isEmpty()).count(); Or a foreach loop int i; for (Card c : this.cards) { if (!c.isEmpty()) { ++i; } } return i;

Hm, how do I explain this properly... So, currently your code structure looks like this: Config | worldGen [oreAether] | worldGen2 [oreAether2] And this is exactly what you see in game. So basically for each object that holds at least one non-primitive non-serializable object forge creates a, let's call it a subcategory. Everything in that object that can't directly be serialized to a property will also be assigned a "sub-category" and so on and so forth. Let's say I have a Config class. In that config class I have the following structure Config | client [rendering[primitives], sounds[primitives], options[primitives]] That structure will lead to a GUI with a client button. Pressing it will reveal 3 buttons: rendering, sounds and options and pressing each one will lead to the corresponding settings. Let's take a more direct world-gen example, with some code. Let's assume that the Generation class stays unchanged and I create a WorldGen class that simply contains a bunch of different Generation objects. Let's say that my structure is the following: Config | worldGen[bauxite, copper, tin, silver, nickel, ruby, sapphire, tungsten, pitchblende, beryl] In game I then would see a worldgen button. Pressing it would reveal all those other buttons and pressing each one would lead me to a specific ore setting. I hope that this is at least semi-understandable

b -> ma -> mi -> t -> v. Looks like standard alphabetical sorting to me.

No, those fields are not static and they can't be assigned to a property as there is no object that hosts them. When I did this: public final GenSettings oreAether = new GenSettings(1, 80, 128, 4,-1, 1); It created a oreaether entry in the config file, and inside that entry it created multiple other entries with their values set according to the arguments i've passed. And this entry was created under a worldgen entry as this specified it: public static final Generation worldGen = new Generation(); So in the end for that code the config file looks like this:

Yes it did. I have no idea why it isn't working for Jay and I know that forge indeed automatically creates both the gui and the file for annotation based configs without you explicitly telling it to do so from multiple tests. It takes the values from the fields at the moment of file creation.

As far as I am aware, no. Forge just auto-detects classes annotated with Config. I had the annotation based config in 1.11.2 with the gui created for me just fine.