Leaderboard

@sanderd17 Thanks! Didn't know the tools where this developped already (since 0 A.D. is still in alpha). Don't mind that the models are not very detailed and the animations not realistic enough. Don't really care about graphics. Use to play games with much less detailed graphics than this.

http://trac.wildfiregames.com/ticket/1983 Felt like doing a quick one. Based on this image for shape and texture: http://en.wikipedia.org/wiki/File:Alectoris-chukar-001.jpg partridge.zip

http://trac.wildfiregames.com/ticket/1976 Working on the croc. Still plenty left to do. Legs are a bit tricky.

?!?!? aldifuhaoidhcfaoidjf Who thinks of a giant outdoor fire chimney as a concept for a blacksmith? If 0 A.D. were about depicting buildings by concept than what they are actually shown historically correct; than why not draw a big anvil and hammer the size of a building itself? Players can easily learn to identify a blacksmith in the game without the big fire chimney. If you had paid attention to the past threads discussing about how a structure should look like, than look in the Art Development sub-forum about the Mauryan structures. Look in this thread about the Mauryan Defense Tower and see eleven pages of discussion about how every little arch should look like, and whether something should be wooden or stone. http://www.wildfireg...showtopic=16696 If that thread doesn't convince you that 0 A.D. depicts buildings historically correct, there are five or six more threads that talk about Mauryan architecture and props. @Enrique: I will try to find pictures and articles for you. I know people used pottery in order to create shapes with metal. EDIT: I wouldn't trust this source of information, but it is interesting to read. http://www.jaysromanhistory.com/romeweb/glossary/timeln/t10.htm

I don't know if this helps, but maybe it does: Arkive is a site about animals, you can search a species and it has some videos about this species. For example, you search Forest elephant, you'll find this: http://www.arkive.org/forest-elephant/loxodonta-cyclotis/video-06a.html A elephant running. Again, no idea if it helps, but I thought it could.

I do not believe that who ever has the resources win. I believe that more resources helps you win. I also do not like the idea of tier 5 units, because that means the tier 5 unit can kill off multiple enemies attacking at the same time and that seems silly.

Blacksmith concepts for romans and Iberians (Iberian one is based on it's current barracks, barracks model will be redone)

Should be fixed in r13489, please test!

I don't see what translation necessarily has to do with modders, unless they also want to be translators, but those are two separate groups with different needs. The way I see it, the only people who should care about translations are: 1) Non-English players who need them 2) People who actually translate the game 3) Programmers who implement the translation system Frankly, group (1) won't care in the least how it's implemented, as long as it works. Group (2) will care, and we have several of them saying we should use a standard system, and they are providing links to communities and tools built around such systems. Group (3) will do whatever needs to be done, so I think the focus shouldn't be on what's simplest to program today, but what makes translation work as well as possible now and in the future. If I'm understanding the concept correctly, we will have in either case a tool that extracts translatable strings from the game data (XML, JS, whatever) and creates .po or .txt files. So the average modder need not know anything about translations, they will write their mod following the conventions of 0 A.D. wrt/ translation support, and then whoever from group (2) does the translating will use the same process as those translating on the game proper. As far as I'm concerned, the average modder shouldn't care or need to care much about the process of translation (unless they are also a translator, in which case they approach it from that p.o.v rather than modding) We're not a proprietary project. And on the contrary, my experience with 0 A.D. is that the clever solutions programmers came up with over the years, to avoid using existing 3rd party libraries and obvious solutions, tend to become very complicated over time and are now the most fragile parts of the engine, because nobody in a few hours of work can foresee all the issues of a complex system that others have encountered over potentially decades of development, and they're no longer around to maintain that fragile code. From a simplicity perspective, if you look at the patch on http://trac.wildfiregames.com/ticket/67, that solution doesn't look particularly more complicated than yours, most of the patch is source for the tinygettext lib, so we're using other people's work there instead of our own, while the changes to the engine itself for GUI XML support are trivial. Can you explain why that approach would be noticeably less efficient than yours, as I understand it's only a matter of loading the .po's into a dictionary instead of .txts? We can benefit from compiling the .po's into binary .mo's for faster loading, if necessary (in fact my suggestion would be that we integrate that into the archive builder and preconvert them for releases, like we already do with XML, DAEs, and PNGs). (Of course we can't have a fair comparison until both approaches are working with the same data, GUI pages will be messier to translate in any case than entity templates, and we don't yet know how the approach of #67 will extend to entity templates) Can you elaborate on our needs that gettext doesn't meet but that your solution does? Nothing hand wavy like "it's easier for modding" without evidence that modders should be constrained by our choice of translation system. So far the argument is sounding like we need to justify using the proposed arbitrary .txt format and get around its shortcomings, and create another tool to convert between .po and .txt to work with everything that's already compatible with gettext, which is a very strange angle to approach this from. ...which historians are we speaking for? If you're saying non-programmers don't want to edit XML files, I fully agree, that's why we should have a GUI-based entity editor for Atlas. That is certainly worth putting effort into and part of having an easily moddable game. Currently an entity editor really only needs to be an XML parser with a GUI generated from the schema, anyone could write that and someone should, it becomes more complicated if the actual text data of the entity is replaced by a key into a proprietary .txt file that needs a custom parser and dictionary. For the historians, finding the correct entity to change would be no more difficult than searching by plain English keywords, kinda the way the object panel of Atlas works now. But there's always the simplest non-technical solution: we could have the historians create a Trac ticket with their suggested changes, which a developer commits in the appropriate file. Or they could ask which file to modify and how to do so, I think if they did this once, it wouldn't need explaining twice, it's not exactly rocket science to figure out the entity template naming conventions and as you say, Notepad++ is more than up to the task (if they make a mistake, that's why we have SVN/git) Any evidence that text loading and storage is a performance bottle neck in 0 A.D.? Honestly, I would be delighted if that was the case, it would mean we squashed all the other more serious one. What about evidence that using a gettext-based solution will be noticeably slower than yours? (As I've said before in discussion of the GUI system, I get like 800+ fps on the main menu, so there's clearly some wiggle room there, and I haven't seen any evidence that game lag is caused by text display/rendering/storage)

Warcraft 2, StarCraft, Warcraft 3, StarCraft 2 But I'm over Blizzard games because they insist on making them online-only.

Flamadeck: Then it seams I got that wrong, apologize and am glad to here we'r on the same track

Really nice model. I hope you like the texture: Source: http://commons.wikimedia.org/wiki/File:Panthera_tigris_tigris.jpg

Fixed the texture. darn hard to find good photos for the wing from above. http://www.flickr.co...shi/6580254701/ http://www.flickr.co...shi/5488404797/ Edit: Aw crap. He had NC on those photos. Edit2: I sent him an email asking if he would consider dropping NC on those two photos.

The new Mozilla's JS engine, IonMonkey, brought a lot of performance improvements, and it only landed in Firefox 18. So most probably v22 would be a lot faster than v17. But, if you could use v24 it would be even better, as the performance is improving from release to release, and v24 contains also OdinMonkey (asm.js) that you could use in some cases (for example for the AI, instead of moving code to C++, you could use asm.js so that the code would be a lot faster and there wouldn't be any performance penalty caused by JS-C++ calls).

I feel pretty satisfied with the model now. tiger.zip