Descriptive Problem Summary:
Numbered Steps to Reproduce Problem:
Code Snippet (if applicable) to Reproduce Problem:
Expected Results:
No lag while movement.
Actual Results:
Lags extremely bad and uses way too much cpu for a person moving. (Got to 111% usage, wtf?)
Does the problem occur:
Every time? Or how often?Every time since the update to v4.90.
In other games?Unknown.
In other user accounts?Yes.
On other computers?Yes.
When does the problem NOT occur?
Didn't have that issue until I updated my byond version to v4.90.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
v4.89.
Workarounds:
Downgrade? :/
Snapshot(s):
Click me!
This snapshot shows TWO mobs(characters) moving around WITH 21% efficiency..., wtf? I never even changed ANYTHING in the movement and I believe the v4.90 update with native pixel movement affected it.
ID:119181
 Sep 28 2011, 12:41 am
|
|||||||||||||
| |||||||||||||
|
Sep 28 2011, 12:45 am
|
|
Skornejoey
 |
I was the other MOB with him on that SS, an he is right it lags horribly when you walk. This only began when he updated his BYOND version. So currently we have beliefs that it is the update of BYOND that causes the movement lag.
|
And as I downgraded v4.90 to v4.89, the issue is gone. You guys should take a look into this.
| |
I can't investigate this without something to look at. You need to send me the source at [email protected], and give me full instructions on how to start the game and get to a point where I can see the issue.
In our tests we have never seen anything like what you're describing. It would be helpful to know more about the server, like how many players were on it at the time. | |
When I was hosting a test server(with v4.90), separate from main server (with v4.89), it lags extremely bad with just TWO mobs. But, once I downgrade from v4.90 to v4.89, it is back to normal. Both servers were hosted on SAME net, SAME computer. Once you get on the game and START to move, it lags awfully. So, I do believe it is native pixel movement you guys have embedded into the v4.90 update. Will be sending in the source shortly.
| |
With just two mobs you should not be seeing extreme lag. Our tests on performance were extensive and there was never an issue remotely like you described, so I have to think the problem is in one of the support routines, or more specifically one of your overrides thereof. I'll see what I can find in your source.
| |
I can understand that, Lummox. However, as seeing I recompiled on different laptop(Vista) and tested it once more, it went from 100% to 91% in few movements... Could it be because I compiled on Win 7? Or could it be because I included custom macro, that has command of "instant" set up for every arrow available?
Edit: Didn't mean command, but built in-var. Edit2: The idea about the instant part, isn't even making sense what-so-ever, as it didn't lag at all on the current v4.89 server. Hmm, so I don't really know why it does that. I've been trying to keep the game "lag-free" as much as possible. This part of v4.90 bugs me a lot. | |
Setting the instant flag isn't a good idea for repeating vars. Nevertheless repeats will only happen once a tick, so that really shouldn't be an issue. It does bring to mind that mouse command behavior changed though, and if you have mouse foo that could be related. I have to see the source to know more.
FYI there is no decimal in the version numbers. | |
Thanks for the FYI part. I'm uploading it as I type this. I'll send over an e-mail to you with the link shortly.
| |
The mediafire link is coming up as invalid; when I put it in, the site says it's a missing or deleted file.
Also, mediafire? Really? | |
Awkward, what site do you prefer then?
| |
Lummox JR wrote:
The mediafire link is coming up as invalid; when I put it in, the site says it's a missing or deleted file. Then what would you prefer for future reference. | |
Lately rapidshare doesn't suck a lot, and megaupload I've never had any issues with (that Greasemonkey couldn't solve). Mediafire does a nasty Ajax thing where it sets up a popup I have to remove manually; I can use it, so don't let that deter you if it's the quickest option to get that file up right away, but it's pretty annoying as file sharing sites go.
| |
Darker Legends wrote:
Then what would you prefer for future reference.That's what I'm asking him... I didn't know if he liked MF or not. I also don't know why that link wasn't working. | |
Ah, MegaUpload it is.
| |
Let me know when you've completed the download, so I may remove it.
| |
I've run a number of tests on your code, but I have been unable to replicate your results. The world.cpu value never gets very high when hosting in 490 or 489. The only thing I did notice, which led me off on a wild goose chase, was that the Move() proc (and those that call it) is reporting an abnormally high realtime value that I think is unusual--but isn't borne out in my actual test results. However this high realtime value exists in 489 as well. Overall, I saw no performance difference whatsoever.
| |
Then, it might have been "one-time" thing - I guess?
However, thanks again Lummox. So, it isn't that of a big deal. Raz | |
This disturbs me because you claim that it happens every time in the initial report. To clarify, can you reproduce the problem right now?
| |
I think I understand the cause of the high realtime profile for Move(): There's a sleep() call in there that could be confusing our profiler code. Actually that should really be a spawn() call, so Move() returns right away.
It would help narrow this down to know if this slowdown always happens for you on 490 and always doesn't on 489, so multiple test runs would be recommended. I'd also like to know if there are any other factors involved, like for instance if this is something unique to your character or your key. A new character for me didn't cause the issue; does it for you? And is it possible your character or key uses some kind of admin panel that ordinary players don't have, that could account for some of the change? A test on a non-admin key would be crucial. | |