Log to file

[Slind14]

Hey,

atm the logging is not included within the forge and server log. Could you consider giving it its own log again, like in tickthreading? It is quite hard to follow up on the console by all these log spam that mods produce.

[LunNova]

The logging should end up in the forge log, and does in my testing.

If you're using a custom build for 1.6.4 it won't because in 1.7.10 everyone moved to using log4j for logging, which is also what ModPatcher uses.

[Slind14]

ohh, yeah my fault. But I think it would still be great to have it logged to its own file for easier bug fixing. (tail -f modpatcher.0.log)

[LunNova]

Done 76f1a0cca3d0cddd04e5e8f1.

[Slind14]

wow after profiling 1.7 a bit.. Looks like forge did create a new bottleneck with log4j, that looks insane for a logger. :(

[Slind14]

the extra log doesn't work properly. It shows: ModPatcher running under classloader net.minecraft.launchwrapper.LaunchClassLoader But the errors only appear in the main log.

[LunNova]

And that's definitely tested under a normal 1.7 setup, not your interesting 1.6 build? It's working fine for me :P

[Slind14]

yes, the 1.6 port works fine. :)

[Slind14]

this is the patch:

<mods>
    <fakeworld>
        <class id="org.bukkit.craftbukkit.v1_7_R4.CraftWorld">
            <insertBefore code="{ if(this.world.^method:World/getSaveHandler^() == null) return null; }">getUID</insertBefore>
            <insertBefore code="{ if(this.world.^method:World/getSaveHandler^() == null) return 0; }">hashCode</insertBefore>
        </class>
    </fakeworld>
</mods>

(btw. am I doing something wrong with this patch? I can't figure out what.)

Which results in https://gist.github.com/Slind14/4433f1f7de1316f20a64 While the modpatcher log looks like this:

ModPatcher running under classloader net.minecraft.launchwrapper.LaunchClassLoader

[LunNova]

The issue with that patch is that the "insertBefore" patch has been renamed to "insertCodeBefore". Have a look at Patches.java. The current 1.1-SNAPSHOT release of JavaPatcher is in the process of being properly documented, and having a proper naming scheme for patches.

That should've given a proper error message instead of crashing with an NPE, I'll fix that.

Not sure why the logging isn't working for you, could be an ordering issue which the commit I just pushed might fix. Might being the key word.

On 28 September 2014 20:51, Slind14 notifications@github.com wrote:

this is the patch:

getUID hashCode

Which results in https://gist.github.com/Slind14/4433f1f7de1316f20a64 While the modpatcher lgo looks like this:

ModPatcher running under classloader net.minecraft.launchwrapper.LaunchClassLoader

— Reply to this email directly or view it on GitHub https://github.com/nallar/ModPatcher/issues/5#issuecomment-57097606.

Ross Allan

[Slind14]

Alright thanks. Btw. there is a small 's' in the commit which I don't think belongs there.

[Slind14]

Well the patch is working fine now. So I don't know if the log works now or not :D. Gonna create a test server for it now.

[Slind14]

mhh, it doesn't complain anymore about the insertBefore. (no where)

[LunNova]

Couldn't find patch with name {the patch's name here} at least should show up in console, if not in the log file.

[Slind14]

The broken patch I tried:

<!-- modpatcher.xml -->
<mods>
    <eventHooks>
        <class id="net.minecraft.world.World">
            <insertBefore code="{ System.out.println(&quot;Example logspam&quot;}; }">getBlock</insertBefore>
        </class>
    </eventHooks>
    <fakeworld>
        <class id="org.bukkit.craftbukkit.v1_7_R4.CraftWorld">
            <insertBefore code="{ if(this.world.^method:World/getSaveHandler^() == null) return null; }">getUID</insertBefore>
            <insertBefore code="{ if(this.world.^method:World/getSaveHandler^() == null) return 0; }">hashCode</insertBefore>
        </class>
    </fakeworld>
</mods>

The entire log with build 43: https://gist.github.com/Slind14/31353679562c3908ca6e

Somehow I can't find anything about the patch. (the ModPatcher.log looks the same)

[LunNova]

[22:34:22] [main/ERROR] [JavaPatcher/]: Couldn't find patch with name insertBefore when patching net.minecraft.world.World

The ModPatcher.log is the same as before, not including the JavaPatcher stuff?

[Slind14]

ohh you updated the patcher, sorry I wasn't aware of that.

The full content of the ModPatcher.log:

ModPatcher running under classloader net.minecraft.launchwrapper.LaunchClassLoader

Does it really work for you? If so, could it be a compatibility issue?

[LunNova]

I can't easily test it just now, but I'm sure it was working when I implemented it.

Might be related to using Spigot/CB if that changes the logging setup?

I know the logging in NTweaks, which is almost exactly the same, works.

If you're running NTweaks and ModPatcher on the same server, maybe the patcher log is only ending up in the NTweaks log?

edit: NTweaks currently includes a bundled ModPatcher. I'll be changing it at some point to auto-download ModPatcher to the mods folder instead, so you can't end up with NTweaks containing an old ModPatcher version/don't have issues if two things depend on ModPatcher.

[Slind14]

after further testing with the ideas you put out: ntweaks + modpatcher does break the modpatcher log. When using botht the ntweaks log does not include the modpatcher related log entries.

Thank you very much for your support.