Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Gemviper

Pages: 1 2 3 [4] 5 6 ... 32
46
Computer Rigs / Re: Running list of motherboards I've built with over the years
« on: April 02, 2017, 10:27:22 PM »
Celeron, it was such a leap ahead at the time, you were styling in game with that one! I started out on a Pentium II which my company kindly paid for as part of their "employee computer program" and I remember the difference when I upgraded well, lol. Right around the time I switched to playing DAoC(more graphics intensive than UO) from UO...

I don't have it anymore, but kinda wish I did. Those old systems are still cool(for some things).

Wish I had my old VIC-20 too, lol. I wonder if I'd remember how to PEEK and POKE still.

47
Character skill advancement / Re: HopKiddo Ninjitsu Trainer
« on: March 23, 2017, 08:01:28 PM »
My previous message about CPU issues removed, the problem was not related to this script.

If you have problems with this script causing lag or increasing your CPU use dramatically I detailed what I found over here - www.scriptuo.com/index.php?topic=14285.msg116527

48
General UO Chat / Re: It's time to talk about lag, again
« on: March 23, 2017, 07:49:00 PM »
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.

49
General UO Chat / Re: It's time to talk about lag, again
« on: March 23, 2017, 07:36:28 PM »
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...

50
General UO Chat / Re: It's time to talk about lag, again
« on: March 23, 2017, 07:11:48 PM »
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.

51
General UO Chat / Re: It's time to talk about lag, again
« on: March 23, 2017, 06:50:06 PM »
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*

52
General UO Chat / Re: It's time to talk about lag, again
« on: March 23, 2017, 06:33:22 PM »
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.

53
General UO Chat / Re: It's time to talk about lag, again
« on: March 23, 2017, 11:06:08 AM »
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.

54
General UO Chat / It's time to talk about lag, again
« on: March 23, 2017, 08:52:00 AM »
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?


55
Character skill advancement / Re: HopKiddo Ninjitsu Trainer
« on: March 22, 2017, 06:43:59 AM »
Just a heads up,

Since the last patch, on OSI, this script is bleeding memory somehow. Turn it on and monitor resources and every jump increases the load until finally the screen is near frozen and the account closes.



56
Site News / Re: Time for a change to the site slogan
« on: March 12, 2017, 11:41:50 AM »
Sweet,   I went for simple wordplay, this being where we "command pixels" and all :)

57
Submit your Script / Single Item Speedloot
« on: March 12, 2017, 11:22:34 AM »
Outdated, sorry

58
Site News / Re: Time for a change to the site slogan
« on: March 12, 2017, 10:37:31 AM »
I like it too. I was thinking "Pixel Command Central" but as usual I'm late to the show :)

59
Scripting Chat / finditem * G - just curious
« on: February 11, 2017, 12:26:16 PM »
Just a curiosity, when I'm testing things I often just specify G_2 to keep things simple. The documentation suggests this is supposed to limit a scan to the ground around me, up to two tiles away. In practice, however, I notice that it occasionally picks up things like ZJF(my character's backpack), YC(my right or left hand even if empty) and even IS(my character itself). For testing purposes this is a bit of a pain, though not more than a minor nuisance really.

My question: why is it happening and is there a simple universal way to keep searches on the G and away from players and their gear? Unfortunately this does not happen all the time, or even half the time, but when it does it's usually on the very first item found.

note: I am usually testing within a #findindex, if that matters.


60
Script Debug / Re: #FINDCNT incorrect value
« on: February 09, 2017, 01:46:32 AM »
Quote
Why not just use: if #findcnt > 0. That means an item was found.

Not always. If you perform one finditem and iterate through the results to perform an action, like run towards one of the results, an if #findcnt > 0 will return true even if that particular item(or corpse) is no longer there, is ignored etc. The reason being if 25 items were found the #findcnt just increments downwards with each iteration.

example: You're running a looting script and while running towards the 3rd result of your finditem iteration someone else picks it up. CHecking to see if it's still there before continuing to run using if #findcnt > 0 will result in a false positive... you may have found 25 items and so the 3rd result would still leave #findcnt at +23. It increments downwards with each iteration.

Of course you could add a new finditem but that defeats the purpose of just using one to begin with(speed). In this scenario it's actually better to set a variable with the current item result and monitor it's distance from you until it's within 3 tiles. If it suddenly goes N/A it's gone and you can continue the loop to move on to the next item.

Check to make sure your script isn't using #findindex together with a #findcnt > 0 within it's loop? I'm not as polished as some others here though and I'm sure you can get better advice, but I hope that made sense.

Pages: 1 2 3 [4] 5 6 ... 32