To answer your question, I think most Mods are on hold until Forge Mixin gets updated.
Patience grasshopper.
Lou
FTFY I don't depend on Forge, I depend on a toolchain which includes (up until now) LaunchWrapper (a Mojang product written by cpw) and ForgeGradle (a modern build toolchain which was designed for Forge but is basically the contemporary MCP) and Mixin (LiteLoader's core which was extracted and improved to power Sponge and other mods).
LaunchWrapper has been supplanted by ModLauncher (a new project written by cpw to address the shortcomings of LaunchWrapper) and I am having to update Mixin to support it. I am also folding in some internal improvements to the structure of Mixin in the process, since the adoption of ModLauncher has necessitated some significant changes anyway.
All this is taking time, LL will come to 1.13.x but it's just taking time. We haven't had changes of this magnitude in recent years and this is taking considerable work to achieve.
For some reason there're no environmental variables for mouse scroll keys? I couldn't find them in the mod's variables and when i tried to use the name from the key binding screen it didn't work:
${if(MWHEELDOWN);log(test);endif}$
//Doesn't return anything
${log(%KEYNAME%)}$
//Returns "MWHEELDOWN", so technically the code above should have worked?
Could this be fixed please @Mumfrey
But if KEYNAME is MWHEELDOWN that means that the macro was triggered by the mouse wheel event, but because mouse wheel events are momentary it's thus very unlikely that the MWHEELDOWN will still be down when reaching that line in the macro.
Macros snapshots all keys pressed at the time the macro is triggered and these states can be accessed by prefixing the state variable with tilde:
IF(~MWHEELDOWN);LOG("Mouse wheel was down when macro was triggered");ENDIF
So maybe give that a try if you're trying to access the state of the key which triggered the macro. Accessing the state of the "key" may not work though, because the mouse wheel events are pulses and it may be difficult to observe the actual key down state within a macro.
1.13 for Forge, LiteLoader and Sponge is going to be a huge undertaking because in order to support Java 9 all of these projects are moving from LegacyLauncher to ModLauncher.
This is such a massive undertaking because I first have to update Mixin, which is going to be a first class citizen under the ModLauncher regime.
This is the biggest upheaval in the history of minecraft releases, and people who understand that statement in the context of some of the changes which have happened in the past will understand the true scope of these changes.
I would request patience. Please just report further requests for updates per the forum rules.
The server's being hammered by a DOS attack at the moment which is occasionally crashing the webserver. If the problems persist then I'll look at migrating the hosting to one of my other boxes.
I have identified and fixed the problem, it was caused by a fix I made which updated the scroll position when dragging a selection. Are there any other issues that people are aware of which I can roll into an update release?
I don't really know what you're asking, the FILTER directive already terminates the chatfilter macro so the behaviour you're describing is already the case.
(latest version has an issue with the text editor's slider, so I reverted)
What? this is the first I've heard of this. Please describe the issue you're having.
Sliders work similarly to labels in that you bind them to a shared variable, you can then simply access the shared variable in your scripts to get or set the value. Shared variables (unlike normal variables) are not attached to the macro trigger that owns the macro, they are shared amongst all scripts. To make a shared variable, prepend an at symbol "@" to the variable name. In order to avoid breaking other scripts with local variables, shared variables exist independently of local variables so for example @#foo is a shared counter variable and #foo is a local counter variable.
So to use the slider value, simply enter a shared variable name eg. @#myslider and you can then use this in your scripts.
GETPROPERTY and SETPROPERTY are mainly for runtime customisation of controls (eg. changing colours, labels, etc) and are not super efficient, this is why labels and sliders use the concept of binding to a variable since it's a much more efficient read/write operation and can support many scripts reading and writing the value at once with negligible overhead.
Looks like forge bumped the ASM version, I will need to bump ASM and make a new snapshot in order to be compatible. In the mean time extracting to mods folder should work as normal.
3
FTFY
I don't depend on Forge, I depend on a toolchain which includes (up until now) LaunchWrapper (a Mojang product written by cpw) and ForgeGradle (a modern build toolchain which was designed for Forge but is basically the contemporary MCP) and Mixin (LiteLoader's core which was extracted and improved to power Sponge and other mods).
LaunchWrapper has been supplanted by ModLauncher (a new project written by cpw to address the shortcomings of LaunchWrapper) and I am having to update Mixin to support it. I am also folding in some internal improvements to the structure of Mixin in the process, since the adoption of ModLauncher has necessitated some significant changes anyway.
All this is taking time, LL will come to 1.13.x but it's just taking time. We haven't had changes of this magnitude in recent years and this is taking considerable work to achieve.
0
But if KEYNAME is MWHEELDOWN that means that the macro was triggered by the mouse wheel event, but because mouse wheel events are momentary it's thus very unlikely that the MWHEELDOWN will still be down when reaching that line in the macro.
Macros snapshots all keys pressed at the time the macro is triggered and these states can be accessed by prefixing the state variable with tilde:
IF(~MWHEELDOWN);LOG("Mouse wheel was down when macro was triggered");ENDIFSo maybe give that a try if you're trying to access the state of the key which triggered the macro. Accessing the state of the "key" may not work though, because the mouse wheel events are pulses and it may be difficult to observe the actual key down state within a macro.
10
1.13 for Forge, LiteLoader and Sponge is going to be a huge undertaking because in order to support Java 9 all of these projects are moving from LegacyLauncher to ModLauncher.
This is such a massive undertaking because I first have to update Mixin, which is going to be a first class citizen under the ModLauncher regime.
This is the biggest upheaval in the history of minecraft releases, and people who understand that statement in the context of some of the changes which have happened in the past will understand the true scope of these changes.
I would request patience. Please just report further requests for updates per the forum rules.
5
I'm not dead, I just go through protracted periods of being insanely busy IRL which vary based on the events I'm working on.
0
The server went down to an attack, you can however access the downloads at CurseForge here in the mean time.
1
The server's being hammered by a DOS attack at the moment which is occasionally crashing the webserver. If the problems persist then I'll look at migrating the hosting to one of my other boxes.
0
There isn't currently an environment variable for that, what is the use-case for knowing the number of rendered entities?
0
I have identified and fixed the problem, it was caused by a fix I made which updated the scroll position when dragging a selection. Are there any other issues that people are aware of which I can roll into an update release?
0
I can only fix issues if I know about them, I will look into that.
1
I don't really know what you're asking, the FILTER directive already terminates the chatfilter macro so the behaviour you're describing is already the case.
What? this is the first I've heard of this. Please describe the issue you're having.
1
Sliders work similarly to labels in that you bind them to a shared variable, you can then simply access the shared variable in your scripts to get or set the value. Shared variables (unlike normal variables) are not attached to the macro trigger that owns the macro, they are shared amongst all scripts. To make a shared variable, prepend an at symbol "@" to the variable name. In order to avoid breaking other scripts with local variables, shared variables exist independently of local variables so for example @#foo is a shared counter variable and #foo is a local counter variable.
So to use the slider value, simply enter a shared variable name eg. @#myslider and you can then use this in your scripts.
GETPROPERTY and SETPROPERTY are mainly for runtime customisation of controls (eg. changing colours, labels, etc) and are not super efficient, this is why labels and sliders use the concept of binding to a variable since it's a much more efficient read/write operation and can support many scripts reading and writing the value at once with negligible overhead.
2
I've pushed a new snapshot, this should now be resolved.
0
Looks like forge bumped the ASM version, I will need to bump ASM and make a new snapshot in order to be compatible. In the mean time extracting to mods folder should work as normal.
1
Server has been successfully restored, if there are any issues accessing downloads please let me know.
1
The server hosting the downloads is temporarily down due to a DOS attack, I'm working on restoring it at the moment.