Fix truncation of Baritone long settings

[mornhussakuyo-hub]

Type of change

• Bug fix
• New feature

Description

Baritone Long settings were wrapped in IntSetting, so opening the settings tab converted their values to 32-bit integers and wrote the truncated values back to Baritone.

This adds a LongSetting with a text-box editor and uses it for every Baritone Long value.

Related issues

Fixes #6219

How Has This Been Tested?

• Ran ./gradlew build.
• Checked that the reported value, 7540332306713543803, round-trips through LongSetting without truncation and that overflowing input is rejected.
• Checked the compiled Baritone adapter for LongSetting usage and the absence of Long.intValue() calls.
• Tested the packaged mod in Minecraft 26.2 with Baritone 26.2-SNAPSHOT. The reported value remained unchanged after opening the Baritone settings page and restarting the client.

Checklist:

• My code follows the style guidelines of this project.
• The change has no complex areas that need explanatory comments.
• I have tested the code in both development and production environments.

[mornhussakuyo-hub]

Hi! Just a friendly ping on this PR. 🙂

The CI is passing and the PR should be ready for review. When someone has time, I'd really appreciate a review.

Thanks!

[Wide-Cat]

Could you add max/min constraints to LongSetting, like the other numeric settings have. I would also like to hear your opinion on whether a slider should be added - it seems impractical for Long values but I could be convinced either way.

[mornhussakuyo-hub]

Could you add max/min constraints to LongSetting, like the other numeric settings have. I would also like to hear your opinion on whether a slider should be added - it seems impractical for Long values but I could be convinced either way.

I can add min/max support. But LongSetting seems to only be used for seeds at the moment, so does it really need a slider? We can add one later if needed.

[Big-Iron-Cheems]

Interesting work, I have one additional question:

• Should we extract the Long numeric editor into a dedicated WLongEdit, analogous to WIntEdit/WDoubleEdit, rather than putting numeric input filtering directly in DefaultSettingsWidgetFactory?

LongSetting currently uses a raw WTextBox with its own numeric character filter, whereas the other numeric settings use dedicated numeric widgets.
If the WTextBox approach is intentional because Long doesn't have slider support, that's reasonable; otherwise a WLongEdit would keep the numeric editing logic consistent.

One related detail: the filter uses Character.isDigit(c), while the resulting value is parsed with Long.parseLong().
It may be worth ensuring the accepted character set explicitly matches the syntax that Long.parseLong() accepts.

Unrelated sidenote: I just noticed that our other numeric type handlers do not use their defaultValue inisde load(CompoundTag tag), might look into that someday.

[mornhussakuyo-hub]

Interesting work, I have one additional question:

• Should we extract the Long numeric editor into a dedicated WLongEdit, analogous to WIntEdit/WDoubleEdit, rather than putting numeric input filtering directly in DefaultSettingsWidgetFactory?

LongSetting currently uses a raw WTextBox with its own numeric character filter, whereas the other numeric settings use dedicated numeric widgets. If the WTextBox approach is intentional because Long doesn't have slider support, that's reasonable; otherwise a WLongEdit would keep the numeric editing logic consistent.

One related detail: the filter uses Character.isDigit(c), while the resulting value is parsed with Long.parseLong(). It may be worth ensuring the accepted character set explicitly matches the syntax that Long.parseLong() accepts.

Unrelated sidenote: I just noticed that our other numeric type handlers do not use their defaultValue inisde load(CompoundTag tag), might look into that someday.

I used WTextBox to keep the changes as small as possible, but I’m happy to extract a WLongEdit if that would be more consistent with the existing numeric widgets.
Good catch on defaultValue too. I can update the other numeric types in a follow-up if needed.

[mornhussakuyo-hub]

I checked this against JDK 25: Character.isDigit(char) is consistent with the decimal digits accepted by Long.parseLong(), including non-ASCII digits.
Filtering out unsupported characters during paste is reasonable. The specific case worth revisiting is decimal input in integer editors: pasting 1.5 currently produces 15, whereas I would expect the fractional part to be truncated, producing 1.
This also affects the existing WIntEdit, so I think decimal-to-integer paste handling could be addressed in a separate PR.

[Frko5000]

All good imo

[Frko5000]

I checked this against JDK 25: Character.isDigit(char) is consistent with the decimal digits accepted by Long.parseLong(), including non-ASCII digits. Filtering out unsupported characters during paste is reasonable. The specific case worth revisiting is decimal input in integer editors: pasting 1.5 currently produces 15, whereas I would expect the fractional part to be truncated, producing 1. This also affects the existing WIntEdit, so I think decimal-to-integer paste handling could be addressed in a separate PR.

Ah yea

[mornhussakuyo-hub]

Could we merge this fix as-is to keep the PR focused? I’ll open a follow-up PR to extract a dedicated WLongEdit.

[Big-Iron-Cheems]

Sure, I'll merge this one for now to avoid scope creep.