vladislavbelov

Also the good link: https://trac.wildfiregames.com/wiki/Manual_SettingUpAGame at Setting up your network.

Also it'd may help to get more readable error: https://trac.wildfiregames.com/wiki/DebuggingOnWindows .

There is a side effect of your way: you have 200 wood, you want to build a house, select it and try to place, suddenly you can't build it, because you have only 50 wood, and you think: "Who stole my wood?". But it's not a stealing, just some building spent this wood on a queued unit. Another example, when you've been attacked in one place, you need create many units there, but all resources are spending in other CC, so you need to click over all buildings and cancel queues. Also there is a problem with priorities, because every situation has an own priorities, which unit should be created first. And in case when buildings spend resources when needed, it may happen that units with low priorities will be created before units with high priorities. So this way will be a complex task. So I'd prefer the current way or combined (suggested by @civilis), because it allows to control the resource flow with big precision.

Probably, the problem with "monopoly mode", it's a checkbox inside sound device settings, try to turn on/off.

Has he any connected audio device (headphones, loudspeakers)?

The first link is unreachable (https://wildfiregames.com/forum/index.php?/topic/18265-terrain-flattening/). I agree with @FeXoR: current version has the balanced solution.

There're few issues with the water: not clean reflections, shifts of reflection (the issue above), not so realistic refraction's colors.

There is a campaign ticket with a WIP patch: #4387. So I hope that it will be finished to A22. About "V": the very interesting letter...

I mean the way where no variations, only animations: It's for the prop, not for unit.

Have you tried the last one way?

There is frequence="1" again, but in the animation. Also "it will save the name for the props", probably you need to do this for unit: <variant frequence="1" name="Walk"> <animations> <animation file="infantry/general/walk1.psa" frequency="1" name="walk1" speed="250"/> <animation file="infantry/general/walk2.psa" frequency="1" name="walk2" speed="250"/> </animations> </variant> And for prop: <variant frequence="1" name="walk1"> <animations> <animation file="infantry/general/walk1.psa" frequency="1" name="walk1" speed="250"/> </animations> </variant> <variant frequence="1" name="walk2"> <animations> <animation file="infantry/general/walk2.psa" frequency="1" name="walk2" speed="250"/> </animations> </variant> Or even without variations: <animations> <animation file="infantry/general/walk1.psa" name="walk1" speed="250"/> <animation file="infantry/general/walk2.psa" name="walk2" speed="250"/> </animations> I'm not sure, I'm searching in the source.

I'm not sure that it's possible yet: sync different actors for animation with the same name and file, especially if actors described in different files.

So the unit and the prop are different actor with different animation files?

if I'm not mistaken they shouldn't be synced (because name just for an animation control), probably it should be synced in that way: <variant frequency="1" name="Base"> <animations> <animation file="units/death1.psa" name="Death" speed="50"/> </animations> <mesh>skeletal/horse.pmd</mesh> <props> <prop actor="props/units/blood1.xml" attachpoint="root"/> </props> </variant> <variant frequency="1" name="Base"> <animations> <animation file="units/death2.psa" name="Death" speed="50"/> </animations> <mesh>skeletal/horse.pmd</mesh> <props> <prop actor="props/units/blood2.xml" attachpoint="root"/> </props> </variant> ...

Shouldn't frequency="1" be there in the <group><variant frequency="1" name="Death">...</group>?

Probably yes, I didn't mean something specific, just some test tool. Because pvp matches or manual checking-s are very subjective, we could notice only very visible bugs.

AIs were only as example, I usually test (not 0AD) a balance with python scripts: generate all permutations of possible sides, simulate (very naive) and search some easy situations. Probably for the balance of the 0AD we could use something like this or whatever else.

Any tools which could check the balance (i.e. play non-visual 1000x matches between AIs)?

Interesting way (Taxation of ancient Greece), we could use a slider for balance between war buildings and economic buildings. And like it was in Greece: when a war with someone was started, you move the slider to war and usual building and units costs more, but war units cost less and faster to be produced.

Probably use one type of fields, but with different states (different models). F.e. it's fertile field, after N cycles the land will less fertile and less amount of food per gather. So need to build a field in other place (like real farm).

There is a ticket: http://trac.wildfiregames.com/ticket/4078, it provides to setup match settings to all AI.

The very interesting implementing of 0AD buildings, there is the question: why buildings have different angle? Ins't it worse for perfectionists?

Supporting of OpenGL3+ is a good idea, and I think it would be good to have separated (possibility to switch) renderers (2 - why we have arb shaders, 3.1, 4+, probably vulkan). Disabling of sky isn't good idea, because sky and reflections should use the same texture, and it doesn't really save time, instead f.e. lods, async ocqueries, geomips and many other things, that we haven't implemented yet. I think no need to move shaders, because shaders are moddable, so user shouldn't go to engine to change them. Deferred shading doesn't actually do what you said to wraitii about batching (he means something else), it saves time for fragment processing (it's something in other way), but not vertex. Batching and instancing saves cpu time (because no need to change states so often) and gpu time (no need to change cache so often to calc vertices). But yes, deferred shading is the good technique, and we need it, but there are few things: we need to store the g-buffer as small as possible (components packing), more number of textures to rendering. Dirs 'graphics' and 'renderer' don't do the same thing, 'graphics' is mostly preprocessing, and 'renderer' is actually rendering. UPD. FBOs, it's not actually true, because we don't need to switch between all FBO textures, why? Because we switch to FBO only when need to render to that, but we could use this textures without a FBO binding. So mostly it isn't expensive, but really we don't need so many FBOs.

I think, he means not browser version, but usual lobby match, and players can control units (as usually), terrain/environment too. It's not so hard as a browser port.

As I said to elexis, I have the unstable Atlas patch, which adds functions to control this camera paths, so I hope that it will be added to the next release, and we will make a movie