blcm / openblcmm Goto Github PK

It'd be nice if say and exec were handled "properly," in that they could be toggled on+off like all the usual set commands. Relatedly, it'd be nice to have the same support for extra commands added via Command Extensions, though that might be better off as a separate issue entirely, since that would also require support for the user/mod being able to define what new commands have been defined.

System Info
Operating System:
Windows 10

Describe the bug
Opening large statements in mod files takes 17+ seconds while the app fully freezes.

To Reproduce
As an example trying to open GD_Iris_GameStages.Balance.Iris_P2_GameBalance in the
NVHM/TVHM Area Scaling v1.2 by 55tumbl Mod.

It'd probably be nice if OE's datapack had actual refs support it it (like the BL3+WL refs DBs that I provide off apocalyptech.com). It'd be easy enough to do from a technical perspective. My main concern would be making sure that the database doesn't grow too much in size. I expect it'd probably be fine, though -- the BL3 refs database is about 85MB; I wouldn't expect a BL2 refs DB to exceed that by too much.

(The BL3 refs DB does omit some connections since its generation method doesn't know about numerical suffixes, though, so judging the actual relative size of the datasets is a bit tough.)

As a mod author, I would like to know what objects are loaded at all times.
For this, a list of packages/levels in each object's dump could be useful. Obviously, this would need a few blacklisted objects, e.g., SkillsDefinition, Meshes, Materials... that are only part of a character package.

Another nice addition would be to allow filtering for certain packages in the search.
For example: inclass:SkillDefinition package:Sanctuary_P
This would search for only SkillDefinitions that are loaded in Sanctuary. Similar, this could be expanded to allow for a list of packages or even for All which would need to internally match all level packages to work correctly.

Right now hotfixes have a "name" field which folks can use for extra hotfix labelling. At the moment this gets shoved into the hotfix key names directly, which can lead to some real weird-looking keys. We probably shouldn't do that.

Relatedly, that "name" field is kind of ridiculous anyway -- we've got in-mod comments already, why not use those? Anyway, they are in pretty wide use, so I guess we'll keep 'em around, but nobody's constructed hotfixes manually for ages, so I don't see that having them in the names is actually useful anymore. So my impulse at the moment is to keep the Name field as-is and just don't use it for hotfix keys.

There's a few places in the code where we call Desktop.browse() to open a URL. There are some circumstances where that call will fail, though, due to Java not knowing how to launch a browser on the currently-active desktop.

We could fall back to some custom behavior when that happens, such as checking for xdg-open on the current path and attempting an open that way, but that doesn't really seem worth it -- Java's probably already doing as much of that as is feasible.

Instead, let's have the error dialog include a textbox which contains the URL, for easy selection/viewing, and also have that dialog copy the URL into the user's clipboard automatically. That way the URL's at least readily available for manual browsing.

At the moment, each use of that browse() function is handled separately, but we'd probably want to wrap all this up in a function under Utilities or the like, and use that instead. Be sure to pass in the parent JComponent so that we can set the modality properly when it's raised.

Not sure if this one's worth the effort, but it'd be nice to expand our game detection to be able to detect all installed instances of the game, regardless of store (or, at least, both Steam + EGS, if the user happens to have both). And then we'd be able to provide better button shortcuts in file dialogs, etc, in case folks want to manage a patch file on multiple installs. I'd also want the ability to actually save custom install locations, in the event that the autodetection doesn't work.

But basically just supporting an arbitrary number of installs per game, and Doing The Right Thing in situations where it'd be helpful.

This is obviously a little less important now that PythonSDK is the preferred method of mod installation, but pointing the user to the correct Binaries dir would be helpful regardless.

command general syntax is set object property value
holding control or shift while searching will search the entire command, would be nice to be able to search for either in the object or in the value rather than the whole command, with options to set the behaviour.
as an example setup
ctrl: search object
shift: search value
ctrl shift: search whole command

My understanding is that ant is a somewhat deprecated system, or at least not really recommended by the wider Java community. Maven seems to be the way to go? Maven would also allow us to specify third-party libraries a little more sensibly, and avoid having the third-party libraries stored right in our git repo. It'd also be nice to be able to build+run from commandline a bit more easily, though technically I think I could fire off ant builds from the CLI already...

From the support server

i.e. here

Deleting the new folder fixed it

Back in the days of hotfixes being constructed by hand, "naming" hotfixes in the hotfix keys was a very useful method of both doing hotfix merging, and verifying the results of those merges. As FilterTool and later BLCMM was developed, that naming functionality got brought along, but its usefulness is, IMO, extremely dubious at the moment.

The functionality isn't even exposed to anyone on a new BLCMM install for some time now, and OpenBLCMM doesn't import the preference which enables their use. So it's effectively dead already. What I'd like to do here is just completely remove it from the mod format as well (and purge any remaining code which handles it).

That'll be for Sometime In The Future, though, and might not be worth the effort. I suspect there's gonna be a ton of people who never move from BLCMM -> OpenBLCMM, and at least for the time being I'd like to make sure that OpenBLCMM-exported files are 100% compatible with BLCMM. That said, enhancements like #9 may end up causing some incompatibility anyway, so if we do end up bumping the BLCM file version number for something like that, it might be worth knocking this off the list, too.

With multiple lines selected, Ctrl-E can be used to edit them all at once. Double-clicking won't work, though, because the first click gets rid of the multi-select and just selects the one you're double-clicking on. Not sure if there's a feasible way to change that behavior, but could look into it, at least.

It might be nice to have a fulltext search index, so that ad-hoc searching could be much faster. The most obvious tool to start with, IMO, is Apache Lucene: https://lucene.apache.org/

My main concern would be database size. We've already got an uncompressed DB that's 600+MB for BL2, and I can't imagine that a good fulltext index wouldn't balloon that up even further. Also, searching the whole dataset isn't that bad anyway, so possibly not worth it.

Still, something to look into.

OpenBLCMM supports Java as far back as 8, still, but newer Java versions have various deprecation warnings which are popping up. Rather than wait until code starts actually breaking, I'll be doing some refactoring to get rid of the deprecation warnings for v1.4.0. (If possible, anyway -- if we run into something which is difficult or impossible to deal with while retaining Java 8 compatibility, we may have to rethink Java 8 support.)

The current ones fall into a couple of categories:

• URI(String) constructor
• InputEvent.getModifiers()
• InputEvent.CTRL_MASK
• ToolKit.getMenuShortcutKeyMask()
• JTextComponent.modelToView(int) and JTextComponent.viewToModel(Point)
• Runtime.exec(String)

For at least some people, actions like closing an edit window can leave focus in a weird state where the main window isn't active, even though it's brought to the front. Users may need to click on some other window and then back to OpenBLCMM to re-activate.

Operating System:
Windows 11

OpenBLCMM Version: 1.3.3
Java Version: 17.0.6
Java VM: Substrate VM GraalVM 22.3.1 Java 17 CE
Memory Used: 130.3 MB
Memory Max: 13.5 GB
BL2 Data: Loaded, v2023.04.20.01
TPS Data: Loaded, v2023.04.21.01
AODK Data: Not loaded: No jarfiles found for AODK

Describe the bug
Crash upon changing OE Data settings while OE is mid-search.

To Reproduce
Change OE Data settings while OE is searching

Additional context
log-2023-08-11-085722.log

double clicking on WeaponBalanceDefinition'GD_Weap_SMG.A_Weapons.SMG_Bandit_2_Uncommon' only selects WeaponBalanceDefinition'GD_Weap_SMG.A_Weapons.SMG_Bandit
double clicking on WeaponPartListCollectionDefinition'GD_Weap_SMG.A_Weapons.SMG_Bandit:PartList' only selects WeaponPartListCollectionDefinition'GD_Weap_SMG.A_Weapons.SMG_Bandit
would be nice to have it fixed so it would select the whole thing

It might be nice to decouple OE from OpenBLCMM entirely (while still preserving the ability for the two to talk to each other, at least well enough to open object links from OpenBLCMM).

Some challenges (okay, one challenge) from the top of my head:

• Both OpenBLCMM and OE need datalib access. Right now they both share the same DataManager objects between them (though with a separate DataManagerManager so they can be pointing at different games). Since our SQLite database has to be extracted for use, it wouldn't be ideal if it had to be extracted in two locations. Also I wouldn't want to have to deal with race conditions if both OpenBLCMM and OE ended up wanting to extract it at the same time.

Maybe they'd technically share a runtime just like the currently do, but just have a separate arg that can be supplied, to launch OE instead of MainGUI? We'd probably need a button somewhere in OE to launch the main app, too...

These two consecutive hotfixes, in TPS, should really trigger an overwrite warning, whereas they currently don't:

set foo bar +(baz)
set foo bar (frotz)

The main issue is that the overwrite checker basically completely discards the TPS array-add syntax, since ordinarily that's completely nondestructive. But discarding it entirely means that it can't pick up on cases like the above.

Note that if this does ever get fixed, the unit tests should probably be exapanded a bit -- for instance, if the set foo bar (frotz) above isn't a hotfix, there wouldn't be any overwrite. We do have a unit test already for this case, which is at the moment expected to fail because of this bug.

Realistically, I kind of doubt this'll ever get fixed, since that syntax is hardly used, and I don't particularly feel like digging through the overwrite code sufficiently to implement a change like this. But, I suppose we'll see.

This issue was originally put in here about comments, but that was mostly just filtered through a misunderstanding of an issue that was mentioned in passing. The actual issue I'd meant to tackle with this is more demonstrated by this kind of thing:

pyb def abc():
pyb   unrealsdk.Log("test")
pyb abc()
pyb -x

The inner whitespace there is what's getting stripped out, which is causing problems for that kind of Python stuff. So, let's address that.

Running a large getall, particularly when there are a lot of object links to format in the results window, can sort of hang the GUI for awhile while it works, unlike the fultext/refs search. When rewriting the Data Library I'd tried briefly to try and at least get the mouse icon to go into a "spinner" state so there's some visual feedback that something's happening, but it didn't work great, and if anything the user experience was worse.

I think the main issue is that getall probably isn't happening inside a SwingWorker like the more involved checks are, so the solution is probably to just rewrite that to use the same sort of framework as fulltext/refs.

There may be some other query types which could benefit from the same thing -- getall is just the one that I'd noticed while writing it.

You can copy and paste folders, commands and comments around inside a single blcmm instance, would be nice to be able to do it cross instances as well

Being able to use a set command in conjunction of a Behavior_ConsoleCommands/Behavior_ClientConsoleCommand without having to open the BLCM file raw and manually edit it would be very appreciated.

There's various dialogs which don't close when the user hits the OS "window close" button -- have to use the Java-provided "OK" button or the like. Specifically:

• Changelog
• Uninstall
• Settings
• INI Tweaks
• Legacy Hex Edits
• What Are Profiles?
• Confirm action without save dialog
• Probably others

The dialogs were honestly probably created like that more-or-less by default. We often want the result of one of the given buttons passed back. But there's mostly no good reason not to figure out having a default action fire when the dialog is told to close, instead of just denying the request. The behavior should probably ideally be:

1. If the dialog has a "Cancel" button, send "Cancel" back
2. If the dialog just has a single button which is "OK", send OK back
3. In the absence of OK or Cancel, continue to deny the window-close request.

In terms of our newish AdHocDialog class, we've got four ButtonSets:

• YES_NO - No default, continue to deny the request
• YES_NO_CANCEL - Default is Cancel
• OK - Default is OK
• OK_CANCEL - Default is Cancel

Currently, a double-click on an object name will open in the current OE tab (or a new one if OE isn't currently open), and a ctrl-double-click will open in a new OE tab.

It'd be nice to have user preferences to configure this behavior. ie: single/double/triple click, and also choosing modifiers, for both current-tab and new-tab variants. There should probably be an option to disable object linking altogether, if folks don't want to have it.

Just what it says on the tin -- when scaling font sizes there's some stuff which doesn't scale up/down appropriately. Namely:

• Checkboxes
• Tree Icons (expand/collapse, lock, comment, folder open/close), exec, say
• Dialog Icons: warning/error/info/question
• Red question-mark icons
• Game Icons in file-dialog shortcuts (also the "stock" home/up/new-folder/etc icons)

This would affect radio buttons too, if we used any.

For checkboxes, we'd have to implement our own Checkbox-rendering function, which might not be a huge deal, but I don't really feel up to it at the moment. For the other icons, theoretically that shouldn't be too big of a deal, though we'd need to get some larger source versions for some of those.

Anyway, not gonna work on this in the forseeable future, but wanted to get it in here. This is related to #28, which I'm hoping to close out pretty soon now.

For mods with MUT options, if you import a new version of the mod, it might be nice if OpenBLCMM would attempt to make the same MUT selections that you already have in the patch file, rather than defaulting to what's in the mod-to-be-imported.

Probably what makes the most sense here would be a "strict" name check -- it would only do this if the in-mod paths match exactly with the new paths.

A lot of steam deck users are having trouble because java does not come preinstalled, and the deck has a mostly read only filesystem by default making it hard to install it. A native executable, similarly to the windows one, would help alleviate this.

OpenBLCMM Version: 1.3.3
Java Version: 20.0.1
Java VM: OpenJDK 64-Bit Server VM 20.0.1+9
Memory Used: 77.1 MB
Memory Max: 2.1 GB
BL2 Data: Loaded, v2023.04.03.01
TPS Data: Loaded, v2023.04.03.01
AODK Data: Not loaded: No jarfiles found for AODK

Bl2 INI files are not being detected on linux despite the fact that TPS INI files are being detected, both are installed in the same way on the same drive, specifically having the windows versions of the games installed.
Possibly allow for manually specifying INI file location in case of failure to detect?

Right now, BLCMM disallows switching theme when OE or edit dialogs are open. If you try it, you can get a variety of Exceptions depending on what you do next. For instance, mousing over the OE tabs will generate an exception out of JTabbedPane:

java.lang.NullPointerException: Cannot invoke "javax.swing.JTabbedPane.getLayout()" because "this.tabPane" is null
	at java.desktop/javax.swing.plaf.basic.BasicTabbedPaneUI.scrollableTabLayoutEnabled(BasicTabbedPaneUI.java:332)
	at java.desktop/javax.swing.plaf.basic.BasicTabbedPaneUI.tabForCoordinate(BasicTabbedPaneUI.java:1740)
	at java.desktop/javax.swing.plaf.basic.BasicTabbedPaneUI.setRolloverTab(BasicTabbedPaneUI.java:682)
	at java.desktop/javax.swing.plaf.basic.BasicTabbedPaneUI$Handler.mouseEntered(BasicTabbedPaneUI.java:4122)
	at java.desktop/javax.swing.plaf.synth.SynthTabbedPaneUI$1.mouseEntered(SynthTabbedPaneUI.java:301)
	at blcmm.gui.components.VariableTabsTabbedPane$MouseListenerWrapper.mouseEntered(VariableTabsTabbedPane.java:285)

Or clicking on the main text area of OE or an edit dialog, you'd end up with this exception in JTextComponent:

2023-08-04 13:59:08 blcmm.Startup$MyExceptionHandler.logError(Startup.java:405) -> class java.lang.NullPointerException: Cannot invoke "javax.swing.text.JTextComponent.putClientProperty(Object, Object)" because "comp" is null
    java.desktop/sun.swing.SwingUtilities2.getAdjustedClickCount(SwingUtilities2.java:1973)
    java.desktop/javax.swing.text.DefaultCaret.mousePressed(DefaultCaret.java:542)
    blcmm.gui.text.HighlightedTextArea$4.mousePressed(HighlightedTextArea.java:470)

I've tried poking at it a bit, thinking maybe there were some calls to JComponent.updateUI() which needed to be made, or something, but in the end I wasn't able to find much and it seemed like a lot of voodoo to me. So, whatever, I'm leaving it for now. Would be nice to figure out someday, though!

Pls thx

When using hotfix syntax and trying to save a command as a regular command you get this warning about it being wrong, maybe add a option in this dialog to automatically make it into a hotfix as just an any level hotfix since that is the default for them, I just forget to check the hotfix checkbox a lot so would be a nice shortcut to be able to click a button to automatically make it so

Basically as the title says, 99% of the time I want the arrays to be collapsed and then auto formatted.
Since collapse arrays is a toggle, maybe the option could be to set its starting state when making a new tab.
For maybe add a button next to it to toggle "automatic auto formatting" so that it formats objects on displaying them.

Right now, user prefs are stored in a general.options file which sort-of resembles a CSV but isn't really. It'd probably be nice to convert that over to a more sensible format. https://github.com/FasterXML/jackson might be a good library to use for that purpose.

I'd kind of prefer if OpenBLCMM didn't know anything about the INI edits, etc, and I'd honestly prefer the hexedits be Somewhere Else as well. There isn't currently an opensource app for either, though, apart from OpenBLCMM, and I'm not eager to start maintaining a separate app myself, though. Having a FOSS version of Hex Multitool would be real nice, though, and bringing the INI Tweaks over there would make sense as well.

Such an app would be the more natural home for an enhancement like #10, too, though probably OpenBLCMM would still benefit from #10 just so it can provide links to Binaries dirs...

So, I'd like to refactor some stuff so that users can have multiple windows open, of both the MainGUI itself (so users can have more than one patchfile open at once), and for OE (most likely for when folks want to look at different games' data at once, though could be used for the same game as well). This also folds in my desire to be able to launch just OE.

It's a pretty tall order at the moment, so I'm not sure when/if I'll ever actually get to it, but some high-level thoughts about how it'd have to work:

1. We'd want the multiple windows to be open in a single Swing/AWT app, rather than having multiple copies of the app open at once. That way, we can share a DataManagerManager between them, and they'd share a common Options object, so there wouldn't be any weird overwriting, or trying to deal with multiple processes attempting to unpack the datapack database, etc.
2. A launch arg should be added to allow users to launch directly into OE without loading a mod. It might make sense to support some args to start OE with a specified game's data
3. We'll need some kind of IPC so that freshly-launched OpenBLCMM processes notice if there's already an OpenBLCMM process open, and handle things accordingly.

Various challenges/issues/details that I forsee:

• Will probably add something like a GUIManager class to keep tabs on all the MainGUI and OE windows that are open
• There are a lot of references in the code to MainGUI.INSTANCE, and at least some references to ObjectExplorer.INSTANCE. We'd need to start passing object instances around instead of relying on that, or in some cases call into the GUIManager class, if an operation needs to be done on all instances of MainGUI/OE
• OE will need a menu of its own, providing access to the settings, and the ability to launch a new MainGUI (and launching new OEs, as well)
• Settings dialog should probably be modal across the entire app, rather than just a single window (I don't think that's the case right now -- it's not a problem at the moment because only MainGUI can launch it, and there can only be one MainGUI, but it'll become a problem if we allow multiple windows). Perhaps use GUIManager to disable the Settings menu option in all other windows, once it's been opened in another?
• Should OE be able to drag tabs from one to another? Can it drag a tab "out" to create a whole new OE window? If we drag the last tab from one OE to another, should it auto-close that OE window, or create a new "start" tab?
• Figure out what to do with various CLI args in various circumstances
  • If someone launches an OE shortcut but there's already an OE window open, should it just raise the existing window, or create a new one?
  • If someone launches a MainGUI with a filename arg, should it open in a new window, or open in the existing window?
• I think we block the theme-switch dropdown when OE is open, because there were rendering issues when trying to update OE's theme dynamcally. Ideally we'd fix that issue instead of continuing that behavior.
• We'd need to figure out what to do with auto-backup files. Might make sense to start including the open-file name as part of the backup file name, though we'd want some more strict checking to make sure that we don't by chance try to write to the same file twice.
• We remember MainGUI/OE window statuses between runs. Will we just keep the parameters for the most-recently-active window?
• What to do with logging on newly-launched processes -- we'd presumably want to have some logging for that.
• "Uninstall" menu option might need some tweaking to account for multiple windows being open
• Recently-opened-files menu should probably get synced between MainGUI windows
• Opening object links from a MainGUI edit window: should it just go to the most recently open OE window? Or maybe if there are multiple OE windows, each with a different game selected, should it go to the one with the appropriate game? Or even default to opening a new OE window if the object is in a game which doesn't already have an OE window open?
• Font-size changes will require some validation and tweaks, though I think once I get that sorted out in general, it should probably be all right, since the font-size code already goes through and repaints everything necessary on the main window, if present.
  • Did we want to support allowing different windows to have different font sizes? That would entail a fair amount of extra work; right now everything just shares a common FontInfo object.
• We'd want to be able to drag-and-drop inbetween MainGUI windows freely

It'd be nice if OpenBLCMM remembered what selections you'd made, and what MUT options you had selected, if you disable a mod entirely, so that if you re-enable it later, you choices "come back." Doing that would require extra data in the mod file, of course, so I'm not sure if it's actually worth it, in the end. Still, something to think about...

OpenBLCMM Version: 1.3.3
Java Version: 20.0.1
Java VM: OpenJDK 64-Bit Server VM 20.0.1+9
Memory Used: 77.1 MB
Memory Max: 2.1 GB
BL2 Data: Loaded, v2023.04.03.01
TPS Data: Loaded, v2023.04.03.01
AODK Data: Not loaded: No jarfiles found for AODK

Running the jar version on linux.

Because I'm on a 1440p monitor I have the global font size set to 16, but despite this, BLCMM and OpenBLCMM do not use this font size everywhere.
Even more weirdly, the class explorer panel in the object explorer sometimes does use the font size and other times does not
For example:

Can go to overwritten" and\or go to overwriter, or maybe even better new thing all together, function on logic of go to closest UP\DOWN. Since now go to overwritten just goes to the closest UP and go to overwriter goes to the latest DOWN. Even then there is a sorta chain of overwrites.

Right clicking the folder and an option of "Unwrap into current category" appears so no matter how many folders are inside all of their code get moved to the selected top category.

For example we have folders named 1-4, each number inside previous one. So if i right click on Folder 3 selecting "Unwrap into current category" code from folder 4 gets moved to 3. Click on 2 code from 3 and 4 gets into 2. Just leaving empty folders behind.

Would help a lot with adjustments to some older mods that have a ton of nesting.

Right now there's a mostly-hardcoded list of syntax checks which are active in dev mode. There's technically one which already has its own setting, which highlights "incomplete" BVC statements (which isn't really an error per se, hence the toggle).

It'd honestly probably make sense to just have a separate pref for each syntax check, though. So, look into that.

OpenBLCMM does a lot of static references, using stuff like Options.INSTANCE. GlobalLogger is basically entirely static, etc. I'd kind of prefer passing around object references instead, though, so that dependencies between all that stuff is more clear. The static/INSTANCE thing has bitten me a number of times while working on OpenBLCMM, too -- for instance, I'd wanted to be able to import original-BLCMM preferences on a first-time OpenBLCMM run, but the Options class really wanted to be the only instance that there was, so a lot of that had to get tweaked to support it.

Getting rid of that kind of thing altogether might be more trouble than it's worth, so we'll have to see. It's undeniably useful to be able to just call Options.INSTANCE or GlobalLogger from Literally Anywhere and having it Do The Right Thing.

Offline helpers (https://bl-sdk.github.io/mods/OfflineHelpers/) requires changing GearboxAccountData_1 to GearboxAccountData_0 if you use forced offline mode, would be handy to have an option for this in the dangerous settings tab of blcmm

Will need some one-time conversion stuff in there, and the ability to discern between a converted version.

As a real-world example:

set GD_Siren_Skills.Cataclysm.Reaper SkillDescription You deal increased [skill]Gun Damage[-skill] (actually: [skill]Bullet Damage[-skill] and [skill]Gun Splash[-skill]) to any enemy with more than 50% health remaining.

BLCMM sees the parens in there and strips out all whitespace starting at the open-paren (though it leaves everything else up to that point alone):

Having some explicit mechanism to mark a line as "don't strip whitespace" might be nice, though that would involve a file format change. A simpler, if more fragile, solution, could be to look for language-looking text in the start of the value and then just Not Strip Whitespace No Matter What if that's detected. Like that opening of You deal increased is three whitespace-delimited tokens without any equals signs, commas, etc. So maybe that would be good enough?

I wonder if that kind of processing could get in the way of CE commands, though. Those would have arbitrary numbers of args which might look like human language. So in those cases we might need some kind of signifier after all...

A workaround for modders, in the meantime, is just using something other than regular parens. I expect square brackets would do. Though I agree it'd be nice to deal with properly in OpenBLCMM anyway.

I believe there are some issues with using the word set in values. I seem to think that a mod like Red Text Explainer ends up having to get manually tweaked in order to save out properly 'cause BLCMM's processing doesn't do the right thing.

Anyway, will need to properly figure out what the issue is and then see what we can do about it.

It looks like single-button Mac devices (like the usual macbook trackpad) can't actually open up the right-button menu at all? On the rest of the Mac OS, it looks like that's done via a Ctrl-click. So yeah, if possible, do that.

I have noticed an issue with properly displaying this search and help UI elements while resizing the window.

I am using Arch Linux with GNOME 43.4 on Xorg with an Nvidia GPU. Video demonstrating the issue: