stopgap fix for opus icons on newer MC #59

Closed
Merith-TK wants to merge 1 commits from Merith-TK/develop-1.8 into develop-1.8
Merith-TK commented 2022-07-04 09:11:02 -04:00 (Migrated from github.com)

Opus Utils.getVersion results in returning 1.1 rather than anything newer when on the 1.100.x CC versions (fabric and forge)

this is an stop gap fix, and yes, If I knew how I would tweak the matchers to make it work, but I dont so this will do, because whoever is on CC 1.1... needs to get off it,

Opus `Utils.getVersion` results in returning `1.1` rather than anything newer when on the 1.100.x CC versions (fabric and forge) this is an stop gap fix, and yes, If I knew how I would tweak the matchers to make it work, but I dont so this will do, because whoever is on CC 1.1... needs to get off it,
Kan18 commented 2022-07-04 09:44:13 -04:00 (Migrated from github.com)

I think this might break again when CC:T 1.110.0 is released, here are some other ideas I had:

I think this might break again when CC:T 1.110.0 is released, here are some other ideas I had: - Multiply the minor version by 10 if it is >= 100 (so for example, CC:T 1.100 would become 2.0, and 1.105 would become 2.05) - Just use the CC minor version (so, for example, CC:T 1.88 would become 88, and 1.105 would become 105) - The above but only if the CC minor version is above 85 or something (for example, CC:T 1.84 would still be 1.84, while 1.86 would be 86) Here are all the usages of Util.getVersion(): https://github.com/kepler155c/opus/search?q=getVersion https://github.com/kepler155c/opus-apps/search?q=getVersion
Merith-TK commented 2022-07-04 10:21:49 -04:00 (Migrated from github.com)

well, as the commit says, and the file comments I put in, this is an stopgap, not pretty, and definitely could use improvement, but it gets the job done without being too invasive on the code

well, as the commit says, and the file comments I put in, this is an stopgap, not pretty, and definitely could use improvement, but it gets the job done without being too invasive on the code
Merith-TK commented 2022-07-15 17:20:49 -04:00 (Migrated from github.com)

so... any ideas for an better implementation of an fix?

so... any ideas for an better implementation of an fix?
Kan18 commented 2022-12-27 12:58:32 -05:00 (Migrated from github.com)

I think Anavrins mentioned at one point that returning multiple values could be a good implementation. I can try working on that (this is somewhat urgent now, since SwitchCraft 2 is literally going away in 12 minutes, and the new version will be on SC3 so more people will run into this bug; if anybody who isn't currently online is seeing this comment right now, please join!)

I think Anavrins mentioned at one point that returning multiple values could be a good implementation. I can try working on that (this is somewhat urgent now, since SwitchCraft 2 is literally going away in 12 minutes, and the new version will be on SC3 so more people will run into this bug; if anybody who isn't currently online is seeing this comment right now, please join!)
Merith-TK commented 2023-01-01 12:47:51 -05:00 (Migrated from github.com)

With the release of SC3 this fix would be very much needed so icons can actually render

With the release of SC3 this fix would be very much needed so icons can actually render

Closing — superseded by #62

This issue was properly resolved by PR #62 (Kan18), which refactored Util.getVersion() to return a (major, minor) tuple using the pattern (%d+)%.(%d+). That correctly parses 1.100 as major=1, minor=100, and introduced Util.compareVersion() and Util.supportsExtChars() to replace all the fragile >= 1.76 float comparisons.

Thanks @Merith-TK for identifying the problem — the regex only matching two digits after the decimal was definitely the root cause. The proper fix is now merged on both develop-1.8 and main.

Closing — superseded by #62 This issue was properly resolved by PR #62 (Kan18), which refactored Util.getVersion() to return a (major, minor) tuple using the pattern (%d+)%.(%d+). That correctly parses 1.100 as major=1, minor=100, and introduced Util.compareVersion() and Util.supportsExtChars() to replace all the fragile >= 1.76 float comparisons. Thanks @Merith-TK for identifying the problem — the regex only matching two digits after the decimal was definitely the root cause. The proper fix is now merged on both develop-1.8 and main.
MayaTheShy closed this pull request 2026-03-22 15:21:49 -04:00

Pull request closed

Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MayaTheShy/Opus#59