-
-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Entity docs #171
base: main
Are you sure you want to change the base?
Entity docs #171
Conversation
Co-authored-by: Dennis C <[email protected]>
Co-authored-by: Dennis C <[email protected]>
Co-authored-by: ChampionAsh5357 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General comments without looking at the sections that still need to be written. Make sure the information is relevant to 1.21.3. Otherwise, nice job.
Natural spawning is performed every tick for entities where `MobCategory#isFriendly()` is true, and every 400 ticks (\= 20 seconds) for entities where `MobCategory#isFriendly()` is false. If `MobCategory#isPersistent()` returns true, this process additionally also happens on chunk generation. | ||
|
||
For each chunk and mob category, it is checked whether there are less than `MobCategory#getMaxInstancesPerChunk() * loadedChunks / 289` in the world. Additionally, for each chunk, it is required that there are less than `MobCategory#getMaxInstancesPerChunk()` entities of that `MobCategory` near at least one player (near means that the distance between mob and player \<\= 128) for spawning of that `MobCategory` to occur. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the detail is good, but it is also very confusing to read and understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't disagree, I just felt it was important to mention it here regardless, and I'm unsure how to improve this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First pass over the changes, still have to do the 4 largest files.
EntityRenderer-->ArrowRenderer; | ||
EntityRenderer-->LivingEntityRenderer; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EntityRenderer-->ArrowRenderer; | |
EntityRenderer-->LivingEntityRenderer; | |
EntityRenderer-->LivingEntityRenderer; | |
EntityRenderer-->ArrowRenderer; |
These should be switched around to avoid the arrow from LivingEntityRenderer
to ArmorStandRenderer
going through the ArrowRenderer
node
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing this makes the arrow go through the AbstractMinecartRenderer
instead. I'm afraid there is no easy way of solving this.
} | ||
``` | ||
|
||
That's literally it. Extend the class, add your field, and off you go. The only thing left to do now is to update that `stackInHand` field in `EntityRenderer#extractRenderState`, as explained above. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section should include an overview over the render state modification system introduced in neoforged/NeoForge#1650.
if (renderer != null) { | ||
// Add the layer to the renderer. Reuses the ModelLayerLocation from above. | ||
renderer.addLayer(MY_LAYER); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is wrong in two ways:
- This event has nothing to do with
LayerDefinition
s, it's related toRenderLayer
s. ARenderLayer
however can indeed render anEntityModel
created from aLayerDefinition
after the latter is baked - Only renderers which implement
RenderLayerParent
can haveRenderLayer
s added to them. In vanilla this only applies toLivingEntityRenderer
and its subclasses
RenderLayer
s should be dealt with in a separate section. This section should instead explain how to go from a LayerDefinition
to the custom EntityModel
in the renderer's constructor.
// Get the associated PlayerRenderer. | ||
if (event.getSkin(skin) instanceof PlayerRenderer playerRenderer) { | ||
// Add the layer to the renderer. | ||
playerRenderer.addLayer(MY_LAYER); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same issue as above
// Build the entity type. The parameter is a string used for datafixing; mods generally | ||
// do not utilize this and can safely pass null here instead. | ||
.build(null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this accurate? I copied around this code and it complains about
java.lang.NullPointerException: Cannot invoke "String.indexOf(int)" because "location" is null
Going through neo discord, Commoble says that this string cannot be null. https://discord.com/channels/313125603924639766/983834532904042537/1109539085560856656
``` | ||
|
||
:::danger | ||
While the compiler will allow you to use a class other than the owning class as the first parameter in `SynchedEntityData#defineId()`, this can and will lead to hard-to-debug issues and as such should be avoided. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally prefer the wording used in the old entity networking page. This is not a case of "avoid if possible", it's a case of "seriously, don't do it, it WILL break".
I would also add a note that this includes adding data accessors via mixin to the technically correct class.
Adds some long-needed entity documentation. Supersedes #15 and #95 . Closes #90 . This PR:
Preview URL: https://pr-171.neoforged-docs-previews.pages.dev