Massive Slowdown's During Skirmish

Bug #896158 reported by Hogo
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ares
Fix Released
Medium
AlexB

Bug Description

Been getting massive slowdowns with Ares, tested and doesn't happen in Vanilla, I tested this with UMP as well and it just start going stupidly slow, I can't see a reason for this but it happens and then randomly springs back into the actual game speed.

##### STEPS TO REPRODUCE #####
Just happens randomly as far as I can tell.

Revision history for this message
Hogo (hogo) wrote :
Revision history for this message
Graion Dilach (graiondilach) wrote :

OK, my notes: This issue seems to be Urgent... but only for you. I guess for Renegade it may be more urgent to roundhouse kick you out of the tracker. Any priority above Normal is used only by the developers. If you have a reason why consider this severe, I'll listen.

Besides, if you can reproduce the slowdowns, why do you set N/A to them? N/A issues can't be major and can't be urgent.

Actual issue: How could you break a tile that crazy? It is known that destroying Tank Drops inair causes the cell to fail, but this doesn't seems caused by this. Your slowdowns are likely to be caused by a huge team of AI units failing to find a path from A to B. To be exact, you broke (98,144) and (98,143). What were on these cells? Which map is this XTERRITOR one?

Revision history for this message
Hogo (hogo) wrote :

Firstly don't talk to me like I'm a piece of shit on the bottom of your shoe, if renegade wishes he can change it but I figured something causing the same to slow to a crawl was quite serious as it prevents you from actually playing the game rendering area useless.

I'm sorry about the urgent, I didn't mean to make it major and urgent.

This has happend before in 1v1s and I never said I could reproduce this. That debug is based on a large game because it was the only debug I had with the slowdown recently, I can get another tomorrow and hope for the slowdown happens in smaller games too.

This map has always had trouble with path finding but it didn't crawl like this in vanilla yuri's revenge, I'm not trying to make peoples lives difficult I try to post things to help out the developers, I spoke to DCoder about this and told him I would get him some more details.

Hogo

Revision history for this message
YR M0ddEr (yr-m0dder) wrote :

I agree with Rob, that attitude was not needed GD, he is only trying to help. But enough of this crap.

Revision history for this message
Untrue (untrue) wrote :

I'm with Rob. I get a slowdown in small games and even without AI in unmodded game. I can back you up here but only after my desktop gets fixed today. Just ignore that asshole, Rob. He thinks he knows all. Just wait for Renegade or DCoder's response.

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Graion is correct about the priorities, although he might have phrased it better. Now stop the drama, all of you. Especially you, Untrue - unlike Graion, I haven't seen anything helpful from you so far.

The map is Territorial Imperative (2-8), a stock YR teamgame map. (You can find the name in missionsmd.ini).

According to FA2, 98/143 and 98/144 are just down and to the left of the highlighted cell in my screenshots. It's no surprise that pathfinding sucks in narrow areas. We can make it so this failure is not logged to reduce slowdown, but then you might not get meaningful information...

Revision history for this message
Graion Dilach (graiondilach) wrote :

Sorry, guys, but I JUST hate those who can't read a manual. I was harassed by a "dipshit" once on MSN who stole one of the TT-Forums' moderator's identity, just because I was a newbie in the community, and numerously seen idiots around OpenArena who were too stupid to understand a NOTTODO... if they ever bothered to read it at all.

I do mistakes as well... but a random guy (Hogo means something to me, since I read through the beta forums in January, but Watling...) with an urgent priority seemed noobish. And as you can see, I personally hate noobs and their overreacting. Urgent is an overreact.

I guess I shouldn't write negative critic when I'm sleepy. It got more aggressive then I wanted to.

Sorry again.

Revision history for this message
Hogo (hogo) wrote :

It's fine dude just don't like being treated like that, DCoder yeah that section War miners & Slave Miners always jam up I will edit the map I guess.

P.S Couldn't remember login for hogo account so I just made a new account with my actual name ;p

Revision history for this message
Hogo (hogo) wrote :

Have added another Debug for today the 14th of April, I was playing Vanilla YR with Ares Enabled, 3 AI's & Me on a small map. It was one of the CO-OP Maps I changed into a Multiplayer map.

It slowed down then speed up and randomly kept doing this throughout the entire game.

Hope this helps.

NOTE: No Yuri was involved as that normally causes lag but not this type of slowdown.

Revision history for this message
WoRmINaToR (worminator) wrote :

Rob, I believe DCoder was hinting at this, but the issue you are most likely having (I am at least 90% sure) is an issue of AI pathfinding failure. Basically you are playing on a map where the AI, in all of its glorious stupidity, gets stuck trying to "group up" at a spot some 20-ish cells away from your base... unfortunately the spot it hand-picked to be its group up point is somewhere inaccessible or is severely bottlenecked. I commonly have issues on maps like Hidden Valley and maps with lots of bridges and little space surrounding the starting bases. Try playing a 1v1 with the AI on a basic map like The Alamo and see if that doesn't help with your lag issues.

But yeah, this happens all the same in Vanilla YR but the lag is significantly less noticeable because there is no logging for it. And DCoder already mentioned the situation on disabling logging...

Revision history for this message
Hogo (hogo) wrote :

This was a completely different map where the AI had no path finding issues that I could see like the previous. Wide open map they grouped fine outside my base no blockages.

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Was your sidebar open to to the tab with a completed-and-waiting-to-be-placed building visible, by any chance? That translucent overlay on the sidebar charge anim is a significant source of slowdown unless your sidebar is in system memory as opposed to vram.

Revision history for this message
Hogo (hogo) wrote :

Does the sidebar default to system
Memory in ares? Can't remember if s structure was doing that but I will give it another go
And see what I can find

Revision history for this message
Hogo (hogo) wrote :

Here's a major slowdown again, I got a video this time to show how it changes so drasticly.

http://www.youtube.com/watch?v=o_7UtwdOmuQ

Revision history for this message
Graion Dilach (graiondilach) wrote :

I noticed you had two AIs. Isn't there by any chance a firing railgun weapon?

This seems totally like a railgun crawl.

Revision history for this message
Hogo (hogo) wrote :

No railguns in this mod yet, the point I'm trying to show was the harrier and rocketeers they crawled then suddenly jumped Into normal speed.

No advanced weapons have been added all standard stuff like dragon trailer smokes and efforts to reduce like like normalisation and transparentcy although they are not changes made in that video.

Revision history for this message
Krozalid (krozalid) wrote :

D, what's the best setting we could use in ares.ini? I don't really know how the codes work.

Revision history for this message
Bug Importer (bug-importer) wrote :

Code related to this issue has just been checked in!
Author: DCoder
Location: ft-more-graphics, r1050
Commit contains DLL: Yes
Revision comment:
Related to issue #1547 - a different approach to allocating surfaces - force all surfaces to be created in system memory regardless of game's requests or config. Ares.ini config to select which surface goes where has been removed. This was done because there are lots more surfaces than the few that were configurable in ares.ini and it makes no sense to switch each surface around separately.
SVN: http://svn.renegadeprojects.com/Ares/1050

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

As noted above, I attempted to force all surfaces to system memory. Can't notice any differences on my system, but others might.

Revision history for this message
YR M0ddEr (yr-m0dder) wrote :

So this is an overall performance upgrade/slowdown decreaser?
Sounds good if true, I will test this tomorrow with a 4 vs 4 battle(offline).

Revision history for this message
FS-21 (jagarni1983) wrote :

Before to test the r1050 I tried with r1048 & r1051 and I can say that with r1050 I noticed the gameplay a lot less laggy in skirmish battles of 7 AIs (AI vs AI battle, no teams, I'm hidden observing the AI game) except for this slowndown:

(VerySleepy captures)
http://www.megaupload.com/?d=5DLWRV04

Revision history for this message
YR M0ddEr (yr-m0dder) wrote :

me too. but this need more testing. I continue tomorrow.

Revision history for this message
Hogo (hogo) wrote :

yayzor will check when I can :)

Revision history for this message
Hogo (hogo) wrote :

Added a new debug to the top post, Another slowdown, It has quite a few Failures written in the Debug Not sure what they relate too. p.s its an open map.

Revision history for this message
YR M0ddEr (yr-m0dder) wrote :

DCoder you may want to watch this video, it gameplay comparing trunk vs graphic branch(4vs4 offline battle):
http://www.youtube.com/watch?v=BCNLXu2UwPk

Full quality(that include FPS)
480mb: http://www.megaupload.com/?d=VGCCOF55

Both two games were played with same teams on the same map, and I started to record 15 minutes after the game started.

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Heyo! More people should test the changes in that new branch, so we can merge it if it doesn't break anything.

Revision history for this message
YR M0ddEr (yr-m0dder) wrote :

this stuff related to graphics should split becuse it have nothing to do with OPs report

Revision history for this message
Hogo (hogo) wrote :

its still part of trying to prevent slowdowns though, anyway this didn't change the situation for me but I will try again.

Revision history for this message
Hogo (hogo) wrote :

http://www.youtube.com/watch?v=Sb-59L6UNdo - 8 or so seconds long, shows exactly what I get throughout a game, I can't see what triggers it, it did do it on and off when my ifv's projectile hit something and caused the impact explosion but that could have been coincidence.

I wish I could give some more concrete evidence but I just don't know what to give you, very sleepy kept crashing and refusing to show results =/

btw this is Vanilla YR + Ares nothing else no mods only have Videobackbuffer=no

P.S Sorry about the rush playing forgot I had music on.

Revision history for this message
Hogo (hogo) wrote :

Added Another Debug with slowdowns throughout 17/5/2011

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Hogo, do you have any idea which revisions introduced this slowdown? before 0.1p1, after, anything more specific?

Revision history for this message
Graion Dilach (graiondilach) wrote :

Branch drastically decreased MO's Buratino MP lag. In trunk 4 crawls the game, with this, 10 needed. I think success.

Tomorrow I do SP check to confirm YRM's video.

Revision history for this message
Hogo (hogo) wrote :

1034 is when I posted this so anything that and below, anyway for me to get the previous revisions?

Revision history for this message
Graion Dilach (graiondilach) wrote :

At the upper right corner of WebSVN, there is a Rev field. You can write any revision there and when you hit OK, you will be at that revision.

And you can download them as usual.

EDIT: Confirmimg awesomeity of new branch. Branch drastically reduces non-pathfinding lag.

Revision history for this message
Hogo (hogo) wrote :

What's the new branch? 1050? and I will try and grab the lower ones tonight

Revision history for this message
Graion Dilach (graiondilach) wrote :

Yep, 1050 is the the branch.

Try with P1 first. Then 900. And go on.

Revision history for this message
Hogo (hogo) wrote :

could you provide a link? I don't understand what you mean by P1 and 900

Revision history for this message
Graion Dilach (graiondilach) wrote :
Revision history for this message
YR M0ddEr (yr-m0dder) wrote :

Tested ft-more-graphics, r1050 online:
- custom palette
- superweapons that change lightning(nuke clone)
- new chrono sphere sw
- spammed lots of units with paradrop

No error or bugs spotted. I guess it is ready for merge now?

Revision history for this message
Graion Dilach (graiondilach) wrote :

The branch improved performance on my three-cored Athlon as well although I could only notice this increase by following an SW timer.

On my old P4, this was more noticable.

Revision history for this message
Hogo (hogo) wrote :

its strange, I still get random Slowdowns :S

Revision history for this message
YR M0ddEr (yr-m0dder) wrote :

And I am not surprised, because the ft-more-graphics branch have done nothing to fix your problem. All it have done is to improve the overall speed.

Revision history for this message
Graion Dilach (graiondilach) wrote :

Hogo, would you mind sharing a test-environment to figure out the source? We can't reproduce because we have no idea what causes it.

Revision history for this message
Hogo (hogo) wrote :

Tell me what I need to do and i will do it :)

Revision history for this message
Graion Dilach (graiondilach) wrote :

Sharing that mod's rulesmd is enough of 9 cases out of 10. The 10th case needs the whole mod.

Revision history for this message
AlexB (alexander-b) wrote :

Rob: Can you try this? Do the slowdowns still occur?
1) Start YR with Ares normally. In the main menu, tab back to your desktop.
2) Start Windows Task Manager, right-click gamemd.exe.
3) Select "Processor affinity" (might be slightly off). Select CPU 0 only, click Ok.
4) Go back to the game and play.

Revision history for this message
Hogo (hogo) wrote :

Version 1094, Got a MASSIVE slowdown I could hardly move and it gradually got quicker in jumps, SLOWEST, SLOW, Fast Faster Fastest like that in blocks. was weird.

Was set to 1 core by default also.

EDIT: I tried with two cores, It just randomly locks up and have to CTRL ALT DEL the process, it proper slows down the computer when it freezes takes a while to get the game closed.

Revision history for this message
AlexB (alexander-b) wrote :

Do you have other applications running in the background? An overly aggressive virus scanner, disk defragmentation, file indexer or the like? Firefox or another browser with Flash plugin?

If you say it was set to one core by default, you do have more than one core? If you do, can you check Explorer.exe? Is it set to one core, too? If it is, please repeat the test from above, choosing another core.

Revision history for this message
Hogo (hogo) wrote :

Avira Anti Vir, firefox and chrome normally sat on forums, moddb and twittterrr

I will set Explorer to Core#1 & YR to Core#2 and give it another go tonight.

Revision history for this message
Hogo (hogo) wrote :

Explorer.exe was set to all 8 cores, I changed it to 1, I changed Yuri's revenge to the second core.

Unfortunately it still had slowdowns :(

Revision history for this message
Graion Dilach (graiondilach) wrote :

Hogo, may I ask for a copy of your mod? I'd love to track it out.

Revision history for this message
cranium (cranium) wrote :

you wouldnt happen to be using any PlayAnimAt type triggers would you? I noticed that those like to slow down and or lag the game from time to time depending on which ones you use.

Revision history for this message
Hogo (hogo) wrote :

Graion the recent tests asked by AlexB have all been on Unmodded YR Vanilla + Ares
and I am not using PlayAnimAt but I will keep that in mind.
These slow downs happen on any map

Custom or Westwood happens on all maps.

Revision history for this message
Graion Dilach (graiondilach) wrote :

Try to disable desktop composition on gamemd, Syringe and Ares.

I moved over to a multicore CPU recently as well, yet I haven't got issues like that. Although my is an AMD one, I use 32bit OS now and I only have three cores.

Revision history for this message
Hogo (hogo) wrote :

well this is my Overall System

I7 Core @ 2.2GHz
6GB DDR3 Ram 1033
285 GTX 1GB

Software: Windows 7 professional 64x
general things running when YR is running
Avira Antivir Virus
firefox
Google Chrome
MSN
Skype

This is a general overview of the things I have and have running when Using Yuri's Revenge, I am also using The First Decade YR.

Revision history for this message
Graion Dilach (graiondilach) wrote :

Check if your HDD which has the game is running in UDMA mode, by right-clicking on an HDD->Properties->Hardware->Properties.

If it's running in PIO mode, there lies your problem, and follow this page for a fix: http://winhlp.com/node/10

For the nerds out there... my system drive did fall back to PIO once and I still don't know why, but after I ran this script, it was fixed. It was a bit interesting that Windows tried to accelerate PIO using the CPU, which caused a hell of a lot slowdown.

Revision history for this message
Hogo (hogo) wrote :

Does that only count for ATA & IDE drives? mine are all Sata and I can't find anything..

Revision history for this message
Graion Dilach (graiondilach) wrote :

Hmm.. AFAIK, it should be apply to SATA, but I only have IDE so can't check it on my own.

Revision history for this message
Hogo (hogo) wrote :

Yeah I tried checking and I can't find anything in HDD, so that's out the window
;(

Revision history for this message
Hogo (hogo) wrote :

Am I still the only person with this problem?

Revision history for this message
Graion Dilach (graiondilach) wrote :

Sorry, seems so.

Revision history for this message
Hogo (hogo) wrote :

I have no idea what will fix this so until then I guess
Yuris revenge is out the window :(

Revision history for this message
cranium (cranium) wrote :

Can you post your rules?

Revision history for this message
Hogo (hogo) wrote :

Attached rulesmd.ini nothing special but maybe there is something.

Revision history for this message
cranium (cranium) wrote :

Try playing with original rulesmd and artmd ini's and see if it still does it. If it dosent, then you'll know it's something within your rules and/or art ini's.

Revision history for this message
Hogo (hogo) wrote :

I have, It happens with normal rules and art with just ares so Vanilla YR + Ares = Slowdowns.

Also I played some TS and got some slow gameplay although that could have been normal with lots of units. I have a feeling My I7 Core doesn't agree with YR =/

Revision history for this message
WoRmINaToR (worminator) wrote :

Okay, this is a long shot, but try disabling Avira AntiVir (if that's even possible). I used that for awhile and it kept killing Syringe.exe (because it injects code into a process during runtime; in Avira's eyes that's a virus) anytime I tried to run it. The case could be different because it's Win7, but Avira could be overscanning Syringe.exe because of its code-injecting nature.

Like I said, it's a long shot but it might help because I had problems with Avira and Syringe.exe before.

However, I did test this with the original revision in which hogo reported the slowdowns, and indeed the surface-memory allocation is again messed up in that revision (and many that follow), so I'm not ruling that out as a possible cause. Testing 1050 now to make sure that's all fixed...

EDIT: And I can confirm the slowdown's fixed for me... what the heck is still wrong with Hogo's setup...?

Revision history for this message
Hogo (hogo) wrote :

I will try disabling Avira as yeah I can understand it may not like syringe.

I was playing TS lastnight and noticed that whenever the green overlay was going when building something on the cameo it would slow down but as soon as the green was gone and it said ready it got quick again. Was this normal for TS? or is my CPU/GFX playing up? Thus could be like my problem with YR

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Did you see my note 9611 (http://bugs.renegadeprojects.com/view.php?id=1547#c9611) ?

Was your sidebar open to to the tab with a completed-and-waiting-to-be-placed building visible, by any chance? That translucent overlay on the sidebar charge anim is a significant source of slowdown unless your sidebar is in system memory as opposed to vram.

Revision history for this message
Hogo (hogo) wrote :

I don't notice that on YR but I will retry it again I really noticed it in TS and I am using a newer version of Ares but I am not using a ares.ini at the moment for the graphics allocation settings, doesn't Ares set them to a default preferred?

Revision history for this message
Hogo (hogo) wrote :

Checked again, Sidebar building isn't effecting it as I was getting slowdowns with nothing building, although a paradrop timer could effect it?

and Avira was disabled it didn't help :(

Revision history for this message
cranium (cranium) wrote :

Have you tried adding these to your ra2md.ini?

[Video]
VideoBackBuffer=no
AllowVRAMSidebar=no

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Those are overridden by Ares' [Graphics.Advanced], and in ft-more-graphics, they cannot be set at all as Ares will use hardcoded settings for them.

Revision history for this message
Hogo (hogo) wrote :

Played another using Ft-more-graphics it was good until me & AI started attacking the allies base, I think prism may have had a effect on the speed?

Revision history for this message
AlexB (alexander-b) wrote :

I guess it was caused by the slow Firestorm check. This was fixed for Ares 0.2. Does this still happen?

Changed in ares:
status: In Progress → Incomplete
Revision history for this message
AlexB (alexander-b) wrote :

Considered fixed.

Changed in ares:
assignee: DCoder DCoder (dcoder1337) → AlexB (alexander-b)
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.