DaemonUmbra

I am talking about Forge's Jar-in-Jar system, NOT shadow... The mod you linked uses shadow, not Forge's Jar-in-Jar system

Because Forge's system is superior to just shoving your dependency inside your jar, Forge's system does things to prevent collisions between packed dependencies, as well as archiving them so they only need to be extracted once.

If you want to rely on the legacy system you can use Jar-in-Jar without a "Maven-Artifact" property, though from a code comment "Maven-Artifact" is likely to be required in Forge for 1.13. This means that you can do this without doing anything with meta files FOR NOW.

You need to run the installer to install Forge, it grabs the universal, the vanilla jar, and all the libraries needed to run the server.

Did you use the installer or did you just grab the universal?

I believe this could be accomplished with Shadow, however the Forge system allows archiving it so it can be extracted once and only once. I see now why you were automating the meta files while my test worked without, and I feel stupid. Seems my test relied on backwards compatibility, oops. Continuing to work on my test (even though it works i don't want to get in the habit of relying on old methods).

I have yet to see you use either method correctly and for some reason you appear to want to automate/complicate the painfully simple process of using Forge's Jar-in-Jar system.

What I linked is instructions for how to have Gradle add Manifest Attributes, this includes ContainedDeps. What is shown in the example on that page goes in your build.gradle

It is a folder for meta files (files that contain information about the jar itself), these are built by the tool that packages the jar. https://docs.gradle.org/current/userguide/java_plugin.html#example_customization_of_manifest_mf In this case though you will want to create the folder yourself, however do nothing more than create /META-INF/libraries/ and put your dependency jar into it.

Maven or not matters only for the jar being packed inside, and there is a built-in workaround for non-maven jars. Look at the "Dependency extraction" section.

Have you looked at the documentation I linked?

Please provide logs as described in my signature below.

Yeah, you're not using Shadow correctly. Update to 1.12 and use Forge's Jar-in-Jar system, it's much easier.

The forge log is called debug.log and should be sitting next to latest.log. Unfortunately a lot of this is ambiguous, can I ask how the server is being hosted and how you and your friend are connecting to it?

It was fixed about a month ago and has to do with your LWJGL being out of date.

I need to see everything in your project.

Is your source code posted somewhere? I have a hunch what your problem might be but I want to make sure.

Make sure all your mods are updated, BiomesOPlenty is mentioned and there are newer versions available.

Yes, both the server and client need to have copies of the mods, the server has a mods folder too.

You launched the vanilla server to play mods? Are you launching the server by double clicking or through a command line?

Please don't necro old threads, if you have a problem you want help with make your own thread. However, if your problem is with 1.7.10 then you are out of luck, we don't support it anymore due to its age.

I can't recall, does @Config work with Maps?

You seem to be under the impression that this is a breach of privacy... but exactly how is a users mod list sensitive information? You likely interact with sites powered by Google's ad tracking services on a daily basis, the information served to advertisers by those services is, imo, more "sensitive" than your Minecraft mod list.

Exactly why do you need a stealth mod if you're NOT doing something that's frowned upon?

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.