r1032 unit slow when executing orders
r1032 unit slow when executing orders
Yesterday I was playing skirmish with version r1032.
When I gave an order to an unit or a group it took a very long time before the done that.
Also when sending units (especially a truck) to a place on the map (even when it's only a few tiles away) it's refusing that and only moves when pointing to a tile that it's right before this noise.
When I gave an order to an unit or a group it took a very long time before the done that.
Also when sending units (especially a truck) to a place on the map (even when it's only a few tiles away) it's refusing that and only moves when pointing to a tile that it's right before this noise.
Re: r1032 unit slow when executing orders
Your first problem commonly appears on older computers. When issuing orders on certain maps the cpu has to calculate the route for the unit(s) to get to the point you ordered them. And untill the calculations have been completed, the unit will not move. I don't know if this can also happen when just ordering 1 unit. I suppose the truck problem is some sort of a bug. Maybe the 2 are connected
- lav_coyote25
- Professional
- Posts: 3434
- Joined: 08 Aug 2006, 23:18
Re: r1032 unit slow when executing orders
this behaviour is just one of the "features" that came with the original release and has been there to this day. it has to do with the pathing / gateways / walls built / cliff tiles. hatsjoe is correct about the waiting until the calculations are done.... thing is some times the AI strings give an hillarious option - ie the truck will turn around and go on the "scenic route" a path that will take it all around the map , and back to that single tile you wanted it to go to.... just an observation from hours and hours and hours of map tweaking / playing etc. ;D
"to prepare for disaster is to invite it, to not prepare for disaster is a fools choice" -me (kim-lav_coyote25-metcalfe) - it used to be attributed to unknown - but adding the last bit , it now makes sense.
Re: r1032 unit slow when executing orders
P4 2,66Ghz, is that too slow to play this game now?
I never had this problem before.
I never had this problem before.
Re: r1032 unit slow when executing orders
No, for route calculating that's definetly fast enough and if you never experienced it before it's probably a software bug in the new release. Hopefully some developer will try to fix it, but i think it's hard to find out where exactly the broblem lies. For now i would revert to 2.0.5 and hope the thing will be solved in 2.0.7 or whatever next release.
- DevUrandom
- Regular
- Posts: 1690
- Joined: 31 Jul 2006, 23:14
Re: r1032 unit slow when executing orders
If he uses the SVN version, my recommendation would be to find out since which revision this regression is present...
If you could tell us what was the last release you used before you experienced the slowness, that might help to narrow the search a lot.
If you could tell us what was the last release you used before you experienced the slowness, that might help to narrow the search a lot.
- Watermelon
- Code contributor
- Posts: 551
- Joined: 08 Oct 2006, 09:37
Re: r1032 unit slow when executing orders
I just compiled and ran the latest rev,the group move order works fine for me(no noticeable pause after executing the order using mouse-left-button),the order/action parts havent been changed for some time now since last time developers touched it,and I dont remember it being broken in old revisions...
The failed pathplanning problem is something else,like lav_coyote25 mentioned,the problem is both source-wise(some map-zone problems Troman mentioned iirc) and map-wise(gateway and map-area accessibility),so I dont know exactly how to fix that yet...
The failed pathplanning problem is something else,like lav_coyote25 mentioned,the problem is both source-wise(some map-zone problems Troman mentioned iirc) and map-wise(gateway and map-area accessibility),so I dont know exactly how to fix that yet...
tasks postponed until the trunk is relatively stable again.
Re: r1032 unit slow when executing orders
The working version was not more than a day of one or two before r1032.
(I suppose there is no logfile where I can see which SVN versions I have downloaded)
I'll try it again with the current SVN.
(I suppose there is no logfile where I can see which SVN versions I have downloaded)
I'll try it again with the current SVN.
- DevUrandom
- Regular
- Posts: 1690
- Joined: 31 Jul 2006, 23:14
Re: r1032 unit slow when executing orders
On Windows you can see this in the properties menu and on linux you can use svnversion.sander79 wrote: (I suppose there is no logfile where I can see which SVN versions I have downloaded)
Re: r1032 unit slow when executing orders
Only when using TortoiseSVN. But if you're not using it, take my advice and check it out, combined with the commandline version of Subversion it is really great in managing your working copy.DevUrandom wrote: On Windows you can see this in the properties menu
If you're using the commandline version of Subversion, wether on Windows or GNU/Linux, you can also type `svn info` in you're working copy directory, `svnversion` does more, it also checks whether local changes are made, and if you're using a mixed revision working copy.DevUrandom wrote: and on linux you can use svnversion.
"First make sure it works good, only then make it look good." -- Giel
Want to tip/donate? bitcoin:1EaqP4ZPMvUffazTxm7stoduhprzeabeFh
Want to tip/donate? bitcoin:1EaqP4ZPMvUffazTxm7stoduhprzeabeFh
Re: r1032 unit slow when executing orders
Something I've noted on many occasions: The AI is dumb. VERY dumb. They build stuff in completely retarded locations (the Ziggurat map is a prime example thanks to its design layout) and tend to get themselves stuck. At which point, they continue to churn out unit after unit, causing more and more congestion until it slows all unit movement down, even your own.
As an example, I was playing Ziggurat yesterday (original game since the redev releases don't play nice on my system for some reason) and eventually all 7 other players built themselves into their bases and had more or less reached the unit production limit. As a result of all those AIs trying to move stuck units, my own unit AIs were taking upwards of a minute to respond to any order that wasn't just a simple move to a location they could directly see.
Of course, vtols worked fine because they can move from one location to another with a simple line of sight. My attack units though... just sat there and took a beating from the various random enemy units that happened to pass by, they couldn't even respond to attacks.
As an example, I was playing Ziggurat yesterday (original game since the redev releases don't play nice on my system for some reason) and eventually all 7 other players built themselves into their bases and had more or less reached the unit production limit. As a result of all those AIs trying to move stuck units, my own unit AIs were taking upwards of a minute to respond to any order that wasn't just a simple move to a location they could directly see.
Of course, vtols worked fine because they can move from one location to another with a simple line of sight. My attack units though... just sat there and took a beating from the various random enemy units that happened to pass by, they couldn't even respond to attacks.
- Watermelon
- Code contributor
- Posts: 551
- Joined: 08 Oct 2006, 09:37
Re: r1032 unit slow when executing orders
I think the retarded building placement is the map's fault,lay_coyote25 mentioned something about 'gateway' in maps which prevents the AI from building structures on map tiles marked as 'gateway'.Radiosity wrote: Something I've noted on many occasions: The AI is dumb. VERY dumb. They build stuff in completely retarded locations (the Ziggurat map is a prime example thanks to its design layout) and tend to get themselves stuck. At which point, they continue to churn out unit after unit, causing more and more congestion until it slows all unit movement down, even your own.
As an example, I was playing Ziggurat yesterday (original game since the redev releases don't play nice on my system for some reason) and eventually all 7 other players built themselves into their bases and had more or less reached the unit production limit. As a result of all those AIs trying to move stuck units, my own unit AIs were taking upwards of a minute to respond to any order that wasn't just a simple move to a location they could directly see.
Of course, vtols worked fine because they can move from one location to another with a simple line of sight. My attack units though... just sat there and took a beating from the various random enemy units that happened to pass by, they couldn't even respond to attacks.
The long respond time of order is probably due to some limitation on max number of orders can be executed per game frame.
What problem you are having with the 2.0.x?if it's performance problem,you should try running it in fullscreen mode with '--fullscreen'/lowering colorbits('color = 32' to 'color = 16' in a file called config without any extension) and disabling shadows via --noshadows
tasks postponed until the trunk is relatively stable again.
Re: r1032 unit slow when executing orders
It's not performance, my pc is quite capable of playing it at 1440x900x32 with shadows, but it slideshows pretty badly and there is nasty white artifacting on the radar + various other places around the main screen. I'm guessing it's not liking opengl for some reason, maybe the drivers I'm using for my card. I can't use the latest drivers as they don't like my card and cause serious screwups, but even so, I've never had any serious issues with opengl before, so I'm not really sure what the problem is.
Unless... it's my cpu. I think it could be on it's last legs, so that is likely part of the reason (I also can't play Dungeon Siege 2 for some reason, so I'm guessing it's probably hardware related.) I've got a new mobo + cpu lined up though (being replaced thanks to getting not one but two faulty ones in a row) so I'll see how things go when I get that installed
On the retarded AI issue, I seem to recall that the AI's to like to build along gateways, causing no end of problems as they trap themselves into stupid locations.
Unless... it's my cpu. I think it could be on it's last legs, so that is likely part of the reason (I also can't play Dungeon Siege 2 for some reason, so I'm guessing it's probably hardware related.) I've got a new mobo + cpu lined up though (being replaced thanks to getting not one but two faulty ones in a row) so I'll see how things go when I get that installed
On the retarded AI issue, I seem to recall that the AI's to like to build along gateways, causing no end of problems as they trap themselves into stupid locations.
- lav_coyote25
- Professional
- Posts: 3434
- Joined: 08 Aug 2006, 23:18
Re: r1032 unit slow when executing orders
cccccccc...................ccccccccccc
cccccccc...................ccccccccccc
cccccccc...................ccccccccccc
ggggggggggggg
c= cliff face
..... = passable terrain
g = gateway
the ai will build along the gateway - as long as you have at least 5 squares - it will leave 1 open. 4 / 3 / 2 it wont. you can not have a gateway that = 1.
i did some experimenting with gateways and made a cross in the exact center of the map... and that was all - units were still able to navigate and had few problems with it. each arm of the cross had 5 squares.
if your wanting the rest of the information it is available. in the Documents Project . i believe its somewhere on this site in the ftp.... maybe kamaze or devurandom can give the link (?).
cccccccc...................ccccccccccc
cccccccc...................ccccccccccc
ggggggggggggg
c= cliff face
..... = passable terrain
g = gateway
the ai will build along the gateway - as long as you have at least 5 squares - it will leave 1 open. 4 / 3 / 2 it wont. you can not have a gateway that = 1.
i did some experimenting with gateways and made a cross in the exact center of the map... and that was all - units were still able to navigate and had few problems with it. each arm of the cross had 5 squares.
if your wanting the rest of the information it is available. in the Documents Project . i believe its somewhere on this site in the ftp.... maybe kamaze or devurandom can give the link (?).
"to prepare for disaster is to invite it, to not prepare for disaster is a fools choice" -me (kim-lav_coyote25-metcalfe) - it used to be attributed to unknown - but adding the last bit , it now makes sense.
Re: r1032 unit slow when executing orders
http://docs.wz2100.net/
Lav, i'll give you the FTP data if i'm back from work.
I just unzipped it quickly.
Lav, i'll give you the FTP data if i'm back from work.
I just unzipped it quickly.
We all have the same heaven, but not the same horizon.