Has forgeSrc been 100% completed for 1.12.2 yet?

[EM3R50N]

Apologies if this is in a FAQ somewhere else - point me there again if so - but how can modders find out if a forgeSrc is 100% finished for a specific Minecraft version yet or not?

 

I ask because as I was trying to update one of my mods yesterday from 1.12 to 1.12.2, I encountered missing methods in the 1.12.2 forgeSrc jars (I tried a few different releases: 2703, 2705, 2759).  If I dug down into the source I could eventually find the methods (but they had obfuscated method names like: func_178086_a(), func_77655_b() and func_77625_d() for example. 

 

Basically I'm trying to confirm if these new missing methods have been deprecated or just haven't been mapped/finished in forgeSrc yet.

 

Thanks and again my apologies if this is in a stickied/FAQ somewhere - I did look a bit first.

[Oen44]

I don't think that it will ever be 100% complete. It's a big project, bugs are always going to appear (not always big one).

[nullsector76]

1 hour ago, EM3R50N said:

Apologies if this is in a FAQ somewhere else - point me there again if so - but how can modders find out if a forgeSrc is 100% finished for a specific Minecraft version yet or not?

 

I ask because as I was trying to update one of my mods yesterday from 1.12 to 1.12.2, I encountered missing methods in the 1.12.2 forgeSrc jars (I tried a few different releases: 2703, 2705, 2759).  If I dug down into the source I could eventually find the methods (but they had obfuscated method names like: func_178086_a(), func_77655_b() and func_77625_d() for example. 

 

Basically I'm trying to confirm if these new missing methods have been deprecated or just haven't been mapped/finished in forgeSrc yet.

 

Thanks and again my apologies if this is in a stickied/FAQ somewhere - I did look a bit first.

those are mapping issues. you could simply fix this by updating your mappings. If they are still obfuscated it means they don't have  name for it yet and then you report it to mcp

[EM3R50N]

Thanks nullsection76 and Oen44. It just seemed odd those methods weren't mapped as I would consider them fairly important ones.  I was thinking maybe they, as you guys said, just weren't mapped yet - but:

1. I wasn't sure if / how we were to report these to MCP (or fork/pull request ourselves?)
2. And also I wasn't sure if it was a good idea to ship my mod with those non-mapped/obfuscated methods or if I should wait till they are mapped.

By the way for the record here are the methods before/after (so far):

// 1.12.2: Unmapped methods? --> Item.setMaxStackSize, Item.setUnlocalizedName and ItemModelMesher.register

// BEFORE (in 1.12):		
myItem = (myCustomItem) new myCustomItem(7,1.0F,false,"Custom Item Name",true).setUnlocalizedName("Custom Item Unloco Name").setMaxStackSize(8);
Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(...);

// AFTER/NOW (non-mapped):  
myItem = (myCustomItem) new myCustomItem(7,1.0F,false,"Custom Item Name",true).func_77655_b("Custom Item Unloco Name").func_77625_d(8);
Minecraft.getMinecraft().getRenderItem().getItemModelMesher().func_178086_a(...);

 

 

[DaemonUmbra]

It makes no difference, mapped methods get un-mapped during the build process of your mod so they properly target vanilla methods outside of your development environment.

If you're working with 1.12.X I recommend updating your mappings to stable_39.

[jabelar]

Just want to clarify the concept a bit. The vanilla source is "obfuscated" meaning that it is valid Java code but isn't really human-readable, mostly because all the fields and methods have names that don't mean anything (to humans). So as part of MCP there is a system of mapping human-friendly names to the actual names. This mapping is basically crowd-sourced -- up to the community to submit suggestions. Note that sometimes the suggestions aren't exactly right (I've seen cases of misnamed methods), and also sometimes the methods get adjusted over time based on trying to improve naming consistency

 

Since the mapping is often getting updated, it is important for your build.gradle to point to a fairly recent version. I recommend updating every week, especially in the early days of a new version when it is probably changing frequently.

 

In terms of whether it is "safe" to build a mod using an outdated mapping, it is because the friendly mappings are just to aid developers and the actual names are the correct ones for associating with vanilla.

 

Note that if you use Java reflection, you need to use a class called ReflectionHelper because of the mapping. In ReflectionHelper methods you need to specify both the mapped and original names. 

 

The mappings are maintained by MCPBot which you can use to find mappings, download CSV spreadsheets with latest listings, and submit suggestions for new ones. 

 

For 1.12.2 I would say that the mapping process is essentially "finished". When 1.13.x comes around though you'll get to observe a period where there are lots of unmapped ones that get better.

 

Each time you update the mappings there is a chance that your code will start throwing errors due to the change. You simply need to figure out what the new name is and correct your code -- a bit of a pain sometimes but unavoidable.

[Draco18s]

1 hour ago, jabelar said:

So as part of MCP there is a system of mapping human-friendly names to the actual names.

There's two steps here. One's a machine step, and one's the human step.

The part you talk about is the human step. The machine step organizes the classes into packages and renames the classes so that instead of a, ab, bz, and cf you have Minecraft, Block, ItemStack, and GuiContainer (these names, I believe, also come from MCP, but I'm not sure where in the process  it occurs). It also renames all methods, fields, and parameters called SRG names. These look like func_12893_f, field_90237_c or paramWorldIn1.  MCP then is a remap from those to human readable names, which are supplied via interacting with the MCPbot on IRC.

Edited September 4, 2018 by Draco18s

[EM3R50N]

Thanks everyone again - I learned a lot here. If there is a FAQ or sticky that sums up some of this please do point me there so I can reference that next time. Again my thanks to all.

 

19 hours ago, DaemonUmbra said:

It makes no difference, mapped methods get un-mapped during the build process of your mod so they properly target vanilla methods outside of your development environment.

If you're working with 1.12.X I recommend updating your mappings to stable_39.

This is very helpful to know - knowing this I can build and ship my mod file w/out worrying if it will break with forge mapping changes. Thank you!