• serializeInitialChunkData -> serializeClient or serializeNetwork, that seems to be Mojang's intention?
• Container.getStack should be more like transferSlot?

Currently the IInventory methods are called setInvStack etc, though I can't help but feel like I want to shorten them to simply set etc. Though things like block entities which implement the interface directly might suffer from it or it could make code more confusing if somebody is unsure about the object being an inventory. Thoughts?

• Look into MapIcon changes
• IChunkProvider/IChunkSaveHandler got a new method
• MigrationType enum got a new thing
• EntityAttribute enum got a new thing
• BlockEntityWithLootTable has new methods
• RegionFileManager has a new method too
• Blocks.blocks -> Blocks.BLOCKS

Enigma doesn't handle this.

This change is a partial follow up to #242, but is also relevant as its own proposal. This proposes the removal of the get prefix from the method in VoxelShapeUtils that returns the static constant EMPTY.

VoxelShapeUtils: getEmpty -> empty

Some of the classes are in, but I'm not sure what the DoubleLists are for. Can someone with a better working knowledge of the area chime in?

The cardinal directions (n/s/w/e) see very little (/no?) use outside F3. Code is usually being written with the axis+direction or xyz coordinates in mind, not a cardinal direction ("5 blocks west + 1 south").

The mapping between axis+sign and cardinal direction was arbitrarily chosen by Mojang and has to be looked up or memorized by the developer for every specific use with the current naming scheme.

It is also cleaner to speak of axis+dir in rotated coordinate systems. The Y axis having been rotated by 90° to point sideways sounds more reasonable than "down" now pointing to the side.

To resolve this, the fields in Facing should be renamed to XP/XN/YP/YN/ZP/ZN, where the first letter is the axis and the 2nd is the direction. Other classes may also have members still using cardinal direction names that'd need to be changed.

I'm a strong yes myself, because this fits Java conventions (and projects such as Brigadier) much better.

In my opinion, none of that stuff is really specific to gen, just as biomes are. There's no reason anything else couldn't spawn a feature, like a sapling does.

I dont know the proper name: but this should explain it:

Caused by: java.lang.IllegalAccessError: tried to access method net.minecraft.item.tool.ItemPickaxe.(Lnet/minecraft/item/Item$ToolMaterial;)V from class net.minecraft.item.Item

Must've been missed in the change

• remove Potion prefix from Effect classes, move them to effect package
• switch what is "base" name and what is "qualified" name
  Compare to similar classes for items: stateless thing is just Item, and wrapper around it is ItemStack.

Also, I personally prefer EffectDamageModifier to EffectDamage, despite it's a bit longer.

List of classes to cnange:

PotionEffect -> EffectStack
PotionEffectType -> Effect
PotionEffectTypeAbsorption -> EffectAbsorption
PotionEffectTypeDamage -> EffectDamageModifier
PotionEffectTypeHealthBoost -> EffectHealthBoost
PotionEffectTypeInstant -> EffectInstant
PotionEffectTypes -> Effects
PotionEffectUtil -> EffectUtils

The current name for what a user is currently riding in the Entity class is vehicle, I don't think this really makes much sense, I've never really heard anyone refer to things like horses or pigs as vehicles. I can make a PR for ridingEntity, mountedEntity, or something along those lines if anyone agrees.

Currently, World is meant for anything regarding single instances of the World class, which is unlikely to change. Level is being adopted as the term used for a single save - confusingly also called "World" in the game (such as "Create New World"), though sometimes "Level" in the code (like "preparing level ...").

Previously some of our classes were using "Dimension" to describe an instance of a world (usually which ID - dimensionId) or its type (Overworld / Nether / End - DimensionType), though I've done some changes to get rid of the mention of "dimension" completely.

I'm not sure this is the correct way to go about it. We should retain the name "Dimension" for something, though I'm not entirely sure what to use it for.

While MobEffect is the confirmed Mojang name, I have no idea where it came from because it's a pretty bad name. Not only mobs have status effects. Status effect is the common name used by the community, so I think it makes the most sense.

Advantages: In my personal opinion, cleaner

Disadvantages: Requires modifying access levels to get there, which is not a good thing for a mapping and adds complexity to projects willing to use pomf; ultimately not worth it IMO

The usage of impl packages is still a bit unclear to me. I would honestly prefer not to use them unless there's a good reason.

For example: net.minecraft.migration, net.minecraft.container, net.minecraft.client.audio are good like they are. There's plenty of classes in the base package and lots of implementations.

On the other hand, net.minecraft.world.chunk.generator (currently) consists of IChunkGenerator and the impl subpackage has only 5 implementations and is pointless in this case.

CoralFeature.generate not getting mapped in build.

yarn-18w48a-tiny:

CLASS btf net/minecraft/world/gen/feature/CoralFeature net/minecraft/class_2978
METHOD btf (Lbat;Lbqa;Ljava/util/Random;Let;Lbvu;)Z a method_12865 method_12865

https://github.com/FabricMC/yarn/blob/18w49a/mappings/net/minecraft/world/gen/feature/CoralFeature.mapping#L1-L4

A great deal of the sound fields have incorrect names. They have been shifted upwards by one position. I attempted to fix this issue in my PR, but tasks like these are mind numbing, and there are a lot of sounds.

• ListMultiWidget should be MultiListWidget (though now that I think about it... I don't know what is Multi about the list at all? Either way, ListMultiWidget is not right)
• SkeletonBaseEntity should be AbstractSkeletonEntity
• EntityCat should be CatEntity
• Entity datafixers...there's a few https://i.imgur.com/qsdgdZm.png

Same as we changed EntityFactory to EntityType

Currently we have oldX/oldY/oldZ and M/N/O (the latter has not been deobf'd).

I'm thinking lerpX/lerpY/lerpZ would be good names for M/N/O. They are not as heavily used as oldXYZ.

Here's what they are used for anyway:

• oldXYZ is for the previous physical position and is used in physics calculations.
• MNO is for the previous visible position and is used for linearly interpolating visible positions between ticks.

Most cases of MNO look like this:

    this.c = this.b.M + (this.b.x - this.b.M) * a1;
    this.d = this.b.N + (this.b.y - this.b.N) * a1;
    this.e = this.b.O + (this.b.z - this.b.O) * a1;

Or this:

    this.M = this.x;
    this.N = this.y;
    this.O = this.z;

EntityRendererEntity has an exception, however this is similar to the first case:

    EntityRenderer.a(a1.getBoundingBox(), a2 - a1.M, a3 - a1.N, a4 - a1.O);

Suggested rename of VoxelShapeUtils to VoxelShapes. This follows Guava's factory class design, which has long been proven to be a fluent and readable approach to object factories and utility classes - see: Strings, Objects, Lists, etc.

I think World.isRemote is awkward, It might make more sense to use the client/server binary instead of local/remote.

Pending on clearing up the enum situation first.

EntityFactory just makes little sense...a factory should build entities not be the actual type of entity. Also mojang calls it EntityType.

EntityType is ok, but I think EntityCategory is a more fitting name. This is the class that defines an entity as either MONSTER, CREATURE, AMBIENT, or WATER_CREATURE.

Some of the names of classes might be modified. Ex. TileEntity -> BlockEntity, Minecraft -> MinecraftClient. Those classes have a more accurate name but they were not renamed because in other decompiling projects people were too lazy to change those common-used names.

Currently the net/minecraft/text has all of the text model components prefixed with TextComponent, in contrast with Mojang's own naming scheme (XComponent).

Its important to note that only TextComponent directly represents actual text, the rest are just placeholders apart a model that is constructed into text client-side. IMO the Text prefix is verbose and unnecessary.

I propose that we should use Mojang's naming (where known) and the following changes:

• net/minecraft/text/ITextComponent -> net/minecraft/text/Component (this is kind of given away in some of the serialisation code).

"BiomeDesert" vs "DesertBiome", etc. Or "ComponentTranslatable" vs "TranslatableComponent".

The former has advantages when sorting names in an editor and is my personal preference; the latter is more common in Java development and is preferred by most other people.

Please discuss.

I feel this should be changed from the Mojang name, as it is misleading when taking into consideration the hit type can be a MISS. A result of a hit that is a MISS makes no sense from a logical perspective. This class would be better just representing the data it contains, rather than what it tried to achieve.

A possible name could be RaytraceContext, but I'll leave this up for proper discussion.

This one has me stumped.

none.bfb appears to be responsible for all the scrollable list containers used for GUIs. However, it does not extend Gui, nor does it extend Drawable (so calling it some form of Widget is going to confuse things).

net.minecraft.sortme.KeyBindingGui directly implements it, but the actual Gui object which uses it is net.minecraft.client.gui.menu.GuiSettingsControls.

Main thing I want to tackle right now is none.big. This is responsible for drawing the server list. It contains a list of none.bif (which is for drawing server entries added by the client), a list of none.bie (which is for drawing server entries detected by scanning the LAN), and an instance of none.bid (which is for telling you that it's scanning for LAN entries).

All of bid, bie, and bif implement none.bew.a, while none.big itself extends none.bew, which extends none.bfb.

none.bew.a is responsible for individual list items inside none.bew.

So here are my questions so far:

• What is a sensible name for none.bfb?
• What classifies something as being part of none.bew?

While it's the origin in some contexts, in others it does not make sense. For instance, it's used as a fallback when attempting to normalise a vector that is very close to zero.

On the other hand, even when it's the origin, it still makes sense to call it the zero vector.

I'm working on a PR to map Vec3d and possibly some other things but renaming ORIGIN will have a lot of side effects which I do not want happening in the PR, hence this issue.

In vanilla, the only value ever used for this field is "minecraft".

owner, in my opinion, implies that there's something backing ownership but namespace is more commonly just a key. I also feel that namespace helps improve the clarity of what an Identifier really is -- it's used in a few different contexts, some of which owner doesn't really make sense (texture registries, loot tables, player skins). In some of those contexts, owner gains a whole new meaning but namespace stays consistent with the underlying behavior of Identifier.

In AIGoalArrowAttack there is an exception that reveals some of the potential names for the real names of the class, Which brings the question,

Where possible, should we be attempting to use the real names that Mojang use? Avoiding their use? Or coming up with the best names that we can given the evidence?

e.g.

        if (!(aIDistantAttacker1 instanceof EntityLiving)) {
            throw new IllegalArgumentException("ArrowAttackGoal requires Mob implements RangedAttackMob");
        }

Implies that the class should really be called ArrowAttackGoal, IDistantAttacker called Mob, and EntityLiving called RangedAttackMob ?

This seems confusing though, as I would have expected that the instanceof check is backwards considering the current naming.

In many places, IBlockStates are used in places where Block would have been in the past. I almost want to call parameters of that type block since it makes more sense to me. What do you think?

Additionally, this opens up the question of whether IBlockState should simply be renamed to IBlock, and Block to BlockType, or something? Though maybe that's a bit too early - should wait for what Mojang is going to do to Blocks, at the very least..?

Advantages:

• Mojang uses it.
• It rolls off the keyboard better.

Disadvantages:

• A bit confusing?

With the addition of the tag system in 1.13, an ambiguity has arisen between object tags and nbt tags. This ticket proposes a change for nbt classes to better respect their data type. Another proposed change in lieu of this migration is to switch to prefix-style naming, as it is more fluent and readable in this case.

• Tag -> Nbt
• AbstractListTag -> AbstractNbtList
  • LongArrayTag -> NbtLongArray
  • ByteArrayTag -> NbtByteArray
  • IntArrayTag -> NbtIntArray
  • ListTag -> NbtList
• AbstractNumberTag -> NbtAbstractNumber
  • ShortTag -> NbtShort
  • DoubleTag -> NbtDouble
  • FloatTag -> NbtFloat
  • ByteTag -> NbtByte
  • IntTag -> NbtInt
  • LongTag -> NbtLong
• CompoundTag -> NbtCompound
• StringTag -> NbtString
• EndTag -> NbtEnd

Furthermore, I propose the following changes as a way of simplifying the current naming pattern.

• NbtAbstractNumber -> NbtNumber
• NbtAbstractList -> NbtList/NbtCollection
• NbtList -> NbtArrayList

The number type has no reason to expose its abstraction modifier, much like Number in Java. NbtAbstractList is also used for collections that can represent themselves as serialized primitive arrays, so although this type extends from Java's AbstractList, it seems rather misleading to express it as one. NbtCollection would be the most appropriate name for this type imo. Following this proposal, NbtList can be expressed more explicitly as the internal list type it defers to, ArrayList.

Why? Mojang calls it that in the translation keys and it's used for more than creative tabs. Item Groups are also used for recipe tabs.

net/minecraft/client/render/entity/EntityRenderer might not be the correct name for this.