In a regular Java conditional, if you do something like this:

if (cheapCheck() && expensiveCheck())

expensiveCheck() will only run if cheapCheck() evaluates to true (and with || only if false).

However, with ModifyExpressionValue, as specified in the wiki, an injector like this turns into the following:

    @ModifyExpressionValue(method = "someMethod", at = @At(
            value = "INVOKE",
            target =  "LFoo;expensiveCheck(LParameters;)Z"
    ))
    private boolean cancelIfPossible(boolean original)
    {
        return cheapCheck() && original;
    }

if (cancelIfPossible(expensiveCheck()))

This forces expensiveCheck() to run every time, given it is passed as a parameter and therefore can't ever be skipped (unless it has no side effects or something, I'm not an expert on this).

Would it be possible for MixinExtras to inline those in order to allow such checks to be skipped? (note that I have no idea if this is actually possible or feasible, just asking) Or would it cause the same incompatibilities as Redirect?

An equivalent Redirect that would do the job would be something like this:

    @Redirect(method = "someMethod", at = @At(
            value = "INVOKE",
            target =  "LFoo;expensiveCheck(LParameters;)Z"
    ))
    private boolean cancelIfPossible(Foo object, Parameters params)
    {
        return cheapCheck() && object.expensiveCheck(params);
    }

Is it possible to make this compatible with java 8+

I currently cannot use this because I get the following error:

gamebuster@gamebuster-Ryzen9-3900X-RTX-3080:~/Desktop/Modding/WildermythGameProvider$ ./gradlew build --info
Initialized native services in: /home/gamebuster/.gradle/native
The client will now receive all logging from the daemon (pid: 1159260). The daemon log file: /home/gamebuster/.gradle/daemon/7.1.1/daemon-1159260.out.log
Starting 24th build in daemon [uptime: 57 mins 53.899 secs, performance: 99%, non-heap usage: 51% of 256 MiB]
Using 24 worker leases.
Now considering [/home/gamebuster/Desktop/Modding/WildermythGameProvider] as hierarchies to watch
Watching the file system is enabled if available
Starting Build
Settings evaluated using settings file '/home/gamebuster/Desktop/Modding/WildermythGameProvider/settings.gradle'.
Projects loaded. Root project using build file '/home/gamebuster/Desktop/Modding/WildermythGameProvider/build.gradle'.
Included projects: [root project 'WildermythGameProvider']

> Configure project :
Evaluating root project 'WildermythGameProvider' using build file '/home/gamebuster/Desktop/Modding/WildermythGameProvider/build.gradle'.
All projects evaluated.
Selected primary task 'build' from project :
Populating VCS workingDir MixinExtra_ekvol5eg59rv8qezjbdvgjak4/MixinExtras with ref 0.0.6: c948689427146f57d5bfb80eedc6efd62bdbcb7d
Now considering [/home/gamebuster/Desktop/Modding/WildermythGameProvider/.gradle/vcs-1/MixinExtra_ekvol5eg59rv8qezjbdvgjak4/MixinExtras, /home/gamebuster/Desktop/Modding/WildermythGameProvider] as hierarchies to watch

> Configure project :MixinExtras
Evaluating project ':MixinExtras' using build file '/home/gamebuster/Desktop/Modding/WildermythGameProvider/.gradle/vcs-1/MixinExtra_ekvol5eg59rv8qezjbdvgjak4/MixinExtras/build.gradle.kts'.
Caching disabled for Kotlin DSL accessors for project ':MixinExtras' because:
  Build cache is disabled
Skipping Kotlin DSL accessors for project ':MixinExtras' as it is up-to-date.
Registering project ':MixinExtras' in composite build. Will substitute for module 'com.llamalad7:MixinExtras'.

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':compileJava'.
> Could not resolve all task dependencies for configuration ':compileClasspath'.
   > Could not resolve com.llamalad7:MixinExtras:0.0.6.
     Required by:
         project :
      > No matching variant of project :MixinExtras was found. The consumer was configured to find an API of a library compatible with Java 9, preferably in the form of class files, preferably optimized for standard JVMs, and its dependencies declared externally but:
          - Variant 'apiElements' capability com.llamalad7:MixinExtras:0.0.6 declares an API of a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component compatible with Java 16 and the consumer needed a component compatible with Java 9
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
          - Variant 'runtimeElements' capability com.llamalad7:MixinExtras:0.0.6 declares a runtime of a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component compatible with Java 16 and the consumer needed a component compatible with Java 9
              - Other compatible attribute:
                  - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)

* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 775ms

I also tried altering the build script myself to make it compatible with java 8, but I don't really know Kotlin, and it didn't work.

Hi!

Amazing library first of all, looks really useful!

Do you think it'd be a good idea to have a JiJ-able fabric mod (maybe as a sub project/module so the main code doesn't depend on it) so if other mods can directly JiJ it, there's no need to load the same library multiple times in different locations (via shadow) and the initialization is also handled by it? That'd also make it more easily version-able and have a proper entry as a mod.

Just a suggestion that crossed my mind, what do you think?

If targeting a non static method call with ModifyExpressionValue, it would be great if it was possible to get a reference to the object the method being called belongs to, similar to Redirect. A reference to the method arguments would also be nice if that is possible.

Hi,

sometimes you just want to wrap the method without really worrying about any of the args, in which case just having the method parameters be Object... args, Operation<?> original could be useful. I know that this alone doesnt seem like a big benefit but it can allow for more compatibility between different mc versions (where you may want to wrap the same method but it has different args) by using different this + multiple @At's.

Similar would also be useful for @WrapWithCondition (although in that case just having no args would also do the job, especially if you want to wrap multiple @At's with the same condition.

This isn't something super necessary but could be neat for making mods that work for lots of different versions.

Hello, I am sure I am doing something dumb, but I am having trouble getting Mixinextras setup in forge gradle. Ive used normal implementation, implementation with fg.deobf, and shade extending implementation. Unfortunately with all of these, the jar files are missing at runtime, particularly the MixinExtrasBootstrap.init() during the mixinPlugin load, as well as mod constructor.

My branch for adding this project is here: https://github.com/baileyholl/Ars-Nouveau/pull/664/files Does anything look particularly out of place here?

Thank you!

currently I have found mixins really lack in 2 areas: you can't make a class extend another class, and you can't add new constructors to a class. would also be preferable if those features could also do something like interface injection does, though that part should maybe be in a different lib.

Can you include the built binaries in the github releases? I don't use Jitpack because of https://github.com/jitpack/jitpack.io/issues/3973.

I also need to download the dependencies at runtime, and I've set up a system for myself to do download artifacts from github releases.

This would wrap the entire left-hand or right-hand side of a comparison, which could be chained by multiple mixins.

Example:

@ModifyComparisonArg(
    method = "targetMethod", 
    comparison = "LESS_THAN_OR_EQUAL",
    argument = "SECOND" //or maybe side = "RIGHT_SIDE"?
)
private TargetType wrapExpression(TargetType expression){
    //TargetType is either int, long, float, double, boolean(?)
    return expression + 5;
}

Code diff:

- if(x * i <= foo.get() * 4){
+ if(x * i <= wrapExpression(foo.get() * 4)){
    // stuff
}

Note: in this example code diff, there is no way to add 5 to either side. If you used a @ModifyExpressionValue on foo.get(), then any value you add gets multiplied by 4 (which will not be the same result). And if you used a @ModifyConstant or @Redirect on the field access, then (in this example) any change you make will also get multiplied by the other values in the expression (again, not the same result), while also not being compatible with any other mixins using the same target.

It's kind of annoying to have to open up this github page whenever I want to check the syntax of one of your injectors. Copying the docs or at least the most important parts into javadocs would make usage a lot smoother.

• @WrapWithCondition is now able to wrap method exiting instructions, if they are safe to remove. Method exiting instructions are safe to remove, if they're always followed by another method exiting instruction and all variables, that are later used and not set, are initialized.
• Added the @InitVariable injector, which can set variables, but, unlike @ModifyVariable, it doesn't provide the previous value and only variables from the next frame instead of the current frame are available.
• Added the BeforeThrow (@At("MIXINEXTRAS:THROW")) injection point that targets ATHROW instructions and also can optionally accept an ordinal.
• Added @RedirectExit injector, which can replace ATHROW and return instructions.
• Changed @ModifyReturnValue to support replacement of the target instruction by checking the opcode of the original target instead of the current target
• Added @ModifyThrowValue to change Throwables about to be thrown.

Methods for the required bytecode validation are in InjectorUtils. My fork contains possible wiki entries representing the changes.

What it does Like a @ModifyArgs is for multiple @ModifyArgs, a @ModifyVariables should be for multiple @ModifyVariables. Quite simple (unless you need to do hacks with the LVT) and should probably be in mixin, but this is the next best thing.

Why it's a good idea You often need to modify parts of a vector of color that have been split up into multiple locals, and it's annoying to have to write three of them (even if they are similar).