Jump to content

Recommended Posts

Posted (edited)

Alright, so I decided to dable in custom mobs for 1.11.2 and I also know there apparently has been a number of changes just from 1.10 to 1.11.2 according to a thread I stumbled across here, so it was even more of a challenge when using a 1.9 tutorials which was outdated but I managed to make it work. So I made my enttiy class, made my ModelClass, and my RenderClass and they all work with no errors. Hurray.

However two issues. My Mob does not show up when you spawn it. It is invisible, and it shows itself after you have smacked it and then "disappears" again. It's still there becasue if you somehow managed to get your curser over it WAILA shows it and you can still strike and damage it, but it's physical "rendered" form is not visible. Here is the screenshot:

Spoiler

GWVornw.png

 

As you can see, it appears breifly when you strike and daamge it and then it goes invisible again, and although thats cool, that is not how it is suppsoed to work. It's AI is fine, its attack is fine all that is great. My guess is I am screwing up my proxies somewhere. Becasue the second issue that shows up, is on a server the egg to spawn this entity is there but when you try to use it nothing happens. So to me that means it isn't even registering on the server which logically to me means i messed something up in the proxies. 

 

So I once again need some help. I  do appreciate it and am thankful. So here is the code: 

MobRegistry: https://pastebin.com/v4Nx8220

RenderPhantom: https://pastebin.com/5WYjBx9F

ModelPhantom: https://pastebin.com/cMQTLFyu (not sure if you need the model code)

 

In my ClientProxy that extends CommonPorxy I am calling my MobRegistry.register(); which in turn as you can see is calling my MobRegistry.registerRender(); and MobRegistry.registerSpawnable.

 

Is it perhaps something as simple as split the two functions up and call MobRegistry.registerSpawnable on the CommonProxy and MobRegistry.registerRender() on the Client? (nope that just crashes)

 

Lastly, I know this code is old and is using a depreceated fuction. So after resolving this issue perhaps a tip on the "new" way to handle the entity registry? I also don't like the fact that you have to "assign" an ID to the entity now. For me I think that it could conflict with other entity ids, right? Or is this part of the new method where these IDs are only stored to the instance of your mod?

 

Edited by HalestormXV
Posted (edited)
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.

34 minutes ago, HalestormXV said:

Is it perhaps something as simple as split the two functions up and call MobRegistry.registerSpawnable on the CommonProxy and MobRegistry.registerRender() on the Client?

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.

 

34 minutes ago, HalestormXV said:

I also don't like the fact that you have to "assign" an ID to the entity now. For me I think that it could conflict with other entity ids, right?

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.

Edited by V0idWa1k3r
  • Like 1
Posted (edited)

I fixed it all up and it works now (server and client), except the phantom still is invisible. All you see is the shadow as indicated here:

Spoiler

1MGE8OJ.png

 

They are running around, they attack, they have their drops, etc. they do all that, but they are just shadows. 

New Render Class: https://pastebin.com/9nWB3Uqv

New Model Class: https://pastebin.com/stZCcZeN

 

As for the the models i SUCK at modeling so I have a program that I use that allows me to make edits and change models and stuff, similar to techne and I guess I exported the .class file without making the changes to the names. Either way the updated model class in this post has the corrected names. How it exports is beyond my control so I don't know why it does it so inefficently but I have been using it for quite some time. And the texture size is indeed a 64 by 32 and is mapped correctly, because if you hit the entity the texture shows up.

 

This shows that the texture is correct:

4GEhQVc.png

Edited by HalestormXV
Posted

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.

  • Like 1
Posted (edited)
45 minutes ago, V0idWa1k3r said:

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.

 

 

Excellent, you are a champion. It works once I made that change. I will also likely take you up on the advice of no longer using the program. Ultimately I would like to try blender. HOWEVER, there is one more issue, or perhaps not issue but question. The entity does not move it's limbs. It just "glides" with no leg animation or swinging arms, etc. I know this is likely do to the inefficeny of the exporter now that you have pointed me to it, but might I ask where or how you would make changes so that the arms swing and the legs move? If I had to guess would it be the rotation points at the top for each of the pieces? Or maybe extend ModelBiped instead of base so it acts more like a zombie?

Edited by HalestormXV
Posted

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.

 

22 minutes ago, HalestormXV said:

Ultimately I would like to try blender.

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.

Posted

Thanks for the tip and for pointing out the rotation points. I was actually looking at the zombie class. Yeah I know Blender won't work directly. But I did some searching and found a couple of third party scripts that might be able to export/convert them to java.class files or .json files and then to java. Either way, models are not my forte and I know my weakness for sure lol. But as it stands now the original issue that this thread was for has been solved, so I can mark this as [SOLVED] once again. I greatly apprecaite the help. 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.