sanderd17

The animations should start from the default stand pose, and end with it. But apart from that, it may be quite simple. How long it should be, depends on your feeling. We can easily stretch or shorten an animation (though that also stretches and shortens the first part of the animation). For how animations work: animals (and other units) have different states (roam, feed/idle, attack, flee, ...) for each state, we can define a different set of animations, and play a sound (currently a single sound, but looping sounds should also be possible in the future. So we can play a sound when we switch to attack mode, but we can's play a sound when we switch between two idle variations f.e. As not all idle animations are expected to have the same sound (you can't play the howling sound when the wolf is sleeping), we can't play any sounds. All the other animations will work. They're all states. The attack animation are a bit more difficult, as the engine expects that the attack happens while standing still. So the animation needs to return to its original position. You can take a look at the tiger animation thread, I believe the wolf animation could be a bit the same (if the wolf has the same bones, you don't even need to make an animation for it, the animation can be reused).

Hmmm, we can add sounds to a type of animation (like adding a sound to the attack animation), but we can't add sounds to a variation of the type (like one of the idle animations), that could cause a problem for the howling. It's still nice to get it in though, but it probably won't be very nice in game. Also, I'd like some very still idle animations (like something sleeping). Predators are normally very still (except when they're hunting), and too many repeated animations make it look silly. But those are mainly game-concerns. I really love the animations you made.

Oh right, nice bonus. I'll make it technology modifiable right away. We can have range-based bonuses now, but they're on-off bonuses. Not something like more bonus for closer entities. Because to would just be too difficult to constantly check those ranges and send messages around everywhere. That said, I'd more prefer just de-bonusing farms near the CC, just for the sake of simplicity.

Please be careful with the simulation2 rename. I don't want to lose the entire SVN history of simulation2 (like happened once with Aegis).

If you want comments by other players, an animated image is better. To get it in game, you need to give the .blend file.

I don't think the design committee wants unlimited resources. Though a mine building could still give a longer lifetime for your mines (double the resources or something).

Or, we could keep the farming as is (you can't starve cities in real life if they still have enough farming ground either), but fix the market "regenerating" resources too fast. Currently, if you buy something, the price of the thing you bought rises, while the price of the thing you sold drops, as it should be. But if you wait a few seconds, it's back to the original price, which is way too fast. And I even wonder if it ever should restore prices, instead of just depending on the global market.

The obstructions can be less, but it cause bigger obstructions sizes (or nothing). You can try it with the fence. If you enable the pathfinder overlay in Atlas, you can place a fence so it makes no single tile "unpassable". If you place a row fences like this, you'll see strange results. The long range pathfinder will think everything is passable, and will just path your units through the fences, but when you come close, the short range pathfinder kicks in (which is more precise), and finds no short path through or around it. This results in the long-range pathfinder kicking in, and returning the same path (as there are no obstructions as far as it can see). This goes into a few loops, until the pathfinders finally give up. Now, with fences placeable in Atlas, the map designer has some power over it. He can make sure it marks some tiles as "unpassable", or he can make sure the row of fences isn't too long (so the short range one finds a way around it). But when you allow these types of objects as buildable in game, certainly when they're used because of their obstruction, it can cause real problems. The same with gates. If the gap of the gate is too small, the sides could trigger two adjacent tiles to be marked as unpassable. That would make it impossible to open the gate decently. For the resolution of the height map, a tile is a 4x4 square when projected along the (upward - in this game) y axis. It's a grid, where every point can be given a different y coordinate. So no, you can't have terrains going straight up. As for changing the resolution to 1x1, that shouldn't be too hard to do if the code is made a bit decently, but you have to think about the pathfinder implications again. Currently, a Tiny map is 128 patches (a patch is something like 8x8 tiles), and a Giant map is 512 patches. So setting the tile size to 1x1 instead of 4x4 would make the pathfinder on Tiny maps just as slow as it is now on Giant maps, and I don't want to imagine what it would lag it would cause on new Giant maps. It's understandable, as for most operations, it will have to check 16x as many tiles to create a path. That being said, Philip is working on a new pathfinder, the main purpose of his work is to give the long and the short range pathfinder the same behaviour (so you don't get that strange fence issue). To do that, he has to work with a more precise grid of 1x1, so in that case, smaller obstructions, more precise heightmaps, and all those things could work.

You can try it yourself: http://trac.wildfiregames.com/ticket/2264 In that ticket, it's used to create celtic slope walls (making the terrain higher after the wall). But there are several problems with using it for walkable walls. First, the terrain rendering is also bound to the heightmap. Secondly, the height map is very imprecise, one tile is 4x4m. So the terrain would stick though parts of the wall, unless it's massively thick. Even for those slope walls (which only need one unwalkable side), I had to make them twice as thick as the regular walls. For general walls, that would mean they should be something like 6x as wide as currently, to have a walkable part, and to hide the steep edges with models. For water bridges, this could be viable, as the edges are already hidden a bit by the water.

Interesting, that tech affects all units, and even buildings. I investigated the code, first take a look at the technology definition. You see that there is no general "affects" part, as in most other technologies (f.e. the first infantry hack armour tech). But there are affects per modification. Now, in the code, these two affects get combined. The combination looks like [ [ ], ["Champion", "Melee"] ]. To check if the technology applies, it loops over the sub arrays, and checks if the entity has all classes of those sub array. So you could read it as "nothing OR ("Champion" AND "Melee")". Here, the "nothing" means that there is nothing required, so everything entity is affected. Now, I don't know who's wrong. If the "affects" per modification is supposed to further refine the general "affects", then the code is wrong. But if the "affects" is supposed to work as an "OR" combination (and thus generalise the original "affects"), the code is right, but the template is wrong. In that case, the template should have set a general "affects" to "Champion Melee Ranged". I can see both cases wanted. So before changing it, we need to find out if a change won't break other technologies. Thanks for reporting this.

We can't document which hero or upgrade to chose. As we're constantly looking to balance it. That means, you should be able to win with any hero or technology chosen, but every choice you make has implications on your play style, and if you know the play style of your opponent, you should also make the choices according to that. But, because it's constantly being rebalanced, we cant give those answers, as they will be totally different in two weeks. One thing though, heros aren't used a lot currently. They do have auras, but their auras are generally a bit weak (certainly not stronger than a single technology, while they're a lot more expensive, and can be killed). I think, in the future, those auras will be made stronger, but until then heros are still pretty much useless.

This is indeed a new bug (at least the part about the planes), I can see what caused it. I'll fix it tomorrow when I'm on my computer.

You do have to watch out a bit with the licenses. We use http://creativecommons.org/licenses/by-sa/3.0/ , that explicitly allows commercial usage, but also requires re-distribution under the same license. So you can use the music from that composer you found. But you'll need to distribute is a bit separated, or at least with decent license explanation. It also means that people making game videos for Youtube add revenue are in a bit of trouble. As they could do it with the CC-BY-SA licensed music, but the music from the composer you found can't be included. So it is possible to stay legal with both licenses, but it will be hard to do it right.

The problemen with garrisoning in A15 is the loading range. Elephants are bigger than units, so need a bigger loading range. This should be fixed in SVN though.

He, I only see this message now, meanwhile I answered your message, and fixed the problem. Thanks for reporting. (that's what happens when you rename loads of stuff).

Newcivs, this isn't a random map bug, your computer is just too slow to handle it (and most regular computers will be too slow).

Maybe it's worth editing the wiki in that case

Time to get formation fighting working I do agree with you, I prefer unit sounds being played a lot to create a battle sound, rather than playing battle loops. The battle loops must always depend on some software detection system, which will be slow. But with unit sounds, the moment the last arrow is fired is the moment you'll hear the last arrow. One thing I'd like as a start is a frequency system in the sound selection, like in the actor variations.

I thought it would be nice without a roof, just because the building is unique, and thus needs to be easy recognisable. Showing the donkeys in all angles, together with the mill stones, would make it as recognisable as it can get I think. This is just my opinion though, I really don't have anything to say on art matters.

The topic makes me feel like http://xkcd.com/272 From the time when I used Norton, it was worse than a virus in many ways. Much harder to uninstall too.

Or you can keep it to 1000 A.D. (that way, you'll appear on the top of every game list, right after 0 A.D. )

You can take a look at the wiki for modding: http://trac.wildfiregames.com/wiki (there's a separate section "for modders"). Almost everything should be moddable, and once you found the base directory, it should be pritty logical that the sounds are in "audio" for example. And the definition of which sound is used by which unit is in "simulation/templates" The lobby is in full development (like the rest of the game), such a friends list could be handy indeed, but there's a ton of other things we need to do too. Relics aren't really planned. But there are other ways of getting bonuses (like creating certain heros, or building certain special buildings).

You can reconnect to multiplayer games started via the IP method. And it should also be possible for lobby games, but you'd have to know the IP of the host (which isn't evident). Though you're right it should be more simple.

I didn't change it, Mythos_Ruler did.

I don't know where you heard that, but melee infantry units also add to the number of arrows. Though I agree, it should be shown a bit nicer in the GUI