modcoderpack / mcpbot-issues Goto Github PK

Both IWorldNameable and ICommandSender have the following srg methods: func_145748_c_, func_70005_c_. Neither of these classes extends from the other.

elementOffsetsById should be uvOffsetsById, same goes for hasElementOffset and getElementOffsetById.

What it says in the title.

Renaming it might make modders fix their implementations. Even BC does it wrong.

Parameter "Container.mergeItemStack.useEndIndex" should instead be called something like "reverse". useEndIndex does not tell the method whether to include the last index when searching for a slot to place an item stack in.

I (and i'm sure i am not the only one) really dislike the methods for getting game rule values:

• getGameRuleStringValue (func_82767_a and func_82756_a)
• getGameRuleBooleanValue (func_82766_b and func_82758_b)

While the int version is just called getInt (func_180263_c and func_180255_c)

I think, the string and boolean methods should be renamed to getString and getBoolean, because the 'gameRule' and 'value' part in the names make zero sense. You are already in GameRules, so the name doesn't need to indicate that.

That said, i suggest also renaming addGameRule (func_180262_a) to simply add.
Same for writeGameRulesToNBT (func_82770_a) and readGameRulesFromNBT (func_82768_a) to simply toNBT and fromNBT.

The impact of this change on existing mods would be small. I wrote a simple tool that analyses bytecode to see if specific methods are called, and i pulled a few complete modpacks through that. There are only a few mods using these methods, including a project i am working on. The impact is small, so i think it's safe to change.

It seems that the MobSpawner's base logic inherited much of the names for spawnerMinecarts.

The things that I think should be renamed:

• WeightedRandomMinecart -> WeightedRandomSpawnable (or something to signify it's not a complete entity)
• field_98285_e, minecartToSpawn -> possibleEntities

Version 1.8

For func_82567_a the parameter p_82567_8_ is not z it should be rotation. Similarly for the same method parameter p_82567_6_ is actually worldZ not y, finally for parameters the parameter p_82567_4_ should be mapped to worldX as x doesn't show the fact that it's not a map canvas x coordinate, it's a world relative coordinate. The method itself should be called updateMapDecorations not updatePlayersVisibleOnMap.

The field field_76203_h should be called mapDecorations as that's what it actually stores, not specifically players or entities. The name is misleading and confuses the fact that non-entity entries are accepted and perfectly safe.

As requested, here's the report:

I maintain a private changelog and noticed ~5K parameter names missing. Here's the diff:

https://gist.github.com/xaeroverse/e6ed35afc8e755a6e474

If you also check the export site, the latest params.csv is about ~25 KB but previous params.csv files are around ~130 KB in size.

edit: checking the "Last Change" field, these params seem to all report a date of 2014-09-25, which was the date when 1.8 supplanted 1.7.10 as the current bot version. I suspect this is more than just coincidence.

Or some better name, WorldRenderer only loosely describes one possible usage of this class.

See also: #52

http://export.mcpbot.bspk.rs/ is down? It seems that running a forge script needs the stuff here, which is in http://export.mcpbot.bspk.rs/versions.json

It seems like the constructor for EntityLargeFireball(World,DDDDDD) isnt available on servers, while both MCPBot and the javadoc say its there...
At least thats what i think this crash means:(only on servers, note that i tried without fastcraft with the same results) pastebin.com/RSyLyB4p

[22:00:59]  <kenzierocks>   gm CommandBase.compareTo
[22:01:01] -MCPBot_Reborn-  === MC 1.8: net/minecraft/command/CommandBase.compareTo (z.compareTo) UNLOCKED ===
[22:01:02] -MCPBot_Reborn-  Base Class : fd => Vec3i
[22:01:02] -MCPBot_Reborn-  Name       : compareTo => compareTo(Ljava/lang/Object;)I => compareTo
[22:01:03] -MCPBot_Reborn-  Descriptor : (Ljava/lang/Object;)I
[22:01:03] -MCPBot_Reborn-  Comment    : None
[22:01:04] -MCPBot_Reborn-  Last Change: 2014-09-25 17:06:49.952100-04:00 (_bot_update_)

I'm very sure fd => Vec3i is incorrect.

Instead, it should probably be named something along the lines of "getPropertiesMapWithValue", to make it clear that the function creates a new map, sets a property's value in that map, then returns the map.

This function used to be called isClientWorld a few years back (as described in issue #29) but was changed to isServerWorld because of the !world.isRemote check. isServerWorld was appropriate for most cases in 1.7.10 but 1.8 introduced new logic that makes the name inappropriate (actually, isClientWorld was correct for a different case as I'll describe below). Two subclasses in particular, EntityLiving and EntityArmorStand, override the definition to incorporate new NBT tags introduced in 1.8. As an example, I'll reduce EntityLiving for clarity but the same can be applied to EntityArmorStand:

    // EntityLivingBase
    public boolean isServerWorld()
    {
        return !this.worldObj.isRemote;
    }
    // EntityLiving extends EntityLivingBase
    public boolean isServerWorld()
    {
        return super.isServerWorld() && !this.isAIDisabled();
    }
    // EntityArmorStand extends EntityLivingBase
    public boolean isServerWorld()
    {
        return super.isServerWorld() && !this.hasNoGravity();
    }

Reduction of double-negatives:

super.isServerWorld() && !this.isAIDisabled()
!world.isRemote && !isAIDisabled
!world.isRemote && AIEnabled

Calling this function on the client will never return true. However, the case where the function is now a misnomer is when on the server, an entity's AI is disabled:

!world.isRemote && AIEnabled
true && false
false

As for a more appropriate name, I'm tentatively proposing canUpdateAI based on an important code section:

1.8 EntityLivingBase#onLivingUpdate

        this.worldObj.theProfiler.startSection("ai");

        if (this.isMovementBlocked())
        {
            this.isJumping = false;
            this.moveStrafing = 0.0F;
            this.moveForward = 0.0F;
            this.randomYawVelocity = 0.0F;
        }
        else if (this.isServerWorld())
        {
            this.worldObj.theProfiler.startSection("newAi");
            this.updateEntityActionState();
            this.worldObj.theProfiler.endSection();
        }

        this.worldObj.theProfiler.endSection();

1.7.10 EntityLivingBase#onLivingUpdate

        this.worldObj.theProfiler.startSection("ai");

        if (this.isMovementBlocked())
        {
            this.isJumping = false;
            this.moveStrafing = 0.0F;
            this.moveForward = 0.0F;
            this.randomYawVelocity = 0.0F;
        }
        else if (this.isServerWorld())
        {
            if (this.isAIEnabled())
            {
                this.worldObj.theProfiler.startSection("newAi");
                this.updateAITasks();
                this.worldObj.theProfiler.endSection();
            }
            else
            {
                this.worldObj.theProfiler.startSection("oldAi");
                this.updateEntityActionState();
                this.worldObj.theProfiler.endSection();
                this.rotationYawHead = this.rotationYaw;
            }
        }

        this.worldObj.theProfiler.endSection();

Other possibilities I thought of are:

• canUpdateEntityActionState (because of the call in newAi)
• canUpdateMovement (because of various references to motion in moveEntityWithHeading, and the NoGravity NBT tag in one of the definitions)
• canUpdatePosition

But, since the important code is within an AI section, I eliminated the canUpdateMovement/canUpdatePosition candidates. I also eliminated canUpdateEntityActionState because if this mapping were hypothetically applied retroactively to 1.7.10, it would be too specific as 1.7.10 has both the entity "oldAi" and "newAi" present (AI is more general than EntityActionState).

Of course, Minecraft's code is not straight-forward. The monkey wrench is net.minecraft.client.entity.EntityPlayerSP (extending EntityPlayer extending EntityLivingBase) which overrides the superclass's method definition to always return true. However, it also overrides onLivingUpdate so it seems that the overridden method is never called for EntityPlayerSP. Despite onLivingUpdate and moveEntityWithHeading being overridden, they do call the super() method at some point - I suspect this is the origin of the isClientWorld name.

So there are two cases to consider for this method: 1) one and only one EntityPlayerSP as instantiated by Minecraft.thePlayer, and 2) one or more EntityLivingBases on the logically local server (first one being the EntityPlayerSP). For now, canUpdateAI is my recommendation, though I can see the case for canUpdateMovement (esp. with the moveEntityWithHeading method). I'm open to suggestions as well...

Currently using a non-grouped nick while identified will present the user with a message that they should register their nick. The authentication code should detect that the user is identified and allow authentication to proceed with the identified nick regardless of whether their current nick is grouped or not.

EntityAIAttackOnCollide constantly repathfinds to target entity and will call attack method when close
EntityAIMoveTowardsTarget pathfinds once to target entity, and thats it

This class is the main 'chase target entity' class that all hostile land entities use, but the name doesn't quite explain it all

suggested rename:
EntityAIMoveTowardsTargetAndAttack

or maybe since its more about persistantly pathing to entity target, some suggestions:
EntityAIHuntTargetAndAttack
EntityAIChaseTargetAndAttack
EntityAIFollowTargetAndAttack

From EntityAIVillagerMate:

    private void giveBirth()
    {
        EntityVillager entityvillager = this.villagerObj.spawnVillager(this.mate);
        this.mate.setGrowingAge(6000);
        this.villagerObj.setGrowingAge(6000);
        this.mate.func_175549_o(false);
        this.villagerObj.func_175549_o(false);
        entityvillager.setGrowingAge(-24000);
        entityvillager.setLocationAndAngles(this.villagerObj.posX, this.villagerObj.posY, this.villagerObj.posZ, 0.0F, 0.0F);
        this.worldObj.spawnEntityInWorld(entityvillager);
        this.worldObj.setEntityState(entityvillager, (byte)12);
    }

(stable_16)

In the newest mappings, func_175549_o is setIsWillingToTrade. This is very clearly wrong, as it's only used in the mate AI. The field in EntityVillager is also wrong (field_175565_bs).

Credit for discovery to @unascribed

srg func_70058_J
Name : bR => func_70058_J => handleLavaMovement
Descriptor : ()Z
Comment : Whether or not the current entity is in lava

Proposed new data
Name: isNotColliding
Comment: checks that the entity is not colliding with any blocks / liquids

This is slightly annoying, and also has things listed as implementing when...it's a final class. Much confusion.

Some of the WorldGenerators for generating trees are named very inconsistently. Specifically in mind is the WorldGenerator for birch trees WorldGenForest which would be better suited as WorldGenBirchTree.

For reference here are all the WorldGenerators for the various tree types. WorldGenShrub (to WorldGenJungleBush) and WorldGenSwamp (to WorldGenSwampTree) are also possible candidates for renaming.

It's not actually a World Chunk manager. It provides biomes for the world (seeing as it's a one to one relationship of world to manager).

Possible names to suggest are:

• BiomeProvider
• BiomeManager
• BiomeGeneratorManager
• WorldBiomeManager

@Deamon5550 can likely provide more explanation and or name options.

GeneratorBushFeature is the only WorldGenerator not in the gen.feature package and not following the WorldGen* naming convention. Changing net.minecraft.world.gen.GeneratorBushFeature to net.minecraft.world.gen.feature.WorldGenBush would fix this inconsistency.

Possible names:

• WorldGenBush
• WorldGenSmallMushroom (it takes a BlockBush but is only used for mushrooms)

isRemote doesn't make any sense as its really for checking to see if this World is actually the client. Figured with 1.8.8 coming, this would be a good chance to get this in.

WeightedRandomChestContent has two fields named theMinimumChanceToGenerateItem and theMaximumChanceToGenerateItem. (field_76295_d and field_76296_e in 1.8)

Besides the obvious mouthful of words, these names are incorrect. If you look further down the class, at generateChestContents (func_177630_a), Minecraft picks a random number between these two fields, then assigns it to the stack size of the generated item. It has nothing to do with generation chance. (Forge forwards this to a method in ChestGenHooks that uses these fields as stacksize limits as well)

I propose that these two fields be renamed to minStackSize and maxStackSize to correct this.

func_72688_a is currently mapped to getMinecraftServer. This makes no sense because it returns a WorldServer instance, not a MinecraftServer instance.

Currently func_70005_c_ is mapped to getCommandSenderName(). While true for EntityPlayers, this doesn't make sense for Entities that can't execute commands. getName() would be a much better name.

Related #14

As of 16. February 7PM GMT decompiled Minecraft on the latest (Semi-Live) mappings doesn't recompile.

Issue affects: Client and Server
Affected class(es): ChatComponentScore and ChatComponentSelector
Affected method(s): createCopy()
Affected Searge name(s): func_179991_h and func_179996_i
Eclipse error message(s): "Duplicate method createCopy() in type ChatComponentScore",
"Duplicate method createCopy() in type ChatComponentSelector"
Person(s) who seem(s) to have caused it: minecrell

ServersideAttributeMap is used on both the client and server. Additionally, it's the only subclass of the abstract class BaseAttributeMap, so it makes more sense to simply call it AttributeMap.

Since BaseAttributeMap is only extended by one class, it makes more sense to call it AbstractAttributeMap - it doesn't really serve as a base class.

In WorldServer#tick, the method is called as follows:

this.worldInfo.incrementTotalWorldTime(this.worldInfo.getWorldTotalTime() + 1L);

As you can see, the incrementing is done by the caller.
Also:
snip

Proposed features:

• allow get queries
• implement a simple auth system
• allow set operations assuming that the user has appropriate permissions
• responses will be sent as json (format TBD)

Please describe use cases in comments.

Proposed use-cases:

• IDE plugin that can submit changes upon refactoring SRG names
• easy access to mappings for server support tools

handleHealthUpdate is wrong, needs to be something like processLogicOpcode

1: rabbit running particles / spawner delay reset
2: entity hit process (plays hurt sound)
3: death
4: iron golem throw attack

6: tame effect failed
7: tame effect succeed
8: wolf shake
9: finish using item
10: ignite tnt minecart, sheep timer?
11: iron golem hold rose
12: spawnheart villager
13: spawn angry villager particle
14: spawn happy villager particle
15: spawn witch particles
16: play zombie sound

17: create fireworks
18: spawn heart particles
19: reset squid rotation to 0
20: spawn explosion particles,
21: play guardian sound
22: reduce debug
23: full debug

The logic is inverted makes reading if statements terribly confusing.

The logic is backwards for the EntityLivingBase#isClientWorld(). If you look at the code it is:

/**
 * Returns whether the entity is in a local (client) world
 */
public boolean isClientWorld()
{
    return !this.worldObj.isRemote;
}

From a Minecraft perspective a client world is when isRemote is true, so you can see that the logic is backwards.

I suggest the name be changed to isServerWorld().

Note that EntityPlayerSP also has an isClientWorld() but that one is correct -- it returns true always, which makes sense for that case.

Currently, doing !!help in a channel still sends it to sender.

p_i1166_2_ lives in net.minecraft.server.management.PlayerProfileCache$ProfileEntry

http://puu.sh/fBCKh/3b55a1ed02.png

It would be nice to be able to receive replies to my commands from the bot with PRIVMSG to my nick. Hexchat and XChat2 both have the behavior that receiving a PRIVMSG creates a new window or tab just for the corresponding channel or nick, and would be more convenient when issuing many commands and reading at leisure (like when first learning to use the bot.)

Thanks :)

Basically, if I updated snapshots, I want to be able to know what a given name has changed to.

ItemReed used to be named for specifically the Item representation of a reed block, but now, it is instantiated for:

• cakes
• reeds
• string
• repeater
• brewing_stand
• cauldron
• flower_pot
• comparator

To be honest, I'm not 100% sure what the name should be instead, but as you can see, it's misleading for it to be named ItemReed. What this class does do is represent an item that isn't just the full rendering of a block, but strictly the item representation of what the block would be (the difference between a technical block itemstack and the actual item itemstack).

Some ideas: ItemRepresentedBlock, ItemBlockProxy, ItemBlockWrapper

<kenzierocks> bspkrs: need to fix EntityLivingBase.addRandomArmor, it has a wrong comment and wrong name
<kenzierocks> http://pastebin.com/JC3LEnhY
<kenzierocks> additionally, <AlphaModder> func_180481_a is the right one for addRandomArmor i think

Fix that, may require more investigation for the proper mapping.

will this show up in IRC?

If you click on "MCP News" on http://mcpbot.bspk.rs/ you get a HTTP 404 error because the Mod Coder Pack now has a new site. The button should open the website http://www.modcoderpack.com/website/.

field_179666_d should be called something like LOCATION_KEYS because it is used to determine if the command is locked to the sender's world or if it should apply to all worlds. Selectors that contain any of these keys will force the selector to stay in the sender's world.

in particular func_180656_a(isProvidingWeakPower) and func_176211_b(isProvidingStrongPower).
They have a is infront of them, but return the strength(int), which is confusing.
My proposal:
func_180656_a>getWeakPower
func_176211_b>getStrongPower

getPropertyNames returns a collection of properties rather than strings, so this name is incorrect.

The class EntityAIArrowAttack isn't specifically to arrows. It calls IRangedMob#attackEntityWithRangedAttack, which is used for launching Wither skulls in EntityWither.

I suggest EnittyAIRangedAttack or EntityAIProjectileAttack as better names.