VulkanMod

VulkanMod

357k Downloads

Breaks custom gamma and fullscreen

andreasdc opened this issue · 25 comments

commented

When I installed the newest update I had Minecraft in windowed mode and when I applied the changes my custom gamma (options.txt file) was resetted back to normal.

commented

Is it fixed?

commented

Did you change settings in game or did you edit options.txt?

commented

I edited options.txt

commented

bump

commented

I think after you change something in the vulkanmod's settings it will reset gamma to max value which is 1.0.

commented

Yes it must be closed. On this commit it works, on the newer with the options screen it doesn't work.

commented

I tried using a mod artefact via IntelliJ using the specific commit you mentioned b7e02ee, and found that to set the gamma: correctly in options.txt the game must be closed, as if its changed in text editor by hand when the client is running it will override/reset it.

I tried to set gamma:0.45 before launching the instance instead of after, and it seems to set the brightness correctly at 45 in game, so unless I'm mistaken it has to be changed only when the client is not running.

commented

I also just tried with the version of 0.1.8 from curseforge from both 1.18.2/1.19.2 as well as the latest commit 1b04d8d and modifying options.txt, specifically gamma again before launching the game seems to work fine and brightness was applied correctly for all three versions of the mod on my machine on Windows 10 (tried 0.15, 0.25 and 0.75).

I also can't seem to replicate or reproduce your issue, however I used a custom 3rd party launcher (Dev version of PolyMC) to do this so unless a specific launcher is interfering with this or your using a different platform e.g. PojavLauncher on Android, I'm not sure what is causing the changes in options.txt to not be applied properly as I can't seem to reproduce the bug at all. (Sorry for not being helpful)

commented

I just had a look at this a while earlier and can confirm that while the mod does read and apply the custom values correctly, upon closing the game the options file is reverted to the default values on every close which is different from/does not follow from vanilla which usually won't revert the values unless they are invalid (e.g. if Brightness.Gamma is set outside of 0-100).

This also only happens in a release environment (if the mod is used in a launcher) and not in a development environment (i.e. With IntelliJ/Netbeans/Eclipse e.g.) as in the latter the options file is not overwritten so it may be a weird edge case issue/ dumb vanilla oddity/weirdness and nothing to do with the mod directly. (e.g. where vanilla is overriding control from the mod code such as if it thinks the file is missing when it isn't)

commented

It looks like it might be a packaging issue as this problem occurs when using ./gradlew build to create the mod artifact from the 0.1.8 release here, however after testing it again (With MultiMC/PolyMC) with a mod artefact build with ./gradlew build with IntelliJ the issue disappears and does not overwrite the Options.txt file however it in exchange doesn't read and apply the settings properly (if set at 100 in game will always stay at that value and won't update it with what's set in options.txt)

The ./gradlew build version without IntelliJ also doesn't always apply the correct LWJGL version its supposed to (3.2.2 instead of 3.3.1) so it not just a Option.txt issue (Unless I built the mod Wrong)

commented

I also noticed that the runDirectory variable used to load the options.txt file in MinecraftClient class points to the correct instance directory if run as a separate .jar mod or in a Dev Environment so that likely isn't the issue.

What might work is using an easy mixin fix where the variable could be overridden manually with System.getProperty(user.dir) however I'm not sure why this only happens in a user/launcher environment and not in a dev environment. (Unless its a launcher specific edge case issue preventing the file from being accessed for some reason)

(I might consider thinking about setting up a small PR if the hypothetical fix for this is very easy to implement.)

commented

After testing this for a while I found that is is not a bug with vanilla/the Mod, it seems to be issue where the value must be formatted correctly to be read by the game, for gamma in options.txt 1-100 is in floating point format (0.0-1.0) so for value 45 it would be written as 0.45 and not 45 (in options.txt). So it looks like Vanilla can't sufficiently error correct for typos so falls back to the default/last saved value.

After doing that it seems to reflect the manually added value in the options menu and in game so it looks like when adding manual values to make sure that they are written correctly in the float format and not the int format.

commented

Are manually added values to options.txt udpated and used properly in game or are they still being reset? (sorry if misunderstanding)

commented

I have gamma:100.0 in the options.txt and it works normally

commented

They are being resetted because VulkanMod sets it to max value of 1.0 if i'm not wrong.

commented
  1. I have gamma:100.0 in options.txt and latest VukanMod from actions 1b04d8d
  2. I open VulkanMod's video settings.
  3. I click apply.
  4. Brightness is now changed to 1.0.
commented

Tried the following: (With the 0.1.8 1.18.2 version from curseforge with a developer version of PolyMC 5.0)

  • let then client generate default options.txt, (e.g. deleting it or with fresh instance)
  • changed gamma:1.0 to 0.125, (which rounds to 12)
  • launch the client,
  • change almost all settings, (without touching the brightness slider in game),
  • close the client,
  • change a random option in options.txt ( e.g. fov:0.1 in options.txt to 0.200, )
  • relaunch the client
  • change random setting in game again

And gamma is still set to 0.125 instead of defaulting to 1.0 and brightness is set to 12 correctly and is not reset to 100/1.0 at any point, I did not touch the brightness slider at any point so unless I'm missing a s key step that triggers the bug to occur, I still can't seem to reproduce it at all.

There likely is an actual issue/bug here that is happening, but I can't seem to create the right conditions to trigger it. (again apologies for being unhelpful)

commented

I think I might understand the issue now, when set to 100.0 with the current blob 1b04d8d the mod treats this as the equivalent of setting brightness level 10000, normally in vanilla I believe this is not clamped back to the default max of 1.0 (Brightness 100), however when the new options menu was added to this mod in options.java, if I'm not mistaken, default ranges are now enforced when they weren't before, so when it sees that gamma is above 1.0, it resets its back to the default range deliberately, so technically it is not a bug from a default settings perspective (and is arguably fixing a vanilla bug)

I tried removing the 100 limit on the 3rd parameter here to Integer.MAX_VALUE:

new RangeOption("Brightness", 0, 100, 1,
and the gamma value at 100.0 was no longer reset back to 1.0 after changing and applying other settings and exiting and relaunching the game.

To allow the option.txt ranges you want to use, if i'm not wrong, the max limits need to be removed so it doesn't clamp the values back to the vanilla limits.

commented

It looks like this when set in game if this is the correct behaviour

I can try looking into setting up a PR for this, but I'm not sure if the repo owner wants to merge something like that as the options ranges are explicitly added so they may have wanted to keep the options within those clamped ranges(which makes sense to stop potential dumb crashes and bugs from happening), also something like that could also be faked/replicated with a custom shader as well in theory.

2022-10-19_21 50 35

commented

if (gamma > normalMax) {
dontsave
}
else {
save
}

commented

I'm assuming you might have potentially also meant trying to setup effects like this AntVenom Video, (brightness/Gamma is also covered) in that case I will definitely think about looking into it as changing some of these parameters (e.g Fog Position, Entity Cull Distance) in game might be useful for some people. (as I was thinking of submitting a PR a bit similar to this anyway)

commented

Still breaks gamma :/

commented

I just retested it and it seems to be working properly. Gamma value ranges from 0.00 to 1.00 and it's correctly saved.
Are you applying changes before exiting menu? Can you test it on another launcher?

commented

I changed in options file, like I described here:

  1. I have gamma:100.0 in options.txt and latest VukanMod from actions 1b04d8d
  2. I open VulkanMod's video settings.
  3. I click apply.
  4. Brightness is now changed to 1.0.

I guess it's not fixed yet and I can't use video settings in the game.

commented

I guess it's not fixed yet

This is a 1.19+ feature, Minecraft resets invalid values in options.txt, isn't it?