Fix package.info files

Ok i do not want to see what happens when i release IC2Classic with my fixed Package.info files and your files that are still the same.
Before you say thats to much work and will take hours. No it takes 5 minutes.... An here is the thing i provide you even all names so they are synced and also allowing part usage of ic2 api without causing issues to other mods thinking the whole mod is loaded...
And it fixes your Forge Throwing Error problem.
If you do not want to add that then delete all other package infos and just leave 1 there... Then your error log is also fixed and i can adjust to that... But fix it.

Here all package infos names:

ic2/api: @API(apiVersion="1.0", owner="IC2", provides="IC2API")
ic2/api/crops: @API(apiVersion="1.0", owner="IC2", provides="IC2CropAPI")
ic2/api/energy: @API(apiVersion="1.0", owner="IC2", provides="IC2EnergyAPI")
ic2/api/energy/event: @API(apiVersion="1.0", owner="IC2", provides="IC2EnergyEventAPI")
ic2/api/energy/prefab: @API(apiVersion="1.0", owner="IC2", provides="IC2EnergyPrefabAPI")
ic2/api/energy/tile: @API(apiVersion="1.0", owner="IC2", provides="IC2EnergyTileAPI")
ic2/api/event: @API(apiVersion="1.0", owner="IC2", provides="IC2EventAPI")
ic2/api/info: @API(apiVersion="1.0", owner="IC2", provides="IC2InfoAPI")
ic2/api/item: @API(apiVersion="1.0", owner="IC2", provides="IC2ItemAPI")
ic2/api/network: @API(apiVersion="1.0", owner="IC2", provides="IC2NetworkAPI")
ic2/api/reactor: @API(apiVersion="1.0", owner="IC2", provides="IC2ReactorAPI")
ic2/api/recipe: @API(apiVersion="1.0", owner="IC2", provides="IC2RecipeAPI")
ic2/api/tile: @API(apiVersion="1.0", owner="IC2", provides="IC2TileAPI")
ic2/api/util: @API(apiVersion="1.0", owner="IC2", provides="IC2UtilityAPI")

These are all names you just copy paste it thats 5 min work...
If you do not want to do that here is the second option but one of them has to happen because i do not want error spam because you guys are to lazy to fix it (and i am laying you the fixed code diretly on your feet)

Just keep this one and delete all others if you do not want to go the first option:

ic2/api: @API(apiVersion="1.0", owner="IC2", provides="IC2API")

ok i even accept this!

Quote from Player

The warnings come from IC2 being a coremod and are bogus/unsubstantiated. I'll just delete all package infos/@API support since Forge refuses to fix its bugs and it's commonly misused.

I am thankfull that you took your broken usage of the IC2 API but it seems that you didnt understand how to use the package.info API.
Let me explain you what it is for.

The PackageInfo API (API API in short) is there to Split the API in 2 ways,

1: First that people are no longer forced to use all parts of an API and do not cause issues
2: Second and most important is that you can split the API from the mod so that mods can still use the interfaces and benefit from the things they provide.
Simply a Indirect OreDictionary.
Simply COFH API is based around that concept. COFH is not required but everyone can still use RF without having to check for specific mods. They search just for the API and thats it.
Its a very basic but well running & userfriendly system. The idea behind that is very good.

Also it seems that you have missunderstood the concept and did not even use it properly and call it bad on their side...
I told you how to use it right and you still say its used wrong on common bases?
No its the same thing as the getDisplayName issue i had to tell you to fix it, or the getUnlocalizedName that you had to change twice to make it work properly how it should has to be done (when you just could it done with one time fix)

It seems like more that you do not understand common based systems because FMLs PackageAPI system works as intendet & the idea is behind to split the API with these package API infos into components so you can ask for stuff with @Optional and do not require a mod for that is very good and people did think themseves something when they created something like that...

Edit: And FML Is throwing Errors because you used a Splitting system to mark all components as the same. Which is equal to not using it or using only 1 packageinfo. So you used it wrong.

Quote from Player

Of course the splitting is NOT the cause of the warnings. If you looked at the source code of their origin for more than 30 seconds, it'd be blindingly obvious that you are plain wrong there too.

It is throwing errors becuase you are trying to register multible PackageInfos with the same name. I only knew how to fix it because i readed the code...

Quote from Player

It is not, this is a major design flaw in @API itself and you seem to have no idea how it actually works.

Awww...

Quote from Player

All it tells you is that the package is present, whether there are actually any classes besides package-info is completely arbitrary with zero guarantees. Thus using API mod containers in @Optional just as wrong as assuming that required-after:<some API mod container> allows you to expect any classes to be available on the class path. The system would have to use annotations on classes, not on packages, to represent the availability of classes.

Yeah and that is important. Its a TrustBased API that someone who copies a part of the API (the full part) out of a mod and intigrates that... And here is the thing: IF people would use ModContainers in the @Optional API then most of the things like RF API would not even work because every mod would have to inset every mod that supports RF instead of a API package info that is telling: Hey i found the RF API Package ok you guys can load...

If you are not able to understand such Trust based things then i am sorry for IC2Exp because these are basements... If you want to make modcompatiblity with anything or provide compat you have to trust that these mods do their thing right if you can not do that then you are at the wrong place for things like that. But you do not even need to answer that because so far everything API related that i saw from you is either mostly not fully useable or completly incompatible with userfriendlyness...
Best example: Removing World/Pos Access from IReactor and forcing people to TileEntity cast things.
Same goes for the IEnergyTile EnetAPI. Instead of making functions that convert IEnergyTile to world/pos you could have added these functions to IEnergyTile + a IsValid function (or isInvalid)... That would even remove the TileEntity Requirement of EnergyTiles which removes the Requirement of FakeTileEntities which is nowdays actually very dangerouse to use because a lot of access to Classes can be done now even before the Class is fully constructed...