Engine Testing - 10. Aug 2012 (89.0.1-87-gce4d36e)

[jamerlan]

I tried under windows vs AI and it crashed. Infolog and demo are atttached

[jamerlan]

next attempt - commander stuck
demo attached. It's very short

[jamerlan]

next try.

Big troubles... unplayable.

03:15 - commander can't build water lab

12:10 - 14-00 - water t1 cons can't build adv shipyard.

demo attached.

[jamerlan]

I tested more... can't reproduce "Even after removing dragoon teeth units cannot go though where dt use to br . U need to individually micro step by srep every single unit So that work" in singleplayer. Maybe it's reproducible only if enemy built these dt. Or it was fixed (I doubt).

[Silentwings]

First try with it - used the MT build and had a serious problem right off. The map (dsd) was black with some blue-ish green sections of noise on it. Tried /advmapshading 0 but nothing changed. See picture & stuff.

[Silentwings]

Second try - used non-MT. Had the same problem with the map. Built some units and they seemed to work fine.

You can see something odd with pathing, though. The commander turns back and forth for about 20 seconds while trying to start to build the veh lab.

[Silentwings]

Third try - used a diff map (tropical). Same-ish problem with map, although its not completely black this time its much darker than it shold be and the noise is still present.

For what it's worth, the segments of the map which display noise seem to alter at random as i move around the map.

[Kloot]

03:15 - commander can't build water lab

12:10 - 14-00 - water t1 cons can't build adv shipyard.

The commander turns back and forth for about 20 seconds while trying to start to build the veh lab.

don't add target's radius to the builder's builddistance (...) ->
from now on the to be built unit's centerpos has to be in buildrange not its border

What this means: if a builder's range is smaller than the distance to a buildee's center, it may be forced to move inside the footprint to get in range and then other code will order the builder out again to clear said footprint --> repeat until the end of the universe.

Now check BA builder ranges vis a vis large structures.

Hint: this (too short ranges) is also the reason you "have troubles with constructors".

[jamerlan]

Kloot, do you mean that build distances for BA constructors should be increased to the radius of biggest building they can build?

If yes, I think it can change balance etc.

[Kloot]

ask jK for a better solution

[FLOZi]

Kloot, do you mean that build distances for BA constructors should be increased to the radius of biggest building they can build?

If yes, I think it can change balance etc.

Change should be quite minimal unless you have really huge buildings

[Silentwings]

Thanks Kloot - will see what I can do about that. I can't think of any situations where increasing build distance to > max radius of building would majorly alter the balance?

Although I don't think its a major problem for BA, tbh it seems to me an un-natural requirement to place on constructors in general. For example, I can't think of how a player tells precisely if the nano they are building will help a nearby factory or not.

Any thoughts on the black ground bug? I've not had it in plain 0.89 but I did a portable install of the test build so it may be using different gfx settings to my normal.

[Johannes]

What is the reason for the builddistance change?

[jK]

Forb had a bug with it.
The code was full of special cases between mobile & immobile units. I unified and modularized the code (the distance checking is now done in a single code function).
Regarding the issue kloot mentioned, it's not specific to the change here, still it was increased by it. First unit are still able to build units with bigger unitradius than their buildrange (it's a special case in the distance check). If the footprint is much greater than the buildrange, but unitradius is shorter than buildrange, the problem kloot mentioned occurs. The solution is footprint & unitradius are need to be ~equal, still the unitradius shouldn't be bigger than footprint, just a _bit_ smaller.

[jK]

Any thoughts on the black ground bug? I've not had it in plain 0.89 but I did a portable install of the test build so it may be using different gfx settings to my normal.

Running out of video memory and/or broken gfx drivers -> switch them

[dansan]

* ST & MT both render fine for me on dsd and zion (linux 3.5.0, gentoo, 64bit, nvidia 304.37 blob).
* BA7.70 and bar-736 arm&core-coms can build veh lab w/o problem.
* BA7.70 arm-com can build sea lab w/o problem (didn't tested with others) (see screen00027).

Regarding the build range I noted the following (seen in BA-7.70 and BAR-736): to start a building the com moves a little nearer to the center of the buildee than absolutely necessary (see screen00025). If you then move the com away and tell it to continue building it builds from further away (see screen00024).

No idea if mod or engine must fix this, just wanted to report it...

A question: is the green circle calculated correctly? I noted (in prev. versions) that nanos can reclaim from a little outside this circle - commonly used in dsd-com-blow-tech.

[Silentwings]

Running out of video memory and/or broken gfx drivers -> switch them

I don't think so - there is plenty of video memory free and my gfx card has had no problems with spring (ever!) until this test build.

Sounds sensible to me what you've done with build radius, but probably the code (a widget iirc) which displays buildradii needs to be adapted for it.

[jpcordovae]

HI to all, I have an error compiling this spring branch as you can see here:

http://pastebin.com/f3eFu7JZ

boost version: 1.49
gcc version 4.7.1 (GCC)

JP

[varikonniemi]

Built fine on ubuntu 12.04 x64
Quick playtest vs AI in zk, no glitches noticed.

[Google_Frog]

89.0.1-106-g13bc2f1 seems to work. With QTPFS units tend to get stuck on the terrain but that is configurable.