The only part of that mod that's shader related is the blur filter, but even that needs to be used in combination with an actual mod changing the camera perspectives. Unless your goal is to make it so that it feels like your Minecraft character needs glasses, you'd need a full revive of the mod too.
Sorry about that, it seems I missed changing the default version from Curse that the widget uses when I updated the mod, but I've gone ahead and fixed that.
Going through and updating mods that I decided to convert to your new LiteMDK structure, I noticed there's not much support for specifying revisions like 1.10.r2 or 1.12.r2. Changing the version in project.gradle to equal a new entry in gradle.properties like mcpVersion and changing mcVersion to be the revision seems like a good way to have all the settings you need located in gradle.properties. In cases where the revision only spans a single version, you can either specify mcVersion to equal mcpVersion or the actual version, though the first would be a good default case.
GRADLE.PROPERTIES SNIPPET:
mcpVersion=1.12.2
mcVersion=mcpVersion
OR
mcpVersion=1.12.2
mcVersion=1.12.r2
PROJECT.GRADLE SNIPPET:
version=project.mcpVersion
Just a thought, though important for the rare cases of inter-version compatibility.
EDIT: Goofed up the first post, didn't actually change the mcVersion in the litemod file the way I originally posted.
SECOND EDIT: Seems this still isn't having the desired effect, so I'm gonna see if you can come up with a better way to do this, but it *is* something that I feel should be taken into consideration.
THIRD EDIT: This actually will work provided you add
mcversion=project.mcVersion
to the litemod.json block in build.gradle, though there may still be a better way
an alternative to the extend from forge option is to click "extract" in the liteloader installer and place the new file in your mods folder, which forge will load as any other mod.
I've been stuck on 1.12 for several of my mods lately, simply because I have no internet set up in my new apartment. I really am trying to get this issue resolved so I can continue updating my mods though.
Would you prefer it moved to a side of the screen or removed completely? Either way, once I have a good internet connection again, I'll look into releasing a new version with that feature.
Where are you when you try this? In my experience, it'll only be the most extreme areas that the max is really useful, and I know a few versions ago they seem to have changed something that makes the transition to full bright more abrupt. There's really not much I can do on my end :/
I could've sworn I released a 1.12.1 update for this, but I'll go back and check in a moment. Nothing's changed, so it would just be a recompile of the same code unless I was in the middle of optimizing something
I'm guessing by "toggling your brightness settings," you mean that you have the normal brightness slider set to one thing, and pressing "G" makes it normal light level?
That alone is nothing more than toggling the mod on and off -- the real purpose of the mod is when you use the arrow keys to adjust the brightness far beyond the built in vanilla limits of brightness. For a demonstration, press "G," hold the right arrow for a bit, then venture into an unlit cave. You could also sit in your lit house and press the left arrow for a bit to make it a little spookier.
So here's a quick play by play of my attempts to fix this mod:
It broke (obviously)
I try to use Mixins to change one part to fix it
That fails
I try to use Mixin to fix another part that would make fixing the first part I tried irrelevant
That fails
In the process of trying to fix it the second time, I changed something and hadn't deleted it after the failed attempt
Killjoy reminds me of a feature in LiteLoader that had in fact been what I used in the mod until it broke
The code that I forgot to delete suddenly makes that original functionality in LiteLoader work properly for what I want again
One one hand, this whole process has taken an obscene number of months to run its course.
On the other hand, I've managed to find a fix that will let me get this mod up and running again in a matter of days, and should make breaking like this a lot less likely in the future.
We'd need to see the whole class, because without even looking at the render code, I can't tell if it's a problem where "ingame" is never set to true when that's running or if it's something else entirely. You're also putting your render code straight in your LiteModBase class, and while I'm not 100% certain on this, I feel it's better practice to put all of your render code in its own class and call it from there. In my mods, I generally have the Renderer class instantiated, and call renderer.render() in onTick() which you'd have to implement Tickable to use.
Again, I'm not necessarily the expert on this, but the renderers in my mods work well enough, and you can use the code for those on github as further examples.
0
It is currently not available for 1.8
0
The only part of that mod that's shader related is the blur filter, but even that needs to be used in combination with an actual mod changing the camera perspectives. Unless your goal is to make it so that it feels like your Minecraft character needs glasses, you'd need a full revive of the mod too.
0
Sorry about that, it seems I missed changing the default version from Curse that the widget uses when I updated the mod, but I've gone ahead and fixed that.
2
Don't install liteloader on top of the forge profile -- click extract in the installer and place the file in your mods folder
1
Going through and updating mods that I decided to convert to your new LiteMDK structure, I noticed there's not much support for specifying revisions like 1.10.r2 or 1.12.r2. Changing the version in project.gradle to equal a new entry in gradle.properties like mcpVersion and changing mcVersion to be the revision seems like a good way to have all the settings you need located in gradle.properties. In cases where the revision only spans a single version, you can either specify mcVersion to equal mcpVersion or the actual version, though the first would be a good default case.
Just a thought, though important for the rare cases of inter-version compatibility.
EDIT: Goofed up the first post, didn't actually change the mcVersion in the litemod file the way I originally posted.
SECOND EDIT:
Seems this still isn't having the desired effect, so I'm gonna see if you can come up with a better way to do this, but it *is* something that I feel should be taken into consideration.THIRD EDIT: This actually will work provided you add
to the litemod.json block in build.gradle, though there may still be a better way
0
WinRar is free -- it's a free trial that even when it runs out, it lets you continue to use it.
0
an alternative to the extend from forge option is to click "extract" in the liteloader installer and place the new file in your mods folder, which forge will load as any other mod.
0
I've been stuck on 1.12 for several of my mods lately, simply because I have no internet set up in my new apartment. I really am trying to get this issue resolved so I can continue updating my mods though.
1
I'll try to look into this, however I'm without internet in my apartment and am currently relying on (very limited) mobile data
0
Would you prefer it moved to a side of the screen or removed completely? Either way, once I have a good internet connection again, I'll look into releasing a new version with that feature.
0
Where are you when you try this? In my experience, it'll only be the most extreme areas that the max is really useful, and I know a few versions ago they seem to have changed something that makes the transition to full bright more abrupt. There's really not much I can do on my end :/
0
I could've sworn I released a 1.12.1 update for this, but I'll go back and check in a moment. Nothing's changed, so it would just be a recompile of the same code unless I was in the middle of optimizing something
1
I'm guessing by "toggling your brightness settings," you mean that you have the normal brightness slider set to one thing, and pressing "G" makes it normal light level?
That alone is nothing more than toggling the mod on and off -- the real purpose of the mod is when you use the arrow keys to adjust the brightness far beyond the built in vanilla limits of brightness. For a demonstration, press "G," hold the right arrow for a bit, then venture into an unlit cave. You could also sit in your lit house and press the left arrow for a bit to make it a little spookier.
2
So here's a quick play by play of my attempts to fix this mod:
One one hand, this whole process has taken an obscene number of months to run its course.
On the other hand, I've managed to find a fix that will let me get this mod up and running again in a matter of days, and should make breaking like this a lot less likely in the future.
1
We'd need to see the whole class, because without even looking at the render code, I can't tell if it's a problem where "ingame" is never set to true when that's running or if it's something else entirely. You're also putting your render code straight in your LiteModBase class, and while I'm not 100% certain on this, I feel it's better practice to put all of your render code in its own class and call it from there. In my mods, I generally have the Renderer class instantiated, and call renderer.render() in onTick() which you'd have to implement Tickable to use.
Again, I'm not necessarily the expert on this, but the renderers in my mods work well enough, and you can use the code for those on github as further examples.