Here is the file. It probably does not load, but I have spent four days trying to figure out why java's manifest reader thinks it is an empty file, yes a hacked copy of the reader works fine.Which is as soon as my access transformers start working.
Here is the file. It probably does not load, but I have spent four days trying to figure out why java's manifest reader thinks it is an empty file, yes a hacked copy of the reader works fine.
As I am out of ideas, it may be a java version/OS thing. Maybe one of you can run it. Note that it contains all my mods, and is not suitable for play.
Also, I just realized that the jar above does not contain the textures, sounds, or other resources, so is likely to crash anyways, or at least be very broken.
Never done anything in forge and Java is not my main language.It is not, as the manifest is not reading correctly.
The manifest is what is read by cpw's code on game launch to detemine if I have an AT and where it is. Other mods do in fact have this.Never done anything in forge and Java is not my main language.
Just read this and poked at a few of the mods with ATs:
The other at.cfg using mods don't have a line like this in their manifest.mf in meta-inf:
your meta-inf folder has the DragonAPI_at.cfg along with it being in the root of the zip (where it is for other mods).
Not sure if that would cause issues.
The manifest is what is read by cpw's code on game launch to detemine if I have an AT and where it is. Other mods do in fact have this.
It is possible to load an access transformer via a core plugin, so that is likely what the other mods are doing. I have no idea how to do this.I was trying to say no other mod in the list I made above of 1.7.10 mods using an *_at.cfg file has the:
FMLAT: *_at.cfg line in the manifest.mf file.
Some are empty or have a line or two to indicate they are core mods, but none have FMLAT declaration.
And non have their config in the meta-inf folder, all of them have it in the root where you also have a copy. I do not know if forge would be troubled by having it in two locations.
Like I said i don't use Java much and don't know the template for implementing this, but I see differences between your mod and the others I listed. Maybe they mean nothing or maybe they indicate a step in the build process is missing/different enough to break it.
It is possible to load an access transformer via a core plugin, so that is likely what the other mods are doing. I have no idea how to do this.
Having the file in multiple locations is not the problem; Forge never even searches for the file.
Basically, here is how it works. Forge loads, and scans the manifest file of the jar. It searches for the "FMLAT" property inside the manifest, which should return "DragonAPI_at.cfg". However, the return value is in fact null, and this is the root of the problem.
- Add support for mod access transformers without a coremod requirement. Use the "FMLAT" manifest attribute, with a space separate list of files that live in the 'META-INF' directory. They should conform to standard AT formatting.
I put it in both. Also, again the problem is not that it cannot find the file when looking for it. The problem is when forge reads my manifest file, getProperty("FMLAT") returns null, as if that line was not in my manifest file at all.Well, I'm really rusty on my Java, but I'm keen for RoC and ReC to get to 1.7, so I poked around a bit on the Forge site... Don't know if this helps but the changelog on the Forge build has a line;
Would it work if you moved the _at.cfg file to the META-INF folder? I'm guessing that the coremod versions can go elsewhere because of how they work but these ones might need to be local to the manifest file, for whatever reason.
The refrigeration unit manufactures liquid nitrogen.Had an electricraft question, so i thought I'd ask. How does one make "coolant" to fill the superconduting wires with? I know it has to go through the filler, but I just can't find the fluid/item that's supposed to be used.
Yeah, I noticed that I failed my Reading skill check on that one... oops.
The usual process I go through when debugging someone else's code is to try to make it crash, then work back from there. I've been playing around with the manifest file and dropping the .jar into the FTB Unstable pack mods folder (which is not exactly the safest test environment), and I've noticed that if I stick an extra newline in between the manifest version and the FMLAT entry, it crashes really, really fast - so it crashes with an 'invalid manifest' error, same as happened to you. However, it can read the manifest file just fine, because if I declare FMLCorePlugin: this.should.crash.java it tells me that it can't load that file (obviously). So there's something odd with how it's reading that specific tag in the file.
Okay... so I've poked and prodded it a bit more. If I take out the extra periods between the class declarations and the data items eg.
public net.minecraft.client.renderer.entity.RenderSlime field_77092_a #scaleAmount
with no . between RenderSlime and field_etc,
the error changes. It instead goes to
java.lang.NumberFormatException: For input string: "Reika-1"
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
etc. Which indicates that I've broken something just by playing with the access transformer file - so it is being read somewhere, if that helps? It got further than it did before, 'replacing 618 ore types', so I must have broken something else on the way?
Awesome manA little update: AFter weeks of practice and hard work, I know the mod pretty well now... and now it's hard to use anything else. The Grinder and Extractor are so cheap and easy to set up that it makes all other ore processing look crappy in comparison. xD