Mouse actions lag

[silent]

Lately my mouse actions have been very laggy. I'm 99% sure it's not my system, fresh reboot, i7 950 6 GB ram, Radeon 5970 graphics, Win7 64, Pincos UI. Mouse clicks will be ignored dragging items across the screen lags. Nothing running in the background just UO.

 

[Pinco]

this happen to me after LONG crafting sessions...
for example if I do bods for more than 1 hour this strange lag starts, but it's because the client in some way seems to keep in memory the data of the crafted items.
The same happen in champion spawn, some of the creatures will stays in memory (and sometimes you can also see those non-existent creatures).

For now the only solution I found is close and reopen the client

 

[silent]

That's funny I was filling bods as well. Although I did reboot and start over and the mouse lag still seemed to be there.

 

[silent]

I think I figured out how to recreate it. When I'm crafting the container I have open has 100 items plus the items showing in my pack. The debug thing you mentioned in another thread shows 125 items being tracked, although there are more on my screen. When I had a large amount of items displayed on the screen the lag is there. If i close the container with 100 items and open a container with maybe 20 items there is no mouse lag whatsoever.

 

[Pinco]

there are just too many items around then :/

 

[Pinco]

try now, should be better...

 

[silent]

I updated the UI and it does seem a little better moving items around. Where you can really see the "jumpiness" is if you expand or reduce a pack. Thanks for the tweak

 

[Conrad]

I've experienced the crafting lag you speak of. I've tied it, by repeated testing, to the crafting process and in particular the make max function. Indeed, the longer you craft, the worse it gets. Closing the client to clear RAM seems to solve the issue (the amount of RAM being used shows a definite slope upwards while crafting, then resets to a reasonable level upon reboot of UO).

But, I've also experienced something even more annoying, and unfortunately it is not tied to crafting and seems to be present at all times, but is far worse during peak hours--I think it is tied to the Comcast related lag everyone has been experiencing. What happens is that the time it takes for the client to recognize an item on cursor mouse-over and highlight/tooltip seems to be taking way longer then it used to. What this means is you have to actually wait up to a second to left click before you can drag an item (or get the tooltip). To make matters worse, once you do start dragging the item sometimes the shift modifier doesn't apply, which leads to dragging the entire stack instead of being given the split-stack gump.

I've based the assumption that this is somehow tied to the Comcast lag on the fact that it seems worse during peak hours--the same times I can do a trace and see that lag on ALTER.NET routers.

But here's the weird thing--I don't experience this problem in the 2D client. While I still get the "run/pause/run/pause/run" of the Comcast lag in the 2D client, I do not get the mouse/item issues like I do in the EC.

Pinco, there is a "Run mouse in separate thread" mode in the 2D client--Do we need something similar in the EC? It seems to me that both issues might be solved by doing just that--run the mouse in another thread. Is that possible with the EC and LUA, or would it be something that the Devs would have to implement through the .exe?

 

[Pinco]

I've experienced the crafting lag you speak of. I've tied it, by repeated testing, to the crafting process and in particular the make max function. Indeed, the longer you craft, the worse it gets. Closing the client to clear RAM seems to solve the issue (the amount of RAM being used shows a definite slope upwards while crafting, then resets to a reasonable level upon reboot of UO).

But, I've also experienced something even more annoying, and unfortunately it is not tied to crafting and seems to be present at all times, but is far worse during peak hours--I think it is tied to the Comcast related lag everyone has been experiencing. What happens is that the time it takes for the client to recognize an item on cursor mouse-over and highlight/tooltip seems to be taking way longer then it used to. What this means is you have to actually wait up to a second to left click before you can drag an item (or get the tooltip). To make matters worse, once you do start dragging the item sometimes the shift modifier doesn't apply, which leads to dragging the entire stack instead of being given the split-stack gump.

I've based the assumption that this is somehow tied to the Comcast lag on the fact that it seems worse during peak hours--the same times I can do a trace and see that lag on ALTER.NET routers.

But here's the weird thing--I don't experience this problem in the 2D client. While I still get the "run/pause/run/pause/run" of the Comcast lag in the 2D client, I do not get the mouse/item issues like I do in the EC.

Pinco, there is a "Run mouse in separate thread" mode in the 2D client--Do we need something similar in the EC? It seems to me that both issues might be solved by doing just that--run the mouse in another thread. Is that possible with the EC and LUA, or would it be something that the Devs would have to implement through the .exe?

no, the true issue here is the malfunctioning of the client garbage collector... all the items/mobiles/particle you see at some point starts to sit in your memory and when they are too many you starts to lag...
I did all what I could to prevent it, but there still something I cannot clear from script :/

 

[Conrad]

no, the true issue here is the malfunctioning of the client garbage collector... all the items/mobiles/particle you see at some point starts to sit in your memory and when they are too many you starts to lag...
I did all what I could to prevent it, but there still something I cannot clear from script :/

Ok, I get it.

Back when I was in a WoW raiding guild (40 players on-screen at a time, most of the time), we had a similar issue--ever-increasing UI lag due to so much stuff stored in memory. The fix was simple--there was a console command that could be run to both reload the current UI and clear memory. /reloadui

Now, World of Warcraft utilized LUA for modding as well. I realize that we, the players, don't have full access to slash-commands, but do you have access to similar UI requests with the LUA permissions in Ultima?

In other words, might forcing a UI reload also reset the memory? If so, could this be done while logged in, perhaps with a hotbar button?

 

[Pinco]

Is useless here, because I've added the cache cleaner to keep clean everything that could be filled by the UI. The rest is all part of the game itself and you must close and reopen the game to clean that...

Is no more a matter of UI...
However you can reload the ui by pressing CTRL + R, but it makes more bad than good