That's the issue I have for years now.
Whenever I select a texture, it choose either the previous or the next one. It happens almost every time I do it. Is it something's wrong on my side, or that's just a common issue nobody talks about?
Page 1 of 1
Sliding tiles selection
#1 Posted 10 October 2019 - 03:46 AM
#2 Posted 10 October 2019 - 04:11 AM
No I’ve had that issue and it’s annoying. I recall Helixhorned saying he either wasn’t having the issue or he couldn’t see a problem in the code, but that was years ago.
#3 Posted 10 October 2019 - 05:42 AM
I remember the short lived problem many years ago but it hasn't been an issue since for me.
#4 Posted 11 October 2019 - 12:51 AM
Micky C, on 10 October 2019 - 04:11 AM, said:
No I’ve had that issue and it’s annoying. I recall Helixhorned saying he either wasn’t having the issue or he couldn’t see a problem in the code, but that was years ago.
So it's the problem that everybody's aware of, that some people still have it but devs won't fix it because they don't have it themselves?
#5 Posted 11 October 2019 - 06:23 AM
Feel free to tests years worth of revisions to track it down and give that info to the devs.
#6 Posted 11 October 2019 - 06:32 AM
Sanek, on 11 October 2019 - 12:51 AM, said:
So it's the problem that everybody's aware of, that some people still have it but devs won't fix it because they don't have it themselves?
It's pretty hard to fix something if you can't reproduce it.
Bisect previous eduke32 revisions (from here: http://dukeworld.duk...ke32/synthesis/ ) and see at which revision the problem starts occurring, then report your results.
This post has been edited by Doom64hunter: 11 October 2019 - 06:33 AM
#7 Posted 11 October 2019 - 06:51 AM
I've encountered this, but it's usually involving a mod or TC. Putting the same snapshot into a vanilla folder didn't reproduce the behavior, so I just learned to deal with it.
#8 Posted 11 October 2019 - 09:52 AM
How are you selecting it? With the arrow keys and enter key? With the mouse?
#9 Posted 12 October 2019 - 06:43 AM
When I encountered it, the issue was with mouse selecting.
The companion to the problem is the tile that's highlighted.
The white box is on one tile, and the tile next to it has the "pink" highlight.
The white box is the actual tile selection, not the pink.
Even so, trying to select the white boxed tile would often select the pink highlighted one. (with mouse click)
in the row above the cameras:
The companion to the problem is the tile that's highlighted.
The white box is on one tile, and the tile next to it has the "pink" highlight.
The white box is the actual tile selection, not the pink.
Even so, trying to select the white boxed tile would often select the pink highlighted one. (with mouse click)
in the row above the cameras:
This post has been edited by Forge: 12 October 2019 - 06:51 AM
#10 Posted 21 January 2020 - 01:07 PM
I can finally reproduce this, and I think I understand what is happening. I was also able to determine the revision that started the problem.
To reproduce it, simply try to scroll past the beginning or the end of the tile list using your mousewheel.
If you try to scroll past the upper boundary and then select a tile (without scrolling down again!) then you will select the next tile in the list instead.
The opposite happens if you try to scroll past the lower boundary, in that case you select the previous tile.
Note that there is a functionality where if you select and lock an existing tile in 3D mode with the left mouse button, you can use the mouse wheel to directly scroll through the tiles without bringing up the list.
Therefore, what I think is happening here is that a single mousewheel input is somehow buffered when one tries to scroll past the top or the bottom of the list. Then, once you click on a tile with the mouse, the buffered mousewheel input fires, and combined with the mouse input it erroneously triggers the aforementioned functionality.
In other words, if you scrolled all the way to the top, a single "Mousewheel Up" input is buffered, which is fired once one selects a tile. Combined with the left mouseclick used to select the tile, it then scrolls the tile one step forward in 3D mode.
Notably, if you try to scroll past the top and then select a tile with the Enter key, the issue does not occur -- further supporting this theory.
Bisection indicates that this was introduced by commit r4200:
To reproduce it, simply try to scroll past the beginning or the end of the tile list using your mousewheel.
If you try to scroll past the upper boundary and then select a tile (without scrolling down again!) then you will select the next tile in the list instead.
The opposite happens if you try to scroll past the lower boundary, in that case you select the previous tile.
Note that there is a functionality where if you select and lock an existing tile in 3D mode with the left mouse button, you can use the mouse wheel to directly scroll through the tiles without bringing up the list.
Therefore, what I think is happening here is that a single mousewheel input is somehow buffered when one tries to scroll past the top or the bottom of the list. Then, once you click on a tile with the mouse, the buffered mousewheel input fires, and combined with the mouse input it erroneously triggers the aforementioned functionality.
In other words, if you scrolled all the way to the top, a single "Mousewheel Up" input is buffered, which is fired once one selects a tile. Combined with the left mouseclick used to select the tile, it then scrolls the tile one step forward in 3D mode.
Notably, if you try to scroll past the top and then select a tile with the Enter key, the issue does not occur -- further supporting this theory.
Bisection indicates that this was introduced by commit r4200:
Quote
Rewrite and unify the handling of the scrollwheel between layers, fixing it in the editor's 2D mode and tile selector under SDL.
The scrollwheel is unique among PC input because it has no innate "hold length". Previously, the layers gave the mousewheel a fake hold length to allow the not-necessarily-synchronous game/editor code to pick up the input before the layers marked it as "no longer pressed". This passed under Windows, but it didn't slide under SDL.
Besides the two problems listed above, it also potentially limited the rate of weapon selection, where scrolling too fast would not register every clicks. [Unrelatedly, this is still the case when you scroll faster than the game's own tickrate, but addressing that would require rewriting input handling to go through a list of "events" for each tic instead of looking at overall pressed/unpressed states.]
The scrollwheel is unique among PC input because it has no innate "hold length". Previously, the layers gave the mousewheel a fake hold length to allow the not-necessarily-synchronous game/editor code to pick up the input before the layers marked it as "no longer pressed". This passed under Windows, but it didn't slide under SDL.
Besides the two problems listed above, it also potentially limited the rate of weapon selection, where scrolling too fast would not register every clicks. [Unrelatedly, this is still the case when you scroll faster than the game's own tickrate, but addressing that would require rewriting input handling to go through a list of "events" for each tic instead of looking at overall pressed/unpressed states.]
This post has been edited by Doom64hunter: 21 January 2020 - 01:12 PM
Share this topic:
Page 1 of 1