AtlaStar

I was dead tired looking at the LasyOptional type and didn't notice getValue was a private member and that the class forces you to pass a consumer, so my mistake.

LazyOptional's are wrappers for a supplier that may or may not be stored at that time. With LazyOptional's you gotta check the type for whether it has a supplier or not by checking isPresent() on it, then use getValue(). You could also just skip the check and use getValue() but you'd have to then check to see if the returned value is null. So basically anywhere you are using a LazyOptional you have to use the getValue() method on it if you actually want the value. EDIT: yeah ignore this I messed up reading the LazyOptional methods last night and didn't notice getValue() was a private method and that it forces you to supply a consumer to ifPresent.

Well from here you have a few options. Disable all mods on the server and client end to see if your client connects or if it generates an error message or general inability to connect. Keep looking at your error logs and disabling mods that are throwing an exception until it works and contacting the authors of the mods which were causing issues. Easiest way to track down exceptions that occur is to use ctrl+f to search the log itself for the word Exception, and if you decide to choose the first option of disabling all mods on both the server and client and it produces an error, I'd post that log here because that could imply it is a Forge error along with details about what version of Forge your client and server are using.

Issue appears to be SecurityCraft...looks like their own VersionChecker utility class is pointing to a non-existent resource during modloading in the client. This appears to make it to where your connection is refused because the server thinks there is a version mismatch between the client and server in that the server just thinks your client doesn't have SecurityCraft. Basically your options are to try and see if SecurityCraft needs to update or if you are using version that is incompatible with your version of Forge, and if that fails either open an issue on the SecurityCraft github or find a SecurityCraft discord./forum where they can provide assistance in making sure your server and client environments are properly set up.

Looks to be related to this BOP issue here https://github.com/Glitchfiend/BiomesOPlenty/issues/1602 Long story short you should track that issue and pull requests which solve the issue, until then rolling back is really your only option. For future reference though, when you get errors and see a specific mod referenced in the stack trace the best bet is to check the mod's github. Should also have added to first check the issues to see if someone else has reported the error, otherwise open up an issue there.

Not super familiar with the inner workings of gradle but I also had the same issue when following the tutorial. I didn't bother to find a fix at the time but this question prompted me to look it up and I have noticed that the mods.toml that was created for me sets the version property to "${file.jarVersion}" while the version on Cadiboo's github has the element set to "${version}", so I have to assume that the expand operation is first trying to find the file property of the internal SimpleTemplateEngine, as the gradle docs show this is what the expand function uses to actually expand the elements, which the file property does not belong to explaining the error. I would try using the mods.toml file stub that Cadiboo is using located here and see if that resolves the issue, which seems likely to be the fix.

Suggest you read this.