hohserg

I found a strange bug that can be reproduced by steps: Create empty gradle project(without any plugins) (by intellij idea) Create submodule `app` which contain regular forge mdk Create submodule `common` which contain annotation `Mark` and class `ClassFromSubmodule` Create submodule `annotation-processor` which contain anootation processor which generate simple companion class for each class annotated with `@Mark` Add some code: //Test.java, `app` submodule //annotation processor will generate TestCompanion for it(and he doing it) @Mark public class Test { } //M

I found a pretty thing: `IModLocator#findPath` It's look as good solve to get actual location of "service" files for each mod

Well. How to determine which class does the mod relate to? Look excessive Maybe it's a bad idea to call this thing as 'service'. Service is a most similar thing. Generally thing which I need is a file with list of names of classes which been found(and generated) by my annotation processor and readable by my mod. And multiple mods in one modpack can contain such file Sorry, it's my wrong understanding of ServiceLoader

If I use ServiceLoader, how it will work with multiple jars with identically named service files? As I know, ServiceLoader resolves existence of multiple same service files by taking first. It's also can resolve by ClassLoader, but I dont know, is Forge use separeted class loaders for each mod and is it be true it future. Also, ServiceLoader gives instances of classes which specified in service, but I'm need to instances of Class<?> of these classes. So, standard utility is not look as appropriate

I doing my annotation processor which generate service file for current mod. And I doing my mod which looking for such services in all mods in modpack. Forge can provide location of mod, whether it is an jar or in-dev-folder. The problem is getting actual location of service file. For jar is trivially and work fine. For in-dev-folder it's hard: File provided by Forge is not only one folder with mod files (look screenshot) It's really problematic and now I'm stumped. Any ideas? Also I can consider other ways instead of services. Related code: ht

I want to read capability of offline player

How to get `File` instance for directory which contain saved world? At 1.12.2 I can use `DimensionManager#getCurrentSaveRootDirectory`. What analogue at 1.16.5?

What is analogue of -Dlegacy.debugClassLoading=true -Dlegacy.debugClassLoadingSave=true arguments for 1.16.4?

Seems like I didn't understand sense of log level and trace markers. Can you explain it?

Oops, not solved I use `-Dforge.logging.console.level=debug -Dforge.logging.markers=SCAN,REGISTRIES,REGISTRYDUMP,CLASSLOADING` But messages of `LOGGER.trace(CLASSLOADING, ...)` is not visible in debug.log file

Ok, it solved `-Dforge.logging.console.level=debug`

Is it possible from command line arguments also?

Minecraft and Forge contains some code like LOGGER.trace(CLASSLOADING, ...); I want to see such messages in log (better to see all log messages). I didn't find `log4j2.xml`or something similar at game jar. How to change default log level?

I set up a publication to maven, but using `fg.deobf` warped dependency version in pom-file. How to fix? My build.gradle: https://github.com/ElegantNetworking/ElegantNetworking_1.15/blob/master/build.gradle Problem in pom: <dependency> <groupId>codechicken</groupId> <artifactId>CodeChickenLib</artifactId> <version>1.15.2-3.3.4.402_mapped_snapshot_20200514-1.15.1</version> <classifier>universal</classifier> <scope>compile</scope> </dependency> `1.15.2-3.3.4.402_mapped_snapshot_20200514-1.15.1` is

I set up a publication to maven, but using `fg.deobf` warped dependency version in pom-file. How to fix? My build.gradle: https://github.com/ElegantNetworking/ElegantNetworking_1.14/blob/master/build.gradle Problem in pom: <dependencies> <dependency> <groupId>codechicken</groupId> <artifactId>CodeChickenLib</artifactId> <version>1.14.4-3.2.8.374_mapped_snapshot_20190719-1.14.3</version> <classifier>universal</classifier> <scope>compile</scope> </dependency> </dependenci