Getting Started with Entity.java Files (1.15)

Started by Dingbat1991 on

Topic category: Advanced modding

Last seen on 04:43, 12. May 2021
Joined Jul 2020
Points:

User statistics:

  • Modifications:
  • Forum topics:
  • Wiki pages:
  • MCreator plugins:
  • Comments:
Getting Started with Entity.java Files (1.15)
Wed, 07/29/2020 - 03:52 (edited)

Hello,

I'm working off Blockbench and MCreator. I created a cicada in Blockbench, rigs and textures included and give it basic functionality in MCreator.

I was looking to provide a little more depth to the entity, so after looking at the .java file, I'm not quite sure where to start. I was hoping there were some excellent references available you can recommend that I can get started reviewing? Particularly spawning in a type of biome on top of trees, ai behaviors, reduce the size of entity, etc.

Edited by Dingbat1991 on Wed, 07/29/2020 - 03:52
Last seen on 00:30, 24. Aug 2023
Joined May 2014
Points:

User statistics:

  • Modifications:
  • Forum topics:
  • Wiki pages:
  • MCreator plugins:
  • Comments:
You could probably find some…
Wed, 07/29/2020 - 05:15

You could probably find some pretty good tutorials just by searching "How to make an entity in (insert MC version here)".

The unfortunate thing about MCreator, though, is that its versatile approach to file structure actually makes it very difficult to add functionality that's not already defined, such as the custom spawning.

As for resizing the entity, it is better practice to not scale the model after the fact when rendering the entity and just make the model as you want it from the get-go. Going in and editing the rendering parameters gets messy pretty quickly from my experience.

Finally, for AI, it's honestly probably the most complex thing you could ever try to do via custom code. It requires a pretty extensive knowledge of the thousands of vanilla and forge methods that make entities tick. I've had an OK time learning them as I go, but I also went into custom coding with a basic knowledge of java and Minecraft's source code.

If you must custom code, then you should absolutely use the vanilla source code that MCreator so graciously provides to better understand Minecraft's complex and often unintuitive mechanics.

Last seen on 04:43, 12. May 2021
Joined Jul 2020
Points:

User statistics:

  • Modifications:
  • Forum topics:
  • Wiki pages:
  • MCreator plugins:
  • Comments:
As for resizing the entity,…
Sun, 08/02/2020 - 05:28

As for resizing the entity, it is better practice to not scale the model after the fact when rendering the entity and just make the model as you want it from the get-go. Going in and editing the rendering parameters gets messy pretty quickly from my experience.

I feel like that this is a very simple process that only affects one or two parameters. Also considering that there are mods that randomly size vanilla mobs, and take for example Wizard's mod, which was also used with MCreator, had insects and butterflies which were clearly scaled down to an appropriate size.

Last seen on 00:30, 24. Aug 2023
Joined May 2014
Points:

User statistics:

  • Modifications:
  • Forum topics:
  • Wiki pages:
  • MCreator plugins:
  • Comments:
Trust me when I say this: I…
Sun, 08/02/2020 - 06:49

Trust me when I say this: I've done it before, and it was so painful. When you scale a model, its rotation points, location, etc. remain unchanged. so it will quickly turn into a mess of cubes if the model doesn't have proper child/parent cubes.

The example you give with the Wizards mod can can be easily replicated by scaling the model in your model editor before you export it (I don't know if it's in Blockbench or whatever it is that you use, as I use Tabula, which is fairly unpopular nowadays). All of the scaling and positional legwork is handled for you this way.

Often times, doing something the simple way turns out to actually be the best way. I don't know exactly what you're trying to achieve so I can't give you a very exact answer, but avoiding the use of custom code with MCreator where possible is usually best.