Leaderboard

Toggle forcing silhouette to be displayed for all units, not only hidden ones. This would make judging who is alive and in which camp clearer under the dust of a battle.

According to unit roles (see http://wildfiregames.com/forum/index.php?showtopic=20103) here is how I think which class could counter which other, depending on the situation of course. Note that this takes running and charging in account for a future implementation (and not just damage/range/armor/cost). It will also vary a bit if some units have different strengths and weaknesses in different civilization, but the general counter should remain the same not to get lost (thus it would be more or less effective). In short (but with some exception) ranged > melee infantry Cavalry > ranged infantry Range with melee cover > cavalry Then we have short/medium/long range melee infantry (being individual, small group, pack figthers respectively) Short/medium/long range infantry (shorter = easier to cover but easily outranged) Light/heavy cavalry (mobility vs durability) Spearmen With medium range, they can fight in two rows, giving them more power when in tight formation. Generally, strength and durability is given when in formation but decreases their speed (thus more prone to hit'n run), less strength and durability when individual (thus more prone to melee fight) Counters: Swordmen when in formation, using outnumbering in fighting Cavalry but not that much Countered by: Swordmen when dispersed (losing their outnumbering effect) Ranged units by hit'n runnnig Elephant, just being crushed Pikemen With long range, they can fight even more than spearmen when in tight formation. The counter scheme is roughfly the same. Counters: Swordmen, spearmen when in formation, using outnumbering in fighting Cavalry Countered by: Swordmen and spearmen when dispersed Ranged units by hit'n running Elephant if not being carefull Swordmen With short melee range, they are the best individual fighters. Counters: Individual melee units Countered by: Cavalry Archers (see archers counter) Elephant Javelinists Short range hit'n run specialist Counters: Spear and pikemen, by forcing to disrupt, or even just killing them in place while hit'n running Javelin cavalry with their speed advantage not being useable (and being less cost/efficient) Elephant with target spreading Countered by: Light and heavy cavalry if uncovered (very short distance to run) Covered archers and slingers by not getting in range Archers Long range troop Counters: Disrupted infantry (be it spear and pikes not in tight formation or swordmen not in testudo) Countered by: Slingers if massed (outrange) Cavalry when uncovered (by reducing their range advantage) Siege, almost ineffective Slingers Long anti-mass troop Counters: Massed infantry Better against siege than archers, but not skirmishers (otherwise mini siege > siege) Early defenses before siege weapons Countered by: Cavalry when uncovered Heavy cavalry (read spear cav) Counters: Everything in one on one (except elephant), not that much for siege Countered by: A few pikemen, a bit more spearmen Javelin cavalry by hit'n running Elephant Skirmishers, archers, slingers (in that order) if they are well covered Light cavalry (read sword cavalry) Counters: Uncovered siege Ranged units if not well covered Can't be hit'n run by javelin cavalry Countered by: Spearmen, pikemen Skirmishers, archers, slingers (in that order) if they are well covered, but less than heavy cav Javelin cavalry Fast hit'n run troop, close to infantry javelinist except for cavalry. Counters: Spear and pikemen, by disrupting them, or even just killing in hit'n run Elephant with target spreading and hit'n run Countered by: Javelinist by being less cost/efficient Light cavalry if fighting it Archer cavalry Long range cavalry Counters: Everything that can't get in range (melee infantry, javelinists) Countered by: Everything that can get in range (archers, slingers, light cavalry, javelin cavalry) Almost ineffective against siege Elephant That mastodont Counters: All melee units (less for pikemen) Siege Countered by: Javelinists, javelin cavalry (good) Archers, archer cavalry (medium) Slingers (somehow)

Pics or it didn't happen

A tin can on a stick, with a wooden tv for a monitor.

1. I might look into that. 2. http://trac.wildfiregames.com/ticket/2679 I asked sanderd17 about this, and this is really complex 3. Just edit the template_turret and remove silhouette 4. I don't know much about that too, I guess it could be done.

If Tarentines are mercenary, then add them as mercenary. Median Cavalry can be their regular javelin cavalry.

Your latest patch work perfect as described! Only 4 more thing to make garrison point work perfect, in this order: 1. Selection ring must be at feet (or at prop coordinate, whichever) instead of on ground. 2. Unit garrison on top wall gate should not prevent passage of unit (or keep door open). Unit obstruction should be ignore. 3. Maybe remove silhouette for visiblegarrison units on parapet. 4. Select wall or fortress you see the visiblegarrison troop health bars too.

What would count as "proper" it is said (on Wikipedia and other sources) that the Seleucids used hellenistic merc cav. The Tarantine cavalry from Tarentum were famous cav mercs and where used by all greek and hellenistic factions sans the Ptolemaics. I think it would just diversify and hellinize the Seleucids more, instead of using an exact copy of a persian unit. While the Seleucids did use Median cav, Tarantine cav would make it more diverse.

I will get these to you tomorrow.

In this case though, everything has already been made on an artistic pov So it's 'just' XML editing. What you could do : Look at all the sele models in atlas, and tell me for each of them which armor, helmet, shields, and weapons should be used. e.g sele infantry : mace_archer_a helmet spart_infantry_melee_armor mace_hypapsit shield, spear ...

Gif are allowed too.

A direct copy of:http://en.tankiforum.com/index.php?showtopic=290667

what 1.1k light infantary looks like? lol

Meanwhile In the dev version...

Some probably know Jenkins already. It's an Open Source tool for automated building and testing. The idea is to notice bugs as soon as possible after they are introduced. Let's compare this situation with and without Jenkins to show what I mean (not using Bob and Alice as names for once): Situation: Yves breaks a test only in debug builds Currently (without Jenkins): Yves has tested his change in the game and he has launched the tests in release mode. Everything works as expected and he commits. Two weeks later there's a forum post about a strange problem with the tests. Leper and Sander both can't reproduce it in their first try. On their systems the tests work well. After a few questions in the forum they figure out it only happens in debug builds and after an hour of collaborative analysis they find and fix the problem. Unfortunately some other commits were based on this change during the last two weeks and more changes need to be done. Future (with Jenkins): Yves has tested his change in the game and he has launched the tests in release mode. Everything works as expected and he commit. Jenkins does some automated building and testing with various configurations. One hour later, Yves gets a mail from Jenkins informing him that the tests don't work in debug mode. Yves has worked on the change just an hour ago and everything is still fresh in mind and he can solve the problem quickly because he already knows where to search for it. That's an optimal case but there are a lot of situations where automated testing can be useful. Just think about how often someone broke a test in the past which caused a lot of unnecessary noise on IRC when this person could just have fixed it an hour after breaking it and nobody would have noticed. I you have some time I recommend watching this video, it explains the topic quite well in my optinion (the general part in the beginning at least): I also recommend this short and general overview of what continuous integration means: I have started experimenting a bit with Jenkins and figuring out what can be done and what could be useful for us. Here's what I have so far: Basic building and testing procedure: Jenkins checks for new svn revisions every 10 minutes. It uses svn update for the checkout instead of doing a fresh checkout everytime. Runs update-workspaces.sh with the newly introduced option "--jenkins-tests" Runs make Runs our test executable and redirects the output to an xml file. Fixes a little incompatibility with the XML schema with sed and then uses the generated XML to display the results of the testsThese steps get exectued for both debug and release configurations. Jenkins has a web GUI which displays and visualizes all kinds of useful information. Unfortunately I don't have a DMZ setup at home, so I don't want to make the server accessible to the internet. But I've made some screenshots to give you an impression of how it looks: This is the overview showing a trend (currently a dark cloud because many builds failed while I was testing). On the bottom left corner you see build with two different configurations (debug and release) running. Here you see the tests listed. They all passed in this run. There are also nice graphs showing a history of the tests either for all tests or individual tests. Of course the graph is not very interesting with only two builds and 100% tests passed in both builds: There's also a build history showing when which tests succeeded or failed: Last but not least, Jenkins keeps track of commits and automatically adds people who do the commits to its configuration. We could assign email addresses to people and send mails if one of their commits doesn't pass a build or a test (I heard you can do that, but I haven't tested it yet). I'll continue improving my Jenkins setup to figure out what can be done and what's useful for us. At some point we should probably think about configuring a Jenkins server which is accessible through the internet. At the moment this would be too early IMO. I know that Philip already has a sever, but as far as I know he only uses it for building and hasn't integrated tests or anything like that.