quantumstate

The AI doesn't currently run in its own thread. The main reason currently is that it would break the profiler. Plus it gives some incentive to keep the AI's nice and efficient for now. The only updates sent are changes, so most of the trees will have no update sent unless a unit has recently been gathering from it. This is simpler because otherwise you have to keep track of what updates have been applied etc. It would probably be slower than the current system.

If you have updating entity collections then dead units will be auto removed. When using removeEnt you must pass it an Entity object. Common-api-v2 is used by all of the current developed bots so should be stable.

Sorry for the late reply. I'm slightly confused by this. You can already grab an entity by id easily, with qBot's I just call GameState.getEntityById(id). The system was deliberately designed to be able to desync the AI from the rest of the simulation, this will allow AI's oyu run in their own threads without needing to lock the rest of the game. For this it is essential to create a copy of the required state. Keeping the copy up to date doesn't take much cpu time you can easily see in the profiler (F11).

Also clock speed is a really bad indicator of cpu performance these days. New cpu designs do more per clock cycle.

I changed the images to be 512x512 with the map preview being 400x300 in the top left corner of the image. Please use this for all new map previews to avoid cropping/stretching.

This is because I resized all of the maps and introduced a crop option in the C++ but this means it needs a rebuild due to the C++ changes.

It would be nice to get rid of the tiling. I wonder if a few (maybe 3) variants of each texture, placed randomly would remove most of the problem. I don't really have any idea, though I a sure someone must have tested something like this before.

I think it would be more fun not to have a visible path for the mine except for the player building it. So if you built one from far enough away then the enemy would not even see it coming. Of course this would be very time consuming and if they scouted they could destroy it. The build speed should definitely decrease with distance. There could also be a wood cost because pit props will be needed for a tunnel. If we would include a feature if someone implemented it well enough then I think it should have a ticket. Low priority tickets shouldn't cause any problems apart from making the list of tickets longer. Also split this into a new topic due to my awesome mod powers.

In the AoE series there was an area which displayed useful information on hover (this could be disabled in the settings) instead of a tooltip. Perhaps that would be good in this case?

One way to do a tournament would be to have players just pick opponents from a pool. Then each result would be recorded and could be used to compute a ranking. The computation would work similarly to the Google pagerank algorithm. This means that if I beat a high ranked person I get many more 'points' then if I beat a rubbish person. So you are encouraged to play people your level and it gives a pretty fair ranking. This would mean it would be easier to find a game since you wouldn't be restricted with who you can play. It does feel a bit less like a tournament though.

I have tweaked the parallax shaders a bit. I managed to fairly successfully remove the stepping artefacts, but the aliasing artefacts due to the step size still remain. A before/after comparison is http://imgur.com/a/5ivAp . It is pretty cheap which is nice. I had a go at trying to remove the aliasing artefacts but wasn't very successful. @@ -121,11 +124,14 @@ #endif s = 1.0 / iter; + float t = s; move = vec2(-eyeDir.x, eyeDir.y) * scale / (eyeDir.z * iter); vec2 nil = vec2(0.0); + float height2 = 1.0 + s; #define PARALLAX_ITER {\ - height -= s;\ + height -= t;\ + t = (h < height) ? s : 0.0;\ vec2 temp = (h < height) ? move : nil;\ coord += temp;\ h = texture2D(normTex, coord).a;\ @@ -162,11 +168,15 @@ PARALLAX_ITER PARALLAX_ITER #endif #endif + + float hp = texture2D(normTex, coord - move).a; + coord -= move * ((h - height) / (s + h - hp));

In your latest commit in the config file you added ; Maximum distance to display very high quality parallax effect. Set to 30 to enable. materialmgr.PARALLAX_HQ_DIST.max = 0 Shouldn't this be VHQ_DIST?

Welcome to the forums and thank for your feedback. In 0 A.D. we have a military focus so we will not be implementing the more simulation orientated features like regrowing forests. For gaining resources later in the game once the map has been depleted we have farming and trading. It is also possible to exchange resources of different types (bartering) at the market. This is what the AI needs to be modified to handle, though some element of using the resources at hand would be good as well.

Oops, I missed this post. Thanks for confirming this. We will end up using cropped pictures rather than stretched ones like I provided here because the stretched ones look ugly due to resizing algorithms being imperfect.

Those docs are fairly incomplete, I recently did a little bit of updating so they are not incorrect, just missing a lot of useful info. On the threading issue, the AI system was designed to handle threading very nicely. It will be very easy to thread it without sync issues because of the AIProxy layer which creates a copy of the games state before sending to the AI so the AI will work with a slightly out of date snapshot. What would be less easy would be to not break the profiler which is one of the reasons which this hasn't been done yet. So when writing an AI you can forget about threading completely and sometime later each AI will get a thread.

I strongly disagree with this. I do not want my workers garrisoning when an enemy raiding force arrives. I want to move them myself to a safer gathering spot instead. The game is currently designed with direct unit control by players, which I like, I don't think adding this special case would be good.

Just have 9 possible colours.

The animated trees aren't meant to be used in game, the performance cost is too high, I think they were just done for a test. I think we should just removed the animation. I don't know if the model is available without the animation attached already, worth checking to avoid duplication.

Maybe the change in actor files from the data driven texture loading patch has borken the perl script?

I have attached a set of resized png's to this post. The game should load them I think, just delete the dds files and stick the png's in. This feels like a lot of effort to just test the power of two textures . Hopefully this is the actual issue. mappreview.zip

I'm not sure there is much of my work left. Zaggy did some fairly extensive remodelling. It feels a bit silly to add me.

The relevant trac ticket is http://trac.wildfiregames.com/ticket/599#comment:23 . As you can see, this has unfortunately not been fixed yet. It is unlikely to get done before Alpha 11, it is a high priority ticket so will get done at some point.

Did you check in both public.zip and update.zip? If the directory isn't in either then that might be the problem (missing files).

It would genuinely be really easy. The hardest bit is calibration, which in the spirit of all good maths textbooks is left as an exercise to the reader. Once you know the two camera positions for every point you now have two lines which it lies on in space. Just find the intersection point (or in reality the point halfway along the perpendicular between both lines). With two high quality cameras this should give good results. More cameras gives a more accurate point.

Could you try running this command in the public/art/textures/ui/session/icons/mappreview directory. mogrify -resize 512x512! *.png You will need to have imagemagick installed. With the ppa you will need to extract the files from the zip somehow which could be slightly messy with permissions. With svn it is easier but is a big download. This will check if it is non power of 2 textures messing things up.