Descriptive Problem Summary:
This is specially noticable in SS13, since assholes very usually manage to stack a whole crapload of items in one place, if this pile is right clicked, depending on the size, may lock the client up for several seconds, up to half a minute if the pile is huge
This also occurs on small menus when the server is a bit bogged down
Numbered Steps to Reproduce Problem:
1. Get on a laggy server, whatever SS13 server has the most players on the hub is usually a good candidate
2. Stack a load of crap on the floor
3. Right click the pile
Does the problem occur:
I havent tried it outside of SS13, I havent encountered any really laggy games that rely on the right click menu
ID:1326139
 Jul 16 2013, 3:00 pm (Edited on Jul 16 2013, 3:07 pm)
|
|||||||||||||
| |||||||||||||
|
Jul 17 2013, 12:53 am
|
|
Rushnut
 |
This sounds like it's more just a "It doesn't matter what the program is, if it has to loop through 9001 items and build a RMB menu entry for it, it's GOING to lag", than an actual bug with BYOND.
|
The RMB menu could build over time, adding some entries and then allowing other code to execute before adding more entries.
| |
But what kind of delay are you talking? If it were simply, say, one tick, .1 of a second, and it waited every say, 10 elements it needs to build an entry for, a stack of 100 objects alone would take an entire second, which would feel ridiculously unresponsive.
I mean to say, I don't know exactly what kind of timings you'd want to put on such a thing but they would have to be incredibly, incredibly tiny. | |
Yeah if they were tiny, it would not lock up the client. This is how anything works... For example, when you look at a list of available quake servers, they don't all show up at once.
If you want to load a map, you don't load all the tiles at once otherwise the loading screen won't be able to update its progress. | |
Although I haven't seen or used the popup menus in years, I'm pretty sure they're client-side. The delay would be client-side and not be limited to game ticks. It also wouldn't have to happen after each item in the list (for example, wait 0.1s every 10 items shown), and there's also a limit to how many items would fit on your screen.
I think the popup menus could be improved in a lot of ways. Appearance customization, use of a scrollbar and scroll wheel, max # of items for a shorter list to scroll through. Maybe even skip the objects list and go straight to the verbs, if there's only one object there. | |
Also, this could be avoided if ss13 had item quantity.
| |
Correct but during those moments the player isn't expected to be actually playing so it's acceptable.
A good example is the Skyrim debug room, inside of it are containers which have millions of items inside. If you try to open them with a computer that isn't NASA grade, you're going to be sat there for a good long ass time whilst it builds the list entries for you. | |
Adding item quantity to that particular game wouldn't eliminate the issue entirely, since it's still possible to get 30 (or easily more) different types of item on the same tile. And there are surely other games that have a similar issue on crowded turfs.
| |
Probably, but BYOND shouldn't have to cater for bad game design.
| |
The ultimate answer is fix the design of the game (yes, allowing thousands of items to show up individually in a right click menu is bad game design).
The work-around more "ok" fix is to make the RMB Menu take processing pauses between building list items so the client doesn't freeze up. | |
If the server is bogged down, 100 items can take over half a minute, I dont think thats intended
| |
I checked again, its about 0.2 seconds delay for every item, it shouldent take that long to just add an entry to a list, if the servers bogged down the delay gets even worse
| |
Tobba wrote:
I checked again, its about 0.2 seconds delay for every item, it shouldent take that long to just add an entry to a list, if the servers bogged down the delay gets even worse Erm not to be rude but, duh? I personally can't see the kind of delay you're talking about though, only when there's a large number of atoms being right clicked, in which case again it's an issue of game design not bad engine. | |
Because it shouldent take 30 seconds to display a fucking menu with 100 items
| |
Rushnut wrote:
Tobba wrote: Right clicking a tile is supposed to be mostly, if not entirely client side - so if I may ask why does server lag affect the performance of right clicking? It's an issue of bad engine; yes, fine, I don't expect more than a screen's worth of right click menu to process in any kind of sane time, but we have this issue with *5* objects, especially when the server is loaded. Add this to the fact that right clicking actually does a range check for items (in fact, for each verb), which is probably what's causing the whole thing to be laggy. | |
Thinking DM knows how to into client sided anything Yeahno. (Probably, I'm just assuming) | |
I agree that bad design is a problem here, but a delay of 0.2s per item is obviously not acceptable. I'll be looking into it.
There is an O(N^2) algorithm governing the icon sorting process that could be a problem; we're no longer properly mirroring the way icons are sorted on the map. However, while this is a bubble sort and extremely ugly, it shouldn't account for the kind of delays being seen. Building the menu might, and the problem might simply be one of having to grab a verb list for each individual item and then building a submenu for it. Assuming the verb list isn't the problem, building the submenus might be; it might just be something the system really sucks at doing quickly. That will require profiling, however, and a good test case. I'm pretty sure I can build the test case without much trouble. | |
It doesnt actually happen locally, I spawned 99 objects on a tile and right clicked it, took like 200ms tops
On a live server, depending on how much its lagging, you could be stuck there for minutes | |
Even on a live server, I've gotten very reasonable right click times if the amount of lag is low, this seems to be networking related
Actually, the amount of time per object seem to be closely related to the round-trip ping pong time | |