sanderd17

Mish, you're making the page a bit heavvy now. Can't you upload the file instead? The formatting scripts gets interrupted here.

As you can have hundreds of moving units at once (say 300 for both players combined), and a pathfinding calculation can easily take up 20ms (rough estimate). If you want to recalculate the path every half second of game time. Your half second would have a 6 seconds lag. You'd only be able to move 10 units more or less fluently with this. So I don't think this is a viable approach. Instead, we work with a long and a short range pathfinder. The long range calculates the general path. Only taking account of more-or-less static obstructions (a building can always be demolished by the time you pass there, but there's a big chance the obstruction won't have changed). Then we have a short range pathfinder that takes account of the moving obstacles too, and just routes you to the nearest point it gets from the long range pathfinder. Again this is a fixed path, but over a short distance. So even moving units aren't expected to move a lot. If it hits an obstacle, a new path is calculated though. The two pathfinders solution is also a drawback though. The long range pathfinder has to be faster, as it needs to calculate long paths (possibly to the other side of the map). So it's tile based, with quite big tiles. Every tile is marked as passable or not-passable. And it finds it way like that. But that also means the pathfinder doesn't take the obstruction size of the unit it wants to move into account. So sometimes, a tile is marked as passable, but a unit (like a siege ram or ship) can't get there because it's too big. As the short-range pathfinder is ultra precise (doesn't have a grid, and compares and huge amount of possible paths). The short range pathfinder notices the unit doesn't fit through that gap. So the path it calculates becomes a very long path, around that big obstruction. Sometimes so long that the short range pathfinder just gives up (to not cause even more lag), and the units stop. There are solutions to that, by letting both pathfinders use the same grid (more precise than the current long range pathfinder), and they do the compatible passability checks. The short range pathfinder should still be the only one to mind about moving obstructions. It should also be made in a way that units "communicate". I.e. friendly units should let each other pass by going out of the way. As such, the short range pathfinder shouldn't get stuck again. You can always read this pdf to have a more precise overview of our plans for the pathfinder: http://trac.wildfiregames.com/export/15216/ps/trunk/docs/pathfinder.pdf

We already release every few months. Small hotfixes aren't desirable. Certainly no balancing hotfixes, as that means everyone has to download and install the game again. Maybe when we only install pyrogenesis, and see 0 A.D. as one of the mods, and pyrogenesis has a good mod manager to download and install new compatible mods, we might uncouple the two releases. But this won't happen soon.

I don't know the actual details. But we use a texture to decide which parts of the maps are visible, and which aren't. Apparently, that texture gets clipped to fit the map, but something went wrong with that, so the visible regions end up in the wrong part of the map.

Some versions ago, tower pushing was a very good tactic. It could only be prevented with a rush. As you see, balancing changes every version.

From the start to the end. The visible terrain doesn't follow the units. Philip thinks the masking texture got stretched and skewed because it's not nicely clipped. See the logs from 10:20 onwards: http://irclogs.wildfiregames.com/2014-05-24-QuakeNet-%230ad-dev.log

Thanks for the fast replies. I'll ask Philip what he thinks of this.

It's technically possible, as it doesn't interfere with the simulation, so you'll still have compatible games. Maybe just replace icu with some dummy headers?

The issue is more serious than that, look at the video. Thanks for dropping by. Meanwhile Philip thinks he found the issue, and it's most likely related to a bug in your video driver. So we'd like some info from it. Can you get your system_info.txt and mainlog.html for us? See http://trac.wildfiregames.com/wiki/GameDataPaths on where to find them. We'd also like if your recording software might influence your video card's behaviour. So can you test if this happens without recording, and tell us what software you use to record. Also, is this always reproducible (does it happen on all maps)? Thanks a lot.

That's something planned for the future, but got hold up a bit due to conflicting design choices.

Corrals are supposed to give a steady food income. You should be able to corral sheep (and other animals) in them, and those animals would give you a certain amount of food per minute.

Thank mimo for it. I wouldn't have implemented it.

Your wishes have been heard: http://trac.wildfiregames.com/changeset/15211 Especially for the players who want to trade 100% of one resource.

Those tags are just hints. Here it means that it's the specific name. Which normally means the name written as they'd locally write it. But for some names, it's also a transliteration (like we don't have Egypt hieroglyphs or Punic symbols), sometime we don't even know how they pronounced it (like for the Celts), so Celts mostly get Latinised named, and it's also possible it's just a specification of a general name (like "Oak" instead of "Tree"). These elements are not important for gameplay (we always refer to the generic name, never use the specific one), but they should be consistent in your language. So it's up to you, or to discuss with your language team.

I most likely won't actually code stuff, but you can always ask me specific help, and I'm also trying to get the public mod more moddable. That was hard when there were no mods around. leper starts with a lower case l, not an upper case i. I had to read twice too, especially because there's a town called Ieper very close to me (written as Ypres in English).Where do you find them? They normally find you. Just be open, try to make good code, and others will probably drop by and contribute a line. After that, it's a matter of making them contribute more than their first line.

Very nice to see this release. Hope you'll enjoy the code changes made in svn so far.

It still doesn't work if you want a split share. Like 25% of each. It was very hard to hunt your traders to achieve this.

It's in the modding forum. The main game probably won't add any new resources, but modders can do whatever they want.

Cav used to be pretty bad in older releases. But we worked on the chasing bug (in older versions, moving units could never be attacked, no matter how slow they were). So in A16, the movement speed has become quite important. While cav still has their good other stats that were given in other versions to make them worth something.

We've got quite some complaints from good players about A16. They say the only viable tactic is a cavalry rush. So I wonder how this matches with your view.

Ooh this math hurts. Take 1, subtract 25%, you're at 0.75. Subtract 25% again and you're at 0.56. The elite is 50% less effective than basic. Period. For completeness, I think it's good to produce some infantry at the start of the game for gathering. So you can fend off a rush (or at least have a chance), but after researching the promotion techs, you probably shouldn't gather with them anymore.

I said that the graph would be the most difficult thing. You'll have to add a new sort gui object, a graph, that accepts coordinate pairs and draws lines. That new object would have to be defined in c++. For the OnUpdate message, just create a method in the statTracker's prototype with that name. Methods starting with On are always recognised as message handlers by the Engine. And the IID_interface comes from components/interfaces. Registering an interface creates that global.

A wonder by a hill would require a new passclass. While they are quite limited already (currently there's a limit of some 8 passclasses IIRC). And we use one for ships, units, unrestricted, buildings, and docks. And I'd like to use some different ones for other animals like swamp animals. And the worst thing of it all: more passability classes will make the pathfinder slower. So I don't think it's a good idea to require it to be build against a hill.

You can always read the actual templates. Typical Females: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/templates/template_unit_support_female_citizen.xml#L59 Typical Males: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/templates/template_unit_infantry.xml#L65 But it becomes worse when they upgrade. See the Athen Elite Archer: http://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/templates/units/athen_infantry_archer_e.xml#L22 It's baseSpeed is reduced to 0.5. Which means it gathers resources only half as fast as the basic infantry unit. The actual stats might differ a bit per civ, but this will be the general trend.

I don't think you can add Object tags on the fly. You can edit their size on the fly though. Not sure what you want with the tracker. You can listen to the OnUpdate message to get executed every tick. But that would cause huge objects (those objects are also send to the lobby server when a game is finished). I think listening to the separate actions, and getting the time from the Timer component would help. And what constants do you mean? Do you have a code example of where they are used?