Geolykt · May 8, 2023 13:29
diff --git a/gistfile1.txt b/gistfile1.txt
 Obligatory foreword: Please be aware that the galimulator modding scene has moved in a very different direction compared to most JVM modding communities and we are still stuck in the past when it comes to certain things. While tinyv2 isn't something we plan to use anytime soon (we make hefty use of tinyv1 though), future developments could mean that newer versions of tiny are used, which is why I feel inclined to comment on this matter.

 Signatures: Those are already automatically generated by our deobfuscator, however the data it generates is directly applied to the jar. In the past there has been no need to store signatures separately to disk. In the future it is planned to double down on the automation, thus merging those files would make sense - especially if it is supported by enigma-like tools.

 Per-class default LVT names: An interesting idea - however I can't recall any cases where I'd need it. In minecraft space there is a larger usecase though given that suffixes and prefixes are used frequently.

 Annotations: Removal probably doesn't make much sense but addition of annotations certainly does (Nullability/Contracts overall, Api statuses and other metadata).

 Unpick data: Those will probably also be semi-automatically detected by the deobfuscator (currently they are left inlined) - especially GL/LibGDX constants would fall under that bin. Other constants are quite rare so merging a manually generated unpick (or whatever our equivalent would be) file with the central mappings file makes sense.

 Inner classes: Current (as of 5 months ago) fabric tooling deals astonishingly poorly with obfuscated (e.g. `snoddasmannen/galimulator/gv`) to deobfuscated inner class (`snoddasmannen/galimulator/Space$ActorSpawningPredicate`) mappings. The silver lining here is that there isn't a common fix to this issue. For galimulator the issue is in that the inner classes attribute was stripped by proguard so it'd need to be generated. Of course manually mapping otherwise independent classes to be inner classes is a strange approach and is solely based on the merity of keeping some resemblance of line mappings.

 `unchanged name`: As a good portion of galimulator is not obfuscated (i.e. everything that is serializiable isn't obfuscated), having a way to explicitly set that something is already deobfuscated makes sense. I've had issues in the past with getting enigma to notice that some names needn't be deobfuscated.

 `changes-package-access`: We don't have a use here either, especially since galimulator keeps the internal package structure intact.

 Sorted trees: The main reason we still stick with tinyv1 is that the order of lines doesn't matter in any shape. This allows for spaghetti deobfuscation while still not impacting performance. However since adopting newer tiny formats will necessarily mean that all mappings need to stored in memory until flushed to disk, sorting the trees wouldn't be a large performance disaster.

 AT/AW data: we do not have any use for that for the forseeable future. Mappings are project-independent. And ATs/AWs don't have a reason to exist in a project-independent manner.

 Comments: I make regular use of comments in my tinyv1 files (mostly for debugging purposes but sometimes also to keep stuff tidy), as such it comes as a suprise to me that tinyv2 isn't supporting them.

 Moving members and line mappings: I believe that mappers shouldn't change the internal structure of the class - may it only be in terms of logical location. Regardless, we don't have a use for this at all in galimulator space.
	Obligatory foreword: Please be aware that the galimulator modding scene has moved in a very different direction compared to most JVM modding communities and we are still stuck in the past when it comes to certain things. While tinyv2 isn't something we plan to use anytime soon (we make hefty use of tinyv1 though), future developments could mean that newer versions of tiny are used, which is why I feel inclined to comment on this matter.

	Signatures: Those are already automatically generated by our deobfuscator, however the data it generates is directly applied to the jar. In the past there has been no need to store signatures separately to disk. In the future it is planned to double down on the automation, thus merging those files would make sense - especially if it is supported by enigma-like tools.

	Per-class default LVT names: An interesting idea - however I can't recall any cases where I'd need it. In minecraft space there is a larger usecase though given that suffixes and prefixes are used frequently.

	Annotations: Removal probably doesn't make much sense but addition of annotations certainly does (Nullability/Contracts overall, Api statuses and other metadata).

	Unpick data: Those will probably also be semi-automatically detected by the deobfuscator (currently they are left inlined) - especially GL/LibGDX constants would fall under that bin. Other constants are quite rare so merging a manually generated unpick (or whatever our equivalent would be) file with the central mappings file makes sense.

	Inner classes: Current (as of 5 months ago) fabric tooling deals astonishingly poorly with obfuscated (e.g. `snoddasmannen/galimulator/gv`) to deobfuscated inner class (`snoddasmannen/galimulator/Space$ActorSpawningPredicate`) mappings. The silver lining here is that there isn't a common fix to this issue. For galimulator the issue is in that the inner classes attribute was stripped by proguard so it'd need to be generated. Of course manually mapping otherwise independent classes to be inner classes is a strange approach and is solely based on the merity of keeping some resemblance of line mappings.

	`unchanged name`: As a good portion of galimulator is not obfuscated (i.e. everything that is serializiable isn't obfuscated), having a way to explicitly set that something is already deobfuscated makes sense. I've had issues in the past with getting enigma to notice that some names needn't be deobfuscated.

	`changes-package-access`: We don't have a use here either, especially since galimulator keeps the internal package structure intact.

	Sorted trees: The main reason we still stick with tinyv1 is that the order of lines doesn't matter in any shape. This allows for spaghetti deobfuscation while still not impacting performance. However since adopting newer tiny formats will necessarily mean that all mappings need to stored in memory until flushed to disk, sorting the trees wouldn't be a large performance disaster.

	AT/AW data: we do not have any use for that for the forseeable future. Mappings are project-independent. And ATs/AWs don't have a reason to exist in a project-independent manner.

	Comments: I make regular use of comments in my tinyv1 files (mostly for debugging purposes but sometimes also to keep stuff tidy), as such it comes as a suprise to me that tinyv2 isn't supporting them.

	Moving members and line mappings: I believe that mappers shouldn't change the internal structure of the class - may it only be in terms of logical location. Regardless, we don't have a use for this at all in galimulator space.