While the SLL ecosystem is focused on transforming the game through runtime bytecode patches, the SML toolchain is focused on ahead of time recompilation of galimulator.
At this point, SML6 is technically game agnostic (provided it has), and has little focus on the decompilation and recompilation aspect it should have at a later point in time. Instead, the focus is initially set on the lengthy process of generating mapping files.
SML6 uses gslStarplane's Autodeobf configuration, meaning that it is also creating spStarmap-compatible mapping files.
All example code snippets in this document use groovy, unless otherwise specified.
SML6 provides the following tasks:
org.stianloader.sml6.tasks.AggregateMappingsTaskorg.stianloader.sml6.tasks.DeobfuscateGameTaskorg.stianloader.sml6.tasks.FetchGameTaskorg.stianloader.sml6.tasks.GenerateEclipseRunTaskorg.stianloader.sml6.tasks.GenerateSourcesTaskorg.stianloader.sml6.tasks.RemapJarTaskorg.stianloader.sml6.tasks.SLLJavaExecTaskorg.stianloader.sml6.tasks.StripDependenciesTaskorg.stianloader.sml6.tasks.XZTarBallerTaskorg.stianloader.sml6.tasks.XZCompressTask
Unlike gslStarplane, all tasks should be compatible with gradle's configuration cache by default.
Please note that unlike gslStarplane, no tasks are configurated by default. As such, you need to register the tasks in the way you want. Of course, some conventions are applied for your sanity. Please refer to the "Task configuration" section for more in-depth information on the configuration of individual tasks.
SML6 also provides the following internal tasks; they are not meant for direct use by API users:
org.stianloader.sml6.tasks.AbstractArtifactTask
SML 6 provides the following artifact transforms:
org.stianloader.sml6.transforms.ApplyRASArtifactTransform
All artifact transforms provided by SML6 are cacheable.
Like the tasks in SML6, the artifact transformations are not configured by default, meaning that they have to be explicitly registered. Further, some parameters need to be set for them to work. However, some parameters will use sane defaults that should work across the board.
The AggregateMappingsTask task defines following properties:
inputFormat(mandatory):Property<MappingFormat>, defines the format in which the input files are stored in.outputFormat(mandatory):Property<MappingFormat>, defines the format of the output file.
The AggregateMappingsTask extends AbstractArchiveTask, meaning that the
task inputs and outputs can be defined as it should be expected of tasks of
that type.
The fully qualified name of MappingFormat is net.fabricmc.mappingio.format.MappingFormat
which is an enum provided by fabric's mapping-io library. For convinience, sml6 provides
the inputFormat(String) and outputFormat(String) methods to set the value of
the respective properties without having to use the fully qualified name.
In essence AggregateMappingsTask is a task that converts mapping files between
formats. However, the main usecase is converting an enigma directory into a single
file - usually the tinyv2 or enigma formats. Although it might be theoretically
possible to use this task to "explode" a mapping file into an enigma directory,
doing so is not particularly recommended due to the semantics of AbstractArchiveTask.
This task does not perform descriptor inferrence or other things that might be required to convert from formats that might omit certain metadata.
Example task configuration:
task aggregateToTiny(type: org.stianloader.sml6.tasks.AggregateMappingsTask) {
from "src/mappings"
group = "build"
archiveExtension = "tinyv2"
inputFormat "enigma"
outputFormat "tiny v2"
}The DeobfuscateGameTask task defines following properties:
autoDeobfVersion:Property<String>, controlls the version of Autodeobf (only"5.0.2"supported at this point)withAutodeobf:Property<Boolean>, controlls whether to run AutodeobfwithSLDeobf:Property<Boolean>, controlls whether to run slDeobf/oaktreewithSLDeobfMappings:Property<Boolean>, controlls whether to generate slIntermediary mappingsoutputDirectory:DirectoryProperty, output files will be stored there by defaultoutputJar:RegularFileProperty, the deobfuscated jar will be stored thereinputJar(mandatory):RegularFileProperty, the obfuscated input jarslIntermediaryMappings:RegularFileProperty, output file for the slIntermediary mappings generated by sl-deobf. Uses the tinyv1 format.spStarmapMappings:RegularFileProperty, output file for the spStarmap mappings generated by Autodeobf. Uses the tinvyv1 format.
Unless otherwise specified, conventions exist that use sensible default
values. For non-galimulator games, you may want to change
withAutodeobf, withSLDeobf, and withSLDeobfMappings,
though honestly only withAutodeobf is really mandatory.
Keep in mind that SML6 expects games to always be a monojar,
an assumption that really does not make much sense. You are welcome
to change it (provided you ensure that it actually does what you want,
I can fix my end later :p).
Note: Although this goes against common sense, the Switchmap classes get remapped via sl-deobf, but no mappings file will be generated. So … just don't touch them. This issue will be resolved eventually, but requires patches to sl-deobf.
The FetchGameTask task defines following properties:
aggressiveCaching:Property<Boolean>, whether to cache aggressively. This may easily result in outdated jars for games that update frequently, at the benefit of much better performance.outputJar:RegularFileProperty, the resolved game jar will be stored at the location provided by this property.primaryGameJar:RegularFileProperty, this is the primary location to look for the jar. If the jar does not exist at that location, only then it will try to find it through common steam installation directories. This property should be set to allow people to work with older versions of a game, as well as for CI/CD purposes.steamApplicationId(mandatory):Property<Integer>, the appId of the game to fetch. This is the primary method of obtaining the application installation directory. The installation directory will be resolved through Steam's application manifests.steamApplicationName(mandatory):Property<String>, the name of the steam application, or rather the name of the directory your game is located in relation to the "common" directory. This method of retrieving the installation dir is a fallback in case the appid approach does not work. Though quite frankly it is unlikely to work well. Also, keep in mind that external library folders will not get queried.steamJarPath(mandatory):Property<String>, the path of game jar in relation to the game's installation directory on steam.
SML6 expects games to be bundled as a single jar in the style of packr and roast. However, many games are likely to be bundled across multiple jars. In that case, just create a merge request to SML6 to implement the desired functionality. I unfortunately lack the resources to do the job for you (after all, I won't be modding the same game as you).
This task is most well tested on linux, though different distros and methods of installing steam (e.g. through flatpak, ew)
may induce issues. Windows should theoretically work, but the used code is very old by now and hasn't been tested in years.
However, on MacOS this task will outright fail to function properly, though the primaryGameJar property can be useful to
work around this issue without compromising the experience for other users.
Example task configuration:
task fetchGalim(type: org.stianloader.sml6.tasks.FetchGameTask) {
steamApplicationName = "Galimulator"
steamApplicationId = 808100
steamJarPath = "jar/galimulator-desktop.jar"
}The GenerateEclipseRunTask task defines following properties:
args(mandatory):ListProperty<CommandLineArgumentProvider>, the command-line arguments passed to the main classjavaVersion(mandatory):Property<JavaVersion>, the version of Java to use at runtime.jvmArgs(mandatory):ListProperty<String>, the JVM arguments to use (includes system properties).mainClass(mandatory):Propert<String>, the main class of the run.moduleName:Property<String>, value of theorg.eclipse.jdt.launching.MODULE_NAMEattribute. Probably best to leave it alone as this task doesn't handle JPMS well.outputFile(mandatory):RegularFileProperty, the destination file to write the launch config into.projectName:Property<String>, value of theorg.eclipse.jdt.launching.PROJECT_ATTRattribute, also used for project-specific classpath entries. Automatically retrieved from theEclipseModel, or set to the project's name if the eclipse plugin is not present.workingDir(mandatory):DirectoryProperty, the working directory for the launch runtime. This property affectsworkingDirPath.workingDirPath:Property<String>, the working directory for the launch runtime. This property is automatically resolved throughworkingDir. This property is only required to prevent gradle from considering the task not up-to-date when contents within the working dir change, even though it's irrelevant for this task.
The GenerateEclipseRunTask generates an eclipse JDT-compatible *.launch file from any given JavaExec task.
However, the task can also be configured like any other other task if so desired, without having to use a JavaExec task as a base.
This task provides the from(JavaExec) and from(Provider<JavaExec>) methods to configure this task faster.
It will copy over all relevant properties. It even automatically sets the outputFile property to a sensible value!
Example task configuration:
task genEclipseRuns(type: org.stianloader.sml6.tasks.GenerateEclipseRunTask) {
from tasks.named('runMods') // this is preferred over `from tasks['runMods']` or `from runMods` because this uses configure on demand.
}The GenerateSourcesTask task defines following properties:
decompileOptions:VFDecompileOptions, the options passed to the Vineflower decompilerinputJar(mandatory):RegularFileProperty, the obfuscated input jarjavadocSources:ListProperty<MIOMappingsProvider>,libraryClasspath:Property<@Nullable FileCollection>, a file collection that describes the library path forwarded to Vineflower. This file collection should only contain jars, other file types might break. Note: Default value is the resolved contents of thetransitiveDependenciesproperty.lineRemappedOutputJar:RegularFileProperty, the file in which the line remapped jar should be stored. If VF was configured to remapLineNumberNodes, then this output file's line numbers will correspond to the decompiled source code. Otherwise, this is the input jar.outputDirectory:DirectoryProperty, output files will be stored there by defaultoutputSourcesJar:RegularFileProperty, the decompiled output jar will be stored at this location.transitiveDependencies:Provider<@Nullable Configuration>, a resolveableConfigurationobject that is the default source of thelibraryClasspathproperty.
The GenerateSourcesTask has following subclass which is in turn used to configure the task further:
org.stianloader.sml6.tasks.GenerateSourcesTask.VFDecompileOptions
The GenerateSourcesTask decompiles the given input jar, and produces a sources jar for that jar, as well as a jar that contains line number information that corresponds to the sources jar (as well as possible that is, the tooling makes plenty of mistakes for now).
The library classpath passed to the decompiler mostly affects @Override annotations, though it may affect
other small things such as casts when the type hierarchy isn't certain due to missing libraries or when
generic signatures aren't known.
This task provides the following methods to more easily configure the task:
addJavadocSourcesConfiguration(Action<MIOMappingsConfigurationProvider> configurationClosure): Register aMIOMappingsConfigurationProvideras javadoc source. This is probably the method you'll use the most of the addJavadocSources[…] trio.addJavadocSourcesDir(Action<MIOMappingsDirectoryProvider> configurationClosure): Register aMIOMappingsDirectoryProvideras a javadoc source.addJavadocSourcesFile(Action<MIOMappingsFileProvider> configurationClosure): Register aMIOMappingsFileProvideras a javadoc source.decompileOptions(Action<VFDecompileOptions> action): Configure the decompiler options as a closuregetDecompileOptions(): Get theVFDecompileOptionsobject used for configuration.
Example configuration:
task genSources(type: org.stianloader.sml6.tasks.GenerateSourcesTask, dependsOn: stripGalim) {
inputJar = stripGalim.outputJar
libraryClasspath = stripGalim.strippingDependencies
outputSourcesJar = outputDirectory.file("galimulator-" + deobfGalim.autodeobfVersion.get() + "-sources.jar")
lineRemappedOutputJar = outputDirectory.file("galimulator-" + deobfGalim.autodeobfVersion.get() + ".jar")
decompileOptions {
removeSynthetic = false
verifyAnonymousClasses = true
setOption("include-runtime", true)
}
addJavadocSourcesFile {
containerFormat = TAR_XZ
mappingFormat = ENIGMA
mappingSource = tarballXZ.archiveFile
dstNamespaceId = -1 // Source namespace
}
}Most of the properties in the VFDecompileOptions class are automatically generated using Gradle's PropertyMixIn.
The automatically generated property names are case-insensitive versions of the constant names within
https://github.com/Vineflower/vineflower/blob/35f2c6e2b65746d8fc4358ced8de03d440f2b80b/src/org/jetbrains/java/decompiler/main/extern/IFernflowerPreferences.java
The VFDecompileOptions class also defines the getKotlin and setKotlin(boolean) method to enable the vineflower kotlin plugin,
see https://vineflower.org/usage/#plugin-kotlin - keep in mind that plugin arguments need to be set through setOption(String, boolean)
or setOption(String, String). The only exception is the --kt-enable option which can be enabled/disabled using setKotlin(boolean)
(or, in groovy code using kotlin = false). The kotlin plugin is enabled by default, or rather SML6 inherits the default properties
for most arguments except for those related to line remapping infrastructure.
When decompiling classes that have the .kt file extension as per the debug source attribute whilst the kotlin plugin is disabled,
the GenerateSourcesTask will automatically change the file extension to .java inline to the actual vineflower output.
Keep in mind that it doesn't do that if line remapping isn't being performed however there is no rational reason to disable
line remapping anyways - at least not when working with an IDE and in that case you'll probably want to have the correct file extension.
For cases where line remapping isn't desired, the file extension probably doesn't matter.
The RemapJarTask task defines following properties:
inputJar(mandatory):RegularFileProperty, the input jar to remaplibraryJars:Property<FileCollection>, defines a list of jars whoose contents should be used to inferr member realms. Especially required for mixin remapping.mappings:ListProperty<MIOMappingsProvider>, the mappings to use. SeeaddMappingsDir/addMappingsFilefor convinience methods to register a mappings directory/file.
The RemapJarTask extends AbstractArtifactTask, inheriting all it's properties.
The RemapJarTask is a task which remaps an input jar (it also remaps mixins and reversible-access-setters definitions), doing nothing
more. The RemapJarTask does not modify any of it's inputs (this is needed for caching to work in a sense).
This task provides the following methods to more easily configure the task:
addMappingsConfiguration(Action<MIOMappingsConfigurationProvider> configurationClosure): Register aMIOMappingsConfigurationProvideras mappings source. This is probably the method you'll use the most of the trio.addMappingsDir(Action<MIOMappingsDirectoryProvider> configurationClosure): Register aMIOMappingsDirectoryProvideras a mappings source.addMappingsFile(Action<MIOMappingsFileProvider> configurationClosure): Register aMIOMappingsFileProvideras a mappings source.
Example task configuration:
task remapGalim(type: org.stianloader.sml6.tasks.RemapJarTask, dependsOn: stripGalim) {
inputJar = stripGalim.outputJar
libraryJars = stripGalim.strippingDependenciesFiles
archiveBaseName = "galimulator"
archiveClassifier = "remapped"
archiveVersion = deobfGalim.autodeobfVersion
destinationDirectory = layout.buildDirectory.dir("sml6/remapGalim")
addMappingsFile {
containerFormat = TAR_XZ
mappingFormat = ENIGMA
mappingSource = tarballXZ.archiveFile
}
}WARNING: This task is what one can describe as experimental. It doesn't seem to work well at this point and frankly more research is required.
The SLLJavaExecTask task extends JavaExec, inheriting all relevant properties and methods.
Additionally, it defines the following properties:
bootFiles:Property<FileCollection>, list of all boot URLs. This is used for SLL to correctly handle the transforming classloader. Computed as the union of thebootGameDependenciesandbootGameJarproperties. Do not change directly unless necessary.bootGameDependencies(mandatory):Property<FileCollection>, dependency artifacts ofbootGameJar. Tip: This can also be aConfiguration(which is aFileCollection).bootGameJar:RegularFileProperty, the game jar that is the main focus of SLL's transforming classloader.mods:ListProperty<FileCollection>, all the present mods. A singleFileCollectiondescribes the classpath of a single mod 'unit', including resources.
The simply the mod registration process, the SLLJavaExecTask provides the following methods:
void usingModSourceSet(Provider<AbstractCompile> classesOutput, Provider<SourceSet> resourceSet): Register a mod using the outputs of theAbstractCompiletask and the resources defined by the givenSourceSet.void usingModTasks(Provider<AbstractCompile> classesOutput, Provider<ProcessResources> resourcesDir): Register a mod using the outputs of theAbstractCompiletask for classes and the outputs of theProcessResourcestask for resources.
Example task configuration:
task runMods(type: org.stianloader.sml6.tasks.SLLJavaExecTask) {
classpath configurations['sllLauncher']
bootGameDependencies = stripGame.strippingDependencies
bootGameJar = genSources.lineRemappedOutputJar
usingModSourceSet(tasks.named('compileJava'), java.sourceSets.named('main'))
systemProperties.put("de.geolykt.starloader.launcher.CLILauncher.mainClass", "be.julien.particulitis.lwjgl3.Lwjgl3Launcher")
javaLauncher = javaToolchains.launcherFor {
languageVersion = JavaLanguageVersion.of(17)
}
}The DeobfuscateGameTask task defines following properties:
filteringEntryNames:ListProperty<String>, stores a list of entry names that are stripped from the output jar. Wildcards, regex, and similar are not supported. Intended to be used to remove singular resources you don't know the dependency of (or are otherwise undesireable).inputJar(mandatory):RegularFileProperty, the fat input jaroutputDirectory:DirectoryProperty, output files will be stored there by defaultoutputJar:RegularFileProperty, the stripped down jar will be stored therestrippingDependencies(mandatory):Property<FileCollection>, defines a list of jars whoose contents should be removed from the input jar. Calling any of thestripGalimulatorDefaults502methods will set this value.
This type provides following methods to more easily configure the task:
stripGalimulatorDefaults502(): Strip galimulator dependencies using the builtin dependency list for Galimulator 5.0.2stripGalimulatorDefaults502(Action<Configuration>): Same as above method, but the generated dependency configuration can be configured through a closure.stripGalimulatorDefaults502(String, Action<Configuration>): Same as above method, but use a custom name for the generated configuration.
Example configuration of this task:
task stripGalim(type: org.stianloader.sml6.tasks.StripDependenciesTask, dependsOn: deobfGalim) {
inputJar = deobfGalim.outputJar
stripGalimulatorDefaults502 {
configurations['compileOnlyApi'].extendsFrom(it)
}
}The dependency notation is the same as the notation you use within the gradle dependencies block.
The XZTarBallerTask class extends Tar.
The XZTarBallerTask task defines the following properties:
compressionLevel:Property<Integer>, the compression level to use for XZ. Maximum value is 9, however for small-ish files the default of 6 does the same thing.
All properties of Tar also apply, with the exception of compression, which is unused.
The archive's default destination directory is by default set to BasePluginExtension#getDistsDirectory. The default archive name is similarly derived. If the base plugin is absent, sane defaults will be used.
The XZTarBallerTask task is meant for shipping compressed mapping files. There is no real need for using this exact task, and other compression methods can be used. However, at the point of writing (2025-10-13), gslStarplane only supports .tar.xz and .xz compression. Though that may be subject to change in future versions of gslStarplane.
XZTarBallerTask is only meant to compress engima mapping directories. For other formats, use the XZCompressTask class instead.
Example task configuration:
task tarballXZ(type: org.stianloader.sml6.tasks.XZTarBallerTask) {
from "src/mappings"
group = "build"
archiveExtension = "enigma.tar.xz"
}
assemble.dependsOn(tarballXZ)The XZCompressTask class extends AbstractArtifactTask, and thus shares many
of the properties present in AbstractArchiveTask, namely all the archive
properties, as well as the destinationDirectory property.
The XZCompressTask task defines the following properties:
compressionLevel:Property<Integer>, the compression level to use for XZ. Maximum value is 9, however for small-ish files the default of 6 does the same thing.inputFile:RegularFileProperty, the input file to compress
To improve ease-of-use (or to just alleviate the pains of muscle-memory), the
XZCompressTask supports the from(Object) notation. However, keep in mind
that the method may only be called once. Further, XZCompressTask can only
compress a single file. To compress an entire directory or otherwise multiple
files at once, consider using XZTarBallerTask instead. The into(Object)
notation is not supported - not that it makes any sense in the first place.
The XZCompressTask task is meant for shipping compressed mapping files. There
is no real need for using this exact task, and other compression methods can be
used. However, at the point of writing (2025-Oct-13), gslStarplane only
supports .tar.xz and .xz compression. Though that may be subject to change in
future versions of gslStarplane.
The archive's default destination directory is set to the directory defined by BasePluginExtension#getDistsDirectory. The default archive name is similarly derived. If the base plugin is absent, sane defaults will be used.
To express the results of the XZCompressTask as a PublishArtifact,
use the asArtifact() method provided by AbstractArtifactTask.
You will need to mainly use this for maven publications.
Example task configuration:
task compressXZ(type: org.stianloader.sml6.tasks.XZCompressTask) {
from "tiny-file.tiny"
group = "build"
archiveExtension = "tiny.xz"
}
assemble.dependsOn(compressXZ)
publishing {
publications {
mavenJava(MavenPublication) {
groupId = project.group
artifactId = project.base.archivesName.get()
version = project.version
artifact compressXZ.asArtifact()
}
}
}Fully qualfiied name: org.stianloader.sml6.tasks.config.MIOMappingsProvider
The MIOMappingsProvider class defines following properties:
dstNamespaceId:Property<Integer>(optional, default: 0), the destination namespace id according to MIO. Should be equal to the namespace of the input jar.srcNamespaceId:Property<Integer>(optional, default: -1), the source namespace id according to MIO. Not used in the javadocs process, but is used in the remapping process.mappingFormat(mandatory):Property<net.fabricmc.mappingio.format.MappingFormat>, the used mapping format. Common values:ENIGMA_DIR,TINY_FILE, orTINY_2_FILE. Depends on the concrete input file though.
Instances of MIOMappingsProvider's subclasses need to be created through gradle's object factory (or just use helper methods).
That being said, attempting to instantiate instances of this classes' subclasses is not exactly recommended.
Creating instances of MIOMappingsProvider directly will fail, as for all intents and purposes it is an abstract class.
This class uses gradle's PropertyMixIn struct to make the MappingFormat and MappingContainer constants easily available as read-only constants.
These properties are case-insensitive. Further, following aliases are applied:
enigmaforENIGMA_DIRtinyforTINY_FILEtiny2forTINY_2_FILEtinyv2forTINY_2_FILEThese aliases are also case-insensitive. Also please note thatPropertyMixInhas little effects outside of closures, where you'd need to use the fully qualified path (or import statements but those are malpractice in stianloader buildscripts). Hence, one should prefer to configure things on demand using closures.
Fully qualified name: org.stianloader.sml6.tasks.config.MIOMappingsConfigurationProvider
This class extends MIOMappingsProvider, inheriting its properties.
The MIOMappingsFileProvider class defines following properties:
mappingSource(mandatory):Property<FileCollection>, the location of the mappings file(s) to use (each file will be treated as it's own unit and summed up).containerFormat(mandatory):Property<org.stianloader.sml6.starplane.remapping.MIOContainerFormat.MappingContainer>, the container format (eitherPLAIN,TAR_XZ, orXZ)
Keep in mind that MappingContainer constants are easily exposed through PropertyMixIn, see the documentation for MIOMappingsProvider.
Instances of this class need to be created through gradle's object factory, passing a Project instance as an argument.
This class also works for any other kind of FileCollection, though it is primarily intended to be used for
Configurations. Also: Configuration extends FileCollection, so you can just use it as-is.
For example, using a configuration for mappings in the RemapJarTask:
configurations {
mappings
}
task remapGalim(type: org.stianloader.sml6.tasks.RemapJarTask) {
inputJar = stripGalim.outputJar
libraryJars = stripGalim.strippingDependencies
archiveBaseName = "galimulator"
archiveClassifier = "remapped"
archiveVersion = deobfGalim.autodeobfVersion
destinationDirectory = layout.buildDirectory.dir("sml6/remapGalim")
addMappingsConfiguration {
containerFormat = XZ
mappingFormat = tinyV2
mappingSource = configurations['mappings']
}
}
dependencies {
mappings "de.geolykt:bstarmap:0.0.1-a20260327@tinyv2.xz"
}Fully qualified name: org.stianloader.sml6.tasks.config.MIOMappingsDirectoryProvider
This class extends MIOMappingsProvider, inheriting its properties.
The MIOMappingsDirectoryProvider class also defines following properties:
mappingSource(mandatory):DirectoryProperty(mandatory), the location of the mappings directory
Instances of this class need to be created through gradle's object factory.
Fully qualified name: org.stianloader.sml6.tasks.config.MIOMappingsFileProvider
This class extends MIOMappingsProvider, inheriting its properties.
The MIOMappingsFileProvider class defines following properties:
mappingSource(mandatory):RegularFileProperty, the location of the mappings file to usecontainerFormat(mandatory):Property<org.stianloader.sml6.starplane.remapping.MIOContainerFormat.MappingContainer>, the container format (eitherPLAIN,TAR_XZ, orXZ)
Keep in mind that MappingContainer constants are easily exposed through PropertyMixIn, see the documentation for MIOMappingsProvider.
Instances of this class need to be created through gradle's object factory.
Fully qualified name: org.stianloader.sml6.transforms.ApplyRASArtifactTransform
This TransformAction can be parametrized with the following properties:
fastTransform:Property<Boolean>, if enabled, skip theClassNodestage and write back the bytecode as-is when the class is believed to not be a target. Default value isfalse.inputFile(mandatory):RegularFileProperty, the location of your reversible access setter file that should be applied on the artifact set.namespace:Property<String>, the name of the ras location for debugging and error reporting purposes. The default value is derived from theinputFileproperty.outputArtifactType:Property<String>, the suffix that should be attached to the classifier if applicable. The default value of this property is derived fromscope.reversed:Property<Boolean>, whether to inverse/undo the RAS application. Default value isfalse.scope(mandatory):Property<de.geolykt.starloader.ras.ReversibleAccessSetterContext.RASTransformScope>, the scope of the artifact transformation. EitherBUILDTIMEorRUNTIME. Depending on the scope certain transformations will not be applied. See RAS's documentation for more information on this behaviour.
For convinience purposes, this transform's parameter class supplies the following constants to more easily configure the task:
BUILDTIME, ade.geolykt.starloader.ras.ReversibleAccessSetterContext.RASTransformScopeRUNTIME, ade.geolykt.starloader.ras.ReversibleAccessSetterContext.RASTransformScope
The ApplyRASArtifactTransform transformation applies a reversible-access-setter transformation on the configuration.
The reversible-access-setter (RAS) standard is stianloader's equivalent of AccessWideners or AccessTransformers. However, unlike those
two formats, RAS is, as it's name implies, reversible. This matters especially for hacks concerning removing ACC_ENUM from enum classes.
Those hacks work at compile-time but don't at runtime. However, your IDE will use compile-time classes to run the application with.
This leads towards potential classloading issues unless the classloader is properly vetted and there is proper interplay between IDE,
buildscript and classloading infrastructure.
RAS also has the advantage of being able to manipulate all kinds of flags that AT/AW can't or have difficult to modify. Yet, there are instances where you have to access a synthetic member, override an enum class, or do other things that might at first sound completely absurd. Yet, modding a video game at times require such brute methods to bend the ecosystem to your will.
Example transformation configuration (including registering the transform):
dependencies {
registerTransform(org.stianloader.sml6.transforms.ApplyRASArtifactTransform) {
from.attribute(ArtifactTypeDefinition.ARTIFACT_TYPE_ATTRIBUTE, "jar")
to.attribute(ArtifactTypeDefinition.ARTIFACT_TYPE_ATTRIBUTE, "ras-compile-jar")
parameters {
scope = BUILDTIME
inputFile = project.file("compile-hacks.ras")
}
}
}
configurations.testCompileClasspath.attributes {
attribute(ArtifactTypeDefinition.ARTIFACT_TYPE_ATTRIBUTE, "ras-compile-jar")
}
configurations.compileClasspath.attributes {
attribute(ArtifactTypeDefinition.ARTIFACT_TYPE_ATTRIBUTE, "ras-compile-jar")
}