Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Very long object list cannot be scrolled #592

Open
Gymnasiast opened this issue Nov 24, 2014 · 14 comments

Comments

@Gymnasiast
Copy link
Member

commented Nov 24, 2014

Since my RCT2 was ten years old when I copied it to OpenRCT2, it should be no surprise I have accumulated a ludicrous amount of plug-in objects (my ObjData contains nearly 7000 files, including the original RCT2 ones). This makes the list of Small Objects in the Scenario Editor so long it's not scrollable any more.

This bug is present in both vanilla RCT2 and OpenRCT2.
(Since I'm probably the only one crazy enough to test OpenRCT2 with a setup like this, I sometimes seem to catch bugs that are hard to reproduce. So if you need a copy of my (1.4 GB) setup, I can provide it.)

@IntelOrca

This comment has been minimized.

Copy link
Contributor

commented Nov 24, 2014

Probably possible to mock lots of objects for testing. The scrolling will need to be fixed at some point, but that doesn't solve the problem too much. So I have also said enhancement, the list could probably be separated into multiple categories (like it is in the new ride menu) and also have a search or filter box.

@Gymnasiast

This comment has been minimized.

Copy link
Member Author

commented Nov 24, 2014

Vanilla RCT2 solved this for the Guest List by splitting it into multiple pages when needed (can be tested by having 4000 guests or more in your park, using a trainer).

@RollingStar

This comment has been minimized.

Copy link
Contributor

commented Dec 6, 2014

I imagine that a 7-zipped object folder would be fairly small - small enough to dump on Mediafire or somewhere.

@janisozaur

This comment has been minimized.

Copy link
Member

commented May 12, 2016

@Gymnasiast how's this in current builds?

@Gymnasiast

This comment has been minimized.

Copy link
Member Author

commented Sep 29, 2016

Still the same, though the list is no longer stuck (which I fixed myself) and the scrollbar thumb is no longer 0.1 mm high (fixed by a contributor): at some point, the checkboxes stop drawing. Then the list items themselves stop drawing (though the preview when hovering keeps working).

@IntelOrca

This comment has been minimized.

Copy link
Contributor

commented Sep 29, 2016

at some point, the checkboxes stop drawing. Then the list items themselves stop drawing (though the preview when hovering keeps working).

You are probably going past 32767 pixels high in the list which is the limit of drawing. Can't really fix until full implementation or UI engine re-write.

@Wuzzy2

This comment has been minimized.

Copy link

commented Sep 29, 2016

One possible (probably partial) fix would be to force a minimum size for the scroll bar (about 10 pixels or so) simply to make sure it can always be grabbed. I am not sure if this will solve all of the problems.

@Gymnasiast

This comment has been minimized.

Copy link
Member Author

commented Sep 29, 2016

@Wuzzy2 The scroll bar is already fixed (in the way you described).

@IntelOrca

This comment has been minimized.

Copy link
Contributor

commented May 17, 2017

It would be a large change, but you can probably change all the scroll offsets in the window struct and event handlers to 32-bit integers now.

@Gymnasiast

This comment has been minimized.

Copy link
Member Author

commented May 17, 2017

That would certainly be a solution.
However, splitting the list into pages does have the advantage of being easier to handle by the user.

@marijnvdwerf

This comment has been minimized.

Copy link
Contributor

commented May 17, 2017

I've never seen a scrollable list split into pages, except for RCT2 and Gmail. So I'm not sure about the 'being easier to handle by the user'.

@Gymnasiast

This comment has been minimized.

Copy link
Member Author

commented May 17, 2017

So you think a list of several kilometres is easier to handle than one split into pages? To me, that makes no sense.

@marijnvdwerf

This comment has been minimized.

Copy link
Contributor

commented May 17, 2017

Splitting it up in pages doesn't serve any purpose, as the position of the items isn't fixed. It sounds like the search system needs to be improved upon.

@Ryder17z

This comment has been minimized.

Copy link

commented May 18, 2017

@Gymnasiast
He's probably using imperial thus this :)

I like the idea of splitting the items, possibly the most flooded letters (or group of letters) gets their own pages, i.e: A-G, H, I-Z when you have lots of objects called something that begins with H.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.