It's time to talk about lag, again

[Gemviper]

The last mini, non-mandatory, patch is causing me huge headaches but the problem existed before. One powerful computer, one instance of UO, one script running and over time the CPU use climbs to 100% causes freezing fpr 5-10 seconds at a time. The script is the hopkiddo ninjutsu trainer, and each jump causes a CPU spike which increases over time, but the same happens with stealth scripts(and probably others). It's not a script problem like I originally thought it was, CPU reaches 100 no matter which script but some take longer than others.

Solution: just log out and log back in again, the UO cache is cleared and it's back to normal... for a short time anyway.

It doesn't seem to be an EUO problem at all, only that EUO performs actions quickly and repetitively bringing on the slowdown much more quickly(comp takes just 10 mins with hopkiddo). How can I either fix this CPU use increase over time or turn off cache or... anything to make the CPU stop climbing steadily?

Ideas?

[gimlet]

What version of windows?
How much real memory?
Do you have any usb drives acting as cache?
Does your hard drive have plenty of extra space available?
What virus checker software ya running?
What client are you runnibg?
Are you using razor or uosteam?
What graphics card are you using and do you load any software extra for graphics?

[Gemviper]

It's taking me 10 mins to freeze on the hopkiddo trainer, closer to an hour on a stealth trainer or running rails etc. This is on an Asian shard too, but it's a pain. This is my game comp, my work comp is stronger. I have two game computers with the same build and ALL THREE have the same problem.

What version of windows? Windows 7 64-bit, I don't want to upgrade to 10
How much real memory? 16GB Ram (vid card has 6GB ram)
Do you have any usb drives acting as cache? No
Does your hard drive have plenty of extra space available? 166GB free right now, 200gb drive
What virus checker software ya running? No automated virus checking, I sweep with seek and destroy and with a kaspersky rootkit detector. No viruses right now
What client are you runnibg? 2D client, last version that works with the current EUO build
Are you using razor or uosteam? Neither
What graphics card are you using and do you load any software extra for graphics? My game computers run a pair of these since Jan - https://www.amazon.com/Gigabyte-GeForce-Xtreme-Graphics-GV-N1060XTREME-6GD/dp/B01KCWZ2EO/ with no extra software.

If you'd like to test this CPU increase until 100% is reached try logging into an off-shard and running the Hopkiddo ninjitsu trainer, it seems to bring the CPU use up the fastest and each jump corresponds to a hit of the 100% cap and a "not responding" error while the white cloud flashes then a drop back to 50% until the next jump. I can play wow and it's steady at 16%, no spike, no increase. Restarting the client(but not touching EUO) resets the CPU to about 15% and it starts climbing again with each passing minute.

According to a guildmate here was a non-mandatory mini patch the other day which I did not download but since that day my problems started.

[gimlet]

ok just 2 more
Are you running EUO version 310?
Are you running UO client 7.0.57.20 ?

[Gemviper]

UO Client: 7.0.57.1
EUO Version: 309

I know there is a newer version of both but I have never upgraded unless it stops working. I always end up screwed on a minipatch and having to wait a while for another mandatory patch to use it again, lol.

[gimlet]

I just ran the script on both 7.0.57.1 and 7.0.57.20 on Siege and could not reproduce your problem.
I wonder if the Asian shard might require the update.
sorry no other ideas!

[Gemviper]

I've been rebooting the client when the cpu reaches 90%. Sometime after 8:45 PM tonight the problem has greatly improved, it's taking twice as long to reach 90%, but still happens. I tried it on Atlantic and also could not reproduce the problem anymore, it's only affecting me on the Asian shards right now. I have 8-9 ninja's to go too, it was sailing along nicely until the last mini-patch was released.

Ah well, hoped there was an easy fix, but looks like it's something behind the scenes so to speak.

Thanks for the suggestions Gimlet. I'm going to quickly download the updates since it looks like they are in sync right now. *fingers crossed*

[Gemviper]

Update: Freshly scanned computer, nothign else running whatsoever, idle of between 0% and 3% CPU use with both EUO and UO running. Casting a magery spell, for example, sees a small spike from 3% to maybe 6% and back. A recall makes it spike a little, from 3% to 9% max and back....

But the stupid ninjitsu shadowjump does, well, see for yourself... over 50% right from the start and will continue to escalate until the jumps hit 100% and cause a temporary not responding condition as the white cloud flashes then back down 50% or so from wherever it's capping out.

Very strange. Each spike represents a successful jump. Each missing spike is a fizzle. Great way to fry your computer if left to run for an extended time.

For comparison on this PC
- magery spell caps at 6%
- recall spell caps at 9%
- netflix streaming caps at 16%
- World of Warcraft caps at 15%
- CoD caps at 21%(extreme settings)
- The UO shadowjump... over 50% while the white cloud flashes as well as a slow increase over time with subsequent jumps.

They need to fix it, or perhaps ditch the white cloud effect, it's definitely not optimized.

[Gemviper]

Another update: On a hunch I did a bunch of manual jumps of only 1 tile, then set the hopkiddo script to only jump 1 tile in each direction, and the result is dramatic. Just in CPU are no longer up to 50%, but instead are around 15%. While the problem still exists it takes much longer to demand 100% and possibly reveals more info about the problem.

Each jump moves the character position and it looks like that movement is forcing game screen to load, which is what is causing CPU use to spike. It's not the white cloud effect, it's how much ground is covered. A longer jump creates a larger spike as more new tiles come into range. Perhaps there's a way to limit how much new tile info is received? or cache it somehow? I'm not sure this is possible on the user end, but here's hoping...

[Gemviper]

Last update(I promise), as I think I found the culprit. It was indeed related to the loading of new tiles, but a little more complicated. I was running this from the 3rd floor of my house which caused the very edge of my screen to display black tiles, or just out of range tiles so to speak. These are in fact just off the map in Malas.

It seems these cause a huge load on the game with shadowjumping. I moved down to the second floor so as not to see these anymore and the problem went away completely. 1st floor, outside etc... no problem. Over by the darkness, HUGE problems.

Pics attached, I hope this helps someone else sometime. The type of tiles being loaded with each jump proved to be the(very frustrating) problem. If you run into increasing lag, try relocating your ninja.

[gimlet]

Nice Find! What screen resolution were you running?

[dxrom]

You have to take into account that the Z-Axis are considered tiles that affect the viewing distance.

Best way to see this is the build up a tower of goza mats. Another way to explain it is that, you cannot place something a tile infront of you, if where it would land is 50+ tiles below and above you. The higher you increase your Z-Axis, the less of the surroundings you will see that are at lower Z-Axis...

Also the resolution changes created an issue that that has yet to be, and more than likely never will be addressed with the classic client,  which is that the classic client now has much more data to parse to and from the server as not only does the classic client technically have to send data about the increase of terrain, items, players, etc it sees, but it also has to accept more data from the server about what others can also see that that they can accurately be drawn on our clients as well. The servers with the previous allowed viewable distances were optimized around the classic client being able to function smoothly and thus where they were previously was the drawing range min/max for the client to not get bogged down. Bleak did not take the into consideration however when updating the viewing distances. And yes people have always been able to increase their resolutions however your client was actually only able to draw/see so far as allowed by the server.

I've been saying it for years now, the classic client needs to be better able to parse data. It doesn't need new art, resolutions, or any of that garbage... What it needs is to not get bogged down just because it's attempting to draw four in-flight afk gargoyles.