r1032 unit slow when executing orders

sander79 · Post by **sander79** » 08 Apr 2007, 12:31

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.

Hatsjoe · Post by **Hatsjoe** » 08 Apr 2007, 14:43

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 · Post by **lav_coyote25** » 08 Apr 2007, 15:29

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

sander79 · Post by **sander79** » 08 Apr 2007, 17:30

P4 2,66Ghz, is that too slow to play this game now?
I never had this problem before.

Hatsjoe · Post by **Hatsjoe** » 08 Apr 2007, 23:07

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.

Post by **DevUrandom** » 08 Apr 2007, 23:27

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.

Post by **Watermelon** » 09 Apr 2007, 16:13

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...

sander79 · Post by **sander79** » 10 Apr 2007, 20:02

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.

Post by **DevUrandom** » 10 Apr 2007, 22:03

sander79 wrote: (I suppose there is no logfile where I can see which SVN versions I have downloaded)

On Windows you can see this in the properties menu and on linux you can use svnversion.

Post by **Giel** » 11 Apr 2007, 10:39

DevUrandom wrote: On Windows you can see this in the properties menu

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: and on linux you can use svnversion.

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.

Radiosity · Post by **Radiosity** » 11 Apr 2007, 11:19

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.

Post by **Watermelon** » 11 Apr 2007, 12:00

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.

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'.

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

Radiosity · Post by **Radiosity** » 11 Apr 2007, 22:39

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.

lav_coyote25 · Post by **lav_coyote25** » 12 Apr 2007, 00:20

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 (?).

Post by **Kamaze** » 12 Apr 2007, 08:06

http://docs.wz2100.net/

Lav, i'll give you the FTP data if i'm back from work.
I just unzipped it quickly.

Warzone 2100 Forums

r1032 unit slow when executing orders

r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders

Re: r1032 unit slow when executing orders