Snapshot Information in .gradle

[delpi]

I had seen this before but didn't really understand the significance.  Hoping someone could guide me on it.

 

in my build file I have

 

mappings = "snapshot_20141130"

 

I'm going to the mcp_snapshot to find fields.csv for reflection. 

 

What i'm worried about is this being horribly out of data.  That sounds like its from last november???

 

Am I supposed to update this?  If so, how?

[jabelar]

A list is here.

 

Actually since they are daily snapshots you don't even have to check that list. I just always update it to the date of my build and it works (I guess in some timezones maybe you need to use the date for the day before the build).

[delpi]

That worked great.  Thanks guys.

 

I do have a related question that came to mind as I was verifying the fields were still the same.  Is there a trick you use to find the right version of the variable?  This is probably something obvious I just don't know,

 

For example there are 3 'flightSpeed" (might be flySpeed, going off memory).  I usually look at the other variables around it to help decide if it is right one, but I still find out when I compile it and try to run it on server that I picked poorly occasionally.

 

 

[jabelar]

That worked great.  Thanks guys.

 

I do have a related question that came to mind as I was verifying the fields were still the same.  Is there a trick you use to find the right version of the variable?  This is probably something obvious I just don't know,

 

For example there are 3 'flightSpeed" (might be flySpeed, going off memory).  I usually look at the other variables around it to help decide if it is right one, but I still find out when I compile it and try to run it on server that I picked poorly occasionally.

 

I think you're asking about when there are multiple fields or methods with similar names that might make sense. Like in a block there are methods isNormalCube(), isOpaque(), isFullCube(), etc. which I always am unsure which does what.

 

I use the Call Hierarchy tool a lot in Eclipse. Just highlight the field somewhere you've found it in the code base and then right-click and choose Call Hierarchy. It will show you what methods use that field. If you're still not sure you can expand those methods to see what calls them, and so forth.

 

Also, in modding since the interfaces aren't documented I'd recommend to ALWAYS inspect the code of any method you call to confirm it is really the one you want to use because sometimes there are surprises or outright mistakes. For example, I got really screwed up using the isClientWorld() method in EntityLivingBase. If you look at the code for their method it is:

 

    /**

    * Returns whether the entity is in a local (client) world

    */

    public boolean isClientWorld()

    {

        return !this.worldObj.isRemote;

    }

 

You'll see this actually is BACKWARDS! It returns whether it is a server world, not a client world. You can imagine how hard it was to debug that and how screwed up my mod was with all the client and server logic reversed!

[delpi]

Its really the multiple fields issue that plague me.  I'll try that with the ones that got me and make sure it would have caught it.    Thanks.

 

I've been able to look at the methods doing something very similar to what you said with success.

 

That is goofy on mojang's part.  Reminds me of 'Never trust Vanilla'

 

 

[jabelar]

That is goofy on mojang's part.  Reminds me of 'Never trust Vanilla'

 

I don't think it is Mojang. I think it is the MCP mapping. Someone was going through the code and decided on a mapping name, the person who suggested it got it backwards.

 

Now there are actual Mojang mistakes that can trip you up too. For example: The attackEntityAsMob() method is inherited from the EntityLivingBase class, however that class doesn't inflict any damage; rather it does nothing but update the last attacker, and in fact it seems to do this backwards (bug?).  Let's look at that briefly, here is the code from the EntityLivingBase attackEntityAsMob() method:

 

public boolean attackEntityAsMob(Entity par1Entity)

{

    this.setLastAttacker(par1Entity);

    return false;

}

 

If you think about the logic in the above method, it seems to be backwards -- you are setting the last attacker of this which is the attacking entity to be the other entity.  It seems it really should be instead: par1Entity.setLastAttacker(this).  (However, it is possible that the method is misnamed or something, maybe it is meant to set the last attacked, but looking briefly through the method it seems to be named correctly.)

 

It is further interesting that vanilla mobs (see EntityMob class or EntityWolf class) seem to fully override this method and don't call this as super method.  So this bug won't afffect Vanilla Minecraft but could certainly affect you if you extend EntityLivngBase in your mod.