[RANT] X4 UI interaction bugs

[Sam L.R. Griffiths]

It is long overdue for Egosoft to fix the aspects regarding making mouse interactions with their UI reliable.

They should know about the issues in question by now, and the current state of affairs is unacceptable to persist for much longer.

Having written mouse cursor hit box code detection code myself I know there is absolutely no excuse for the current situation to persist for as long as it has done.

As it currently stands, the situation with making selections from the property lists and similar screens is unacceptably poor.

In addition, please kill the auto-tree expansion code on entity selection - this causes other issues and can make the selection of multiple ships unacceptably awkward as well as causing unnecessary UI load.

[Buzz2005]

viewtopic.php?f=192&t=415107

read the dev post, next build will have improvements for mouse interaction

[Sam L.R. Griffiths]

viewtopic.php?f=192&t=415107

read the dev post, next build will have improvements for mouse interaction

Thanks for the link, but that does not negate the fact that the problem should not have persisted as long as it has - arguably it should not have been an issue in the released product in the first place. It is a pretty fundamental feature of a UI to ensure user interactions work properly.

From the sounds of things, they may only be addressing part of the problem.

[SPiDER]

Its also NOT fixed that post relates to 2.2b we are now on 2.21 and its sill the same Broken along with a whole host of other things.........
just check the utter **** up when they TRIED ( and failed ) to sort the drone issue 2.21 got rid of all those excess cargo drones everyone had....but it STILL dosent auto replace used ones or allow adjustment once the initial order had been fufilled.
Seriously Build a 1.5 billion cr shipyard and no building drones or cargo drones...wtf is that?????? etc etc etc more other broken stufff...still probably get censored for adding to your rant post

[Nifhtyeq]

No one being censored also did they already mention the ui. If you are having genuine problems with bugs then put it in tech support section

[Sam L.R. Griffiths]

If you are having genuine problems with bugs then put it in tech support section

It is a well known issue - but as I have already pointed out, it is one that should not have been in a released product.

[Nifhtyeq]

If you are having genuine problems with bugs then put it in tech support section

It is a well known issue - but as I have already pointed out, it is one that should not have been in a released product.

This whole game has problems that shouldn't be in the game. What is past is prologued. The real question is are they going to address it and while link provided here showed they are addressing some ui issues especially with some recent patches I don't they gonna do a full redesign. Not yet if the game has become unplayable to you leave it alone. I've done that before with a game.

[Sam L.R. Griffiths]

If you are having genuine problems with bugs then put it in tech support section

It is a well known issue - but as I have already pointed out, it is one that should not have been in a released product.

This whole game has problems that shouldn't be in the game. What is past is prologued. The real question is are they going to address it and while link provided here showed they are addressing some ui issues especially with some recent patches I don't they gonna do a full redesign. Not yet if the game has become unplayable to you leave it alone. I've done that before with a game.

I don't expect a full redesign, just get the existing implementation to work properly as it should have done at release. Preferably, they should properly fix and test the UI before the next major landmark update.

The problems with the UI are irritating but can be tolerated to a point - due to the UI interaction issues, I would not blame anyone for trying to paint X4 as not fit for purpose. Egosoft are doing a reasonable job where feature development is concerned but are critically failing on the quality/testing front.

[graphicboy]

I don't expect a full redesign, just get the existing implementation to work properly as it should have done at release. Preferably, they should properly fix and test the UI before the next major landmark update.

The problems with the UI are irritating but can be tolerated to a point - due to the UI interaction issues, I would not blame anyone for trying to paint X4 as not fit for purpose. Egosoft are doing a reasonable job where feature development is concerned but are critically failing on the quality/testing front.

I will absolutely agree that there are some flaws in QA, not the least of which is a lack of stress tests and long SETA run saves. Moving past the fact that they released in an alpha state, they've unfortunately had to fix a number of issues that made the game unplayable. The caveat there of course was finishing things like Ventures while there were so many other, actually critical things missing.

As best I can tell, the UI-interaction (clicks-in-the-wrong-place) bug has more to do with being CPU bottle-necked than anything. I rebuilt my computer mainly to address this very issue, because I was running sub-par hardware. I can still reproduce it if I run SETA for a couple days straight and leave it running while I try to do something.

[pref]

As best I can tell, the UI-interaction (clicks-in-the-wrong-place) bug has more to do with being CPU bottle-necked than anything.

Wouldn't say that, i had this issue on fresh start with a proper PC, above the recommended settings.
Also trade window was auto closing itself quite often when moving the mouse.
I'd even change how the object list is sorted, adding new entries to the bottom and keeping ships that left the sector since the map was opened with a different color so they won't dodge the cursor all the time.

[Sam L.R. Griffiths]

As best I can tell, the UI-interaction (clicks-in-the-wrong-place) bug has more to do with being CPU bottle-necked than anything.

Wouldn't say that, i had this issue on fresh start with a proper PC, above the recommended settings.
Also trade window was auto closing itself quite often when moving the mouse.
I'd even change how the object list is sorted, adding new entries to the bottom and keeping ships that left the sector since the map was opened with a different color so they won't dodge the cursor all the time.

I have not seen the auto-closing issue often but I have seen it and it is probably related to the flawed mouse-click hit-box issues, most likely a pure maths issue as opposed to processor starvation (though it can not be completely ruled out as a potential root cause of some incidents).

CPU bottle-necking should not affect UI mouse click accuracy, it might affect responsiveness but that is another matter entirely. Even if CPU bottle-necking was part of the root cause it should not be because that would imply there are racing conditions in the multi-threaded code which should not exist.

[graphicboy]

I have not seen the auto-closing issue often but I have seen it and it is probably related to the flawed mouse-click hit-box issues, most likely a pure maths issue as opposed to processor starvation (though it can not be completely ruled out as a potential root cause of some incidents).

CPU bottle-necking should not affect UI mouse click accuracy, it might affect responsiveness but that is another matter entirely. Even if CPU bottle-necking was part of the root cause it should not be because that would imply there are racing conditions in the multi-threaded code which should not exist.

Seemed to me from observing the UI that it was relying on synchronous processing of mouseenter/mousemove/mouseleave to complete on all objects. The cursor itself is hardware based on its disconnect from fps, but "where it is" was still software.

"should not" apparently is. They can either remove the synchronous processing, or remove the hardware cursor. Either one solves the problem.

[Sam L.R. Griffiths]

I have not seen the auto-closing issue often but I have seen it and it is probably related to the flawed mouse-click hit-box issues, most likely a pure maths issue as opposed to processor starvation (though it can not be completely ruled out as a potential root cause of some incidents).

CPU bottle-necking should not affect UI mouse click accuracy, it might affect responsiveness but that is another matter entirely. Even if CPU bottle-necking was part of the root cause it should not be because that would imply there are racing conditions in the multi-threaded code which should not exist.

Seemed to me from observing the UI that it was relying on synchronous processing of mouseenter/mousemove/mouseleave to complete on all objects. The cursor itself is hardware based on its disconnect from fps, but "where it is" was still software.

"should not" apparently is. They can either remove the synchronous processing, or remove the hardware cursor. Either one solves the problem.

Believe it or not, MFC/.NET has been multi-threaded in essence for years and handled mouse click events reliably.

In the cases of mis-clicks I have witnessed, the mouse cursor had not moved between the time of the click and the time of the reaction thus the positional data should be accurate regardless.

The way most mouse handling code works is event driven in nature and normally runs in according with the following pattern:-

1. Mouse Button Click detected
2. Position of cursor recorded by click detection code
3. Clicked object/region identified
4. Event raised against the object/region click handler including which button/buttons and cursor position at the time

Getting rid of a hardware cursor is not actually required.

[graphicboy]

In the cases of mis-clicks I have witnessed, the mouse cursor had not moved between the time of the click and the time of the reaction thus the positional data should be accurate regardless.

Ah, those - I'd forgotten since they were less frequent for me. Hopefully that specific problem isn't the extent of the upcoming fixes. We'll see soon (tm) enough.

[Sam L.R. Griffiths]

In the cases of mis-clicks I have witnessed, the mouse cursor had not moved between the time of the click and the time of the reaction thus the positional data should be accurate regardless.

Ah, those - I'd forgotten since they were less frequent for me. Hopefully that specific problem isn't the extent of the upcoming fixes. We'll see soon (tm) enough.

They are pretty much the only mis-click occurrence for me, on top of that there are still cases of button hit boxes consistently not matching the actual position of the visual representation of the button (e.g. station logical overview screen).

There are other UI issues such as the expansion issue highlighted in my OP and multi-select issues as a direct consequence of this.

Overall, the UI code needs to be comprehensively tested and fixed by Egosoft before the next landmark release, even if it means delaying the release itself.

[pref]

I have not seen the auto-closing issue often but I have seen it and it is probably related to the flawed mouse-click hit-box issues, most likely a pure maths issue as opposed to processor starvation (though it can not be completely ruled out as a potential root cause of some incidents).

Definitely not a HW resource issue, have that from the start on games where i have a single ship and smooth fps both on menus and 3D render.
I can maybe use the trade window normally in 30% of the time or even less.

Think it has to do with mouse movement, or mouse over events. Also my HOTAS might have something to do with it.
If i use the trade window with keyboard interaction only then the auto close never occurs. Even with mouse sometimes i have to move the cursor over certain UI elements to trigger the close (like moving it above the amount selection bars). Sometimes right when i move the mouse the auto close happens.
In cases the whole map closes not just the trade window, which seems like a more severe lua error (though i never checked logs for this).

The click issue is probably different, seems like the data describing the click is not stored well/"quick" enough (maybe there is an async call there as well which allows for the target change).

[Sam L.R. Griffiths]

Definitely not a HW resource issue, have that from the start on games where i have a single ship and smooth fps both on menus and 3D render.

I agree that it is almost certainly not a HW resource issue; However, if there are any racing conditions in the related code then any H/W resource bottlenecks are unlikely to help matters.

Overall, it is up to Egosoft to identify the root cause(s) of the issues and resolve them.

[adeine]

There are definitely some quirks in how X4 handles UI events, to the point that 2.0 broke left click selection for me and a few others, submenus not always expanding on hover, or being able to get keys stuck when changing from one UI context to another. Like pressing shift a moment early when trying to rename a ship, entering its name and clicking away only to find yourself accidentally shift selecting everything in the property list in one giant glitch fest because the shift key is now stuck.