Leaderboard

Yay, good news! Since the last post in this thread I've been working on integrating as many changes from the patch into svn as possible. When working on ticket #2241 I noticed that the changes there brought more or less the same performance problems the whole patch causes. I suspected the wrapping again and started to look for alternatives. In a discussion on #jsapi, Boris (bz) suggested using the module pattern to achieve a similar separation we currently get by using different global objects. That was more or less just a keyword for me in the beginning, but after some experimenting I got it working in ticket #2322. Today I've combined all parts of the puzzle and made the measurements. The results are exactly as I hoped and (kind of) expected! I've measured four different versions. The unmodified svn version at revision r14386 The patch from ticket 2241 applied to r14386 The patch from ticket 2322 applied to r14386 The patches from ticket 2241 and 2322 combined. Also based on r14386.All these versions use SpiderMonkey 1.8.5. It's a non-visual replay on the map Oasis 04 with 4 aegis bots. It runs about 15'000 simulation turns and (most importantly) all four replays ended with the same simulation state hash. What you can see on this graph: The second measurement (2241) suffers from significant performance problems due to the wrapping.The patch that moves the AI to one global (2322) doesn't change much compared to the unmodified SVN version. This is expected because our current SVN version can use multiple global in one compartment to avoid wrapping overhead. The theoretical benefits from loading the scripts only once and analyzing them more efficiently with the JIT compiler aren't significant. I expect this to be more important for the new SpiderMonkey version because its JIT compiler is more heavy-weight. On the other hand the JIT compiler is still designed to cause little overhead, so it's probably still not significant.When both patches are combined, we can avoid wrapping overhead and achieve about the same result as our current SVN version.Because my measurements for the new SpiderMonkey also contained this wrapping overhead, it's now quite open again what performance benefits it will bring. Well, we can say that it won't make much of a difference in the first 4000 turns or so, but that's where it only starts getting interesting!

Stanislas I think your best bet is to start again from scratch. Don't take the reference image too literally. Try to make a visually interesting structure while staying within the limits of the building template. This building is very much a barracks, perhaps too rigid and "predictable" try to suprise the audience Please don't take this the wrong way, starting over is much more fun than constantly editing a building that in all likelyhood won't work as well as it could. maybe sketch out some different variations and show us, so we can spot any problems before you've put time into a model

An updated version of this guide is available on the Wiki. Introduction This is a guide covering how to export and set up animation files from Blender3D into 0AD as well as some tips and general guidelines for get the animations working in 0AD. The Blender3D version used for this guide is 2.65a newer versions might have problems with the Collada exporter. Last blender version (2.69) works fine for exporting animations. Animations have three main requeriments in order to get them working in 0AD. These are: 1.- The file with the mesh and armature (COLLADA file) 2.- The file(s) with the different animations of the armature (COLLADA file(s)) 3.- The file XML defining the armature (called skeleton in 0AD) with its bones names and hierarchy. The last step is to specify the animations that the unit will have available on its different states in the XML actor file of the unit (i.e. Walk, run, death, idle...) Rig setup: When setting up the rig to animate your mesh, there are a lot of options to configure it to make the animator's life easier and achieve good results with less effort. Sadly, there are some limitations in how much animation and skeleton data the COLLADA format can export. Here are some points to keep in mind when configuring your rig to make animations for 0AD: -Avoid disabling "inherit rotation" in bones. While it's a very nice blender feature, when exporting your animation the bones that have their inherit rotation checkbox disabled end up inheriting their parent's rotation, plus the extra rotation you add in the animation resulting in weird and undesired behaviours. There's a tricky workaround for this, which is creating a helper bone which the bone that you don't want to rotate will copy its rotation. -Make sure the rig have the correct scale, and has its scale applied before start animating. Resizing your rig and/or mesh and applying its new scale before baking the animation may end up messing the animations you may already have, specially if you have any IK (Inverse Kinematics) setup in your rig. Here's a workaround that may or may not work: -Scale to the correct size the mesh+armature file and re-export it. -Export the baked animation(s) to dae with their incorrect size, but correct animation. -Import them back into blender, scale them correctly, and export them back without applying the scale one by one. -Mark the "Clear Constraints" checkbox when baking an action if you use any IK or constraint. Specially if you use constraints like "copy rotation" and "copy location". Once the action is baked without "Clear Constraints", it may appear in blender that it worked fine, but it will not when exported to collada format. -Save your .blend file before exporting. You will lose your rig constraints when baking the animation, plus importing collada animation files back to blender is not working propperly to date (11/24/2013). Because of this, if you want to tweak an animation, or use the same skeleton/rig to create a new one, the only way to do it right now is using the .blend file. In this guilde, we're going to set up the animations for a wild animal unit "Tiger" that will be controlled by the IA "Gaia". 1.- Export the .DAE file with the armature In this step, we're going to use Blender3D to create the first main file needed for the unit's animation. This file tells the engine the relationship between the bones and the mesh. Before this step, you should create in Blender3D the armature (skeleton from now on), and the mesh that is going to use it, apply the skeleton to the mesh and tweak the vertex wheights that each bone will move (this is not covered in this tutorial). Before exporting the mesh and the armature, you should make sure that both objects are centered in the origin point of the scene and both object's origin points locations match. To move the object's origin points to the scene origin point (coordinates 0,0,0) first use "SHIFT+C" this will make your 3D cursor to center into the scene origin, then select the mesh and the skeleton with rightclick and shift rightclick and use "CTRL+ALT+SHIFT+C", in the pop-up menu select "Origin to 3D cursor". Now make sure you remove from the "action editor" any action currently used by the skeleton (if any) and move the timeline back to the first frame if it isn't there. [1b – Optional image removing the action editor's action] Also make sure your skeleton is in the default pose (also called resting pose). To do this, select the skeleton, use "CTRL+TAB" to enter pose mode, hit "A" to select all bones and use "ALT+G", "ALT+R" and "ALT+S" to reset the bone's position, rotation and scale, this will put the armature in it's resting pose. Now we're ready to export the mesh and skeleton. Make sure there's nothing else in the blender scene other than the armature and mesh (remove lights, other meshes, helpers/empties...). In "Object Mode" select the mesh first with rightclick and then the armature with "shift+rightclick" (the order is important) then go to the menu in the top of the screen and use "File --> export -- > Collada (Default) (.dae)" Navigate to the folder where you want the file to be created, name the file and hit enter or click Export. *Note: These "mesh+armature" files are stored in \0AD\binaries\data\mods\public\art\meshes\skeletal\ 2.- Export the .DAE file animations In Blender3D, you have to use the "action editor" to create the different actions (or animations) that you want to export into 0AD to use them. These actions are usually: walk, run, idle, attack, and death, but you can make variations of each one or make more types of actions if desired. This tutorial do not cover how to animate in Blender3D but I'll give you links to animation tutorials and tips for the animations at the end of it. 2.1- Bake the action to keyframes In 3D animation software, you animate inserting keyframes or "posing" your skeleton along a timeline, and then the software computes the space between keyframes with intermediate poses which makes the movement motion. The closer one keyframed pose is to another, the quicker the motion will be from one pose to another, and the further the keyframed pose is to another, the slower the motion will be. To make an animation file readable for 0AD, you have to bake the action into keyframes in Blender. This is the process of creating a keyframe for each frame if a bone has changed its position from the previous frame. This is done automatically by Blender3D when baking the action. To bake an action into keyframes, first select the action to bake in the action editor, then adjust the "start frame" and "end frame" on the timeline to match the action length. After that, select the skeleton, enter in pose mode with "CTRL+TAB" and select all bones with "A". Once you have selected all bones, move the mouse cursor into the 3D viewport, hit "space" to bring the search option menu and type "bake action" then select "Bake Action" in the menu. A menu for the "Bake Action" option will emerge, uncheck "Only Selected" checkbox, !and check "Clear Constraints" checkbox (specially if you use IK and/or constraints) and click OK This will automatically insert keyframes between the poses you used to animate. 2.2- Export the animation .DAE file This is the same process as the first point. This will create the file containing the actual animation that will be played in 0AD's engine. Switch from pose mode to edit mode with "CTRL+TAB" select the mesh first with rightclick, then the armature with shift+rightclick, go to "File --> export -- > Collada (Default) (.dae)" Navigate to the folder where you want the file to be created, name the file and hit enter or click Export. *Note: These animation files are stored in \0AD\binaries\data\mods\public\art\animation\"unit type"\ **Note2!!: Units with different meshes but same skeletons can share these animation files and use it even if the animation files have been exported with different meshes. However, each unit needs to have its own "mesh+skeleton" .dae file that we have created in the first step. Repeat 2.1 and 2.2 for each animation of the unit and name them accordingly (i.e. tiger_walk, tiger_death, tiger_idle_01, etc...) 3.- Create the XML file defining the skeleton 0AD needs a .XML file to define the skeleton's name, bone hierarchy and bones' names. These skeleton .XML files are located in "\0AD\binaries\data\mods\public\art\skeletons\" You'll need one skeleton .XML file for each different skeleton you want to use in 0AD. The easiest way to set up one, is to open an existing file and modify it with the information of the new skeleton you want to add and save it as a new file. You can open .XML files with any text editor software. I recommend notepad++ to do so (personal preference). This is an example of the syntax that you need to use to setup the file correctly: Note how each child bone is defined under its parent bone line before closing the parent's bone definition with "</bone>" The RootBone is the bone in the armature that controls every other bone in it. Note: If you have any bone name in the skeleton containing a dot "." you have to use an underscore "_" in this file instead when writing the bone's name. To know the hierarchy of your skeleton, you can use the outliner window in Blender3D and expand the armature contents. There you can see which is your root bone, and the childs of each one of them. Once you have completed setting up the file, use "save as" and save the .xml file with an appropiate name in the folder specified at the beginning of this section. -Specifiying the animations for the unit in its actor Every unit (or entity) in 0AD has it's own .XML file which contains information that tells the engine different properties of that entity. These files are called actors. Some properties that contains these actor files are: -Mesh: the mesh that will be displayed in the engine for that entity or unit. -Prop(s): Actors can be used within other actors. They're called props. You need an empty/helper/bone with its name starting with "prop-" to specify where you want the actor to be shown. -Variants : These are possible variants of a unit (used for unit diversity) as well as states that a unit may have. -Texture(s): The texture or textures that the mesh will use. -Animation(s): Animations that the unit or entity can use and the variant/state associated with that animation. Animations in the actor files are normally specified just before the <mesh> tag in the following format: The <animation> tags in this example include the location and filename of the animation (created in section 2), the name of the variant/state that will use that animation specified by "name=", and the speed that the animation will play. The animation speed gives you control over the speed that the animation will play independiently of the speed it had when exported from Blender3D. Loading and hiding props during an animation: There's a special case for animations where you can load prop's actors and make them dissapear during the animation. The first animation specified in the example with the variant name "Build" uses this case. You specify with fractional numbers when the prop will show up with "load=" and when it will dissapear with "event=" during the animation. The number "0" means the start of the animation and "1" the end of it. The variants are normally specified after the textures in the actors. Here's the variant definition of "Build" from the previous example: In this example the actor "wood_1_a.xml" is going to be loaded at 25% of the duration of the build animation, and it will dissapear at 75%. You specify where the prop actor will be placed with "attachpoint=" . The attachpoint value needs to be the name of a bone, but it is mandatory that the bone name starts with "prop-". When you specify the prop-bone name you ommit the "prop-" part of the name, but if it's declared in a variant that is going to use "load=" and "event=" you have to start the name of the prop-bone with "loaded-" (in this example, the bone's where the actor is going to appear is "prop-beam". Note*: For static meshes without skeleton, you can use empties parented to the mesh with the name prefix of "prop-". You can later use this empty location to spawn an actor on it's place when defining the props between the <prop> tags right after the <mesh> definition in the actor file. 2015 Edit: - Blender collada export now works better and there's no need to bake the animations even if using IK setups. This reduces considerably the size of the animation collada file. - In order to get clean loops in pyrogenesis, you have to export including the first and last keyframe of the loop. In theory, it is the same keyframe and should be avoided, but the engine needs this duplicated keyframe. In resume: export the first and last keyframe in the animation loop to get a clean looping animation. - Blender now supports "clean channels" option when selecting keyframe channels and deletes the keyframes that do not add anything new to the animation. This reduces the size of the animation file without altering the animation at all. Just select all keyframes in the action editor, hit "X" and select "clean channels" Rigging Tutorials: http://vimeo.com/30073532 http://vimeo.com/30072564 http://vimeo.com/30078317 Animation Tutorials: http://www.cgmasters.net/free-tutorials/epic-looping-idles/ http://cgcookie.com/blender/2011/08/22/animating-a-character-picking-up-an-object/ Import/export 0AD assets and AO baking: http://www.wildfiregames.com/forum/index.php?showtopic=17542&p=273078

Wildfire Games, an international group of volunteer game developers, proudly announces the release of "0 A.D. Alpha 15 Osiris", the fifteenth alpha version of 0 A.D., a free, open-source game of ancient warfare. This alpha features a multiplayer lobby, skirmish maps, auras and more! Easy Download and InstallDownload and installation instructions are available for Windows, Linux and Mac OS X. 0 A.D. is free of charge and always will be. Although you might find some people selling copies of 0 A.D., either over the internet or on physical media, you will always have the option to download 0 A.D. completely gratis, directly from the developers. Moreover, you can redistribute the game and modify it freely as long as you abide by the GPL. You can even use parts of the art and sound for your own projects as long as you abide by CC BY-SA. No "freemium" model, no in-game advertising, no catch. Top New Gameplay Features in This Release Multiplayer Lobby: The new in-game multiplayer lobby is a place to meet other players and play games together. Meet the entire 0 A.D. community online and face the challenge of a multiplayer game!Auras: Units get a bonus when they are in range of a special building, like a wonder, or another unit, such as a hero. This feature adds a new layer of strategy to the game. So far, in Alpha 15, temples regenerate health for nearby units, and most heroes have auras. This feature is set for expansion and further refinement over the next few alphas.Debut of the Ptolemaic Egyptians: Alpha 15 debuts the Ptolemaic Egyptians as a new playable civilization. Some new buildings, units and unique gameplay features can already be tested, but it's not finished yet and still contains a lot of placeholders. The Ptolemies will be completed in the next alpha releases. A Ptolemaic Egyptian settlement along the Nile. Skirmish Maps: Skirmish maps are a new game mode in 0 A.D. They're similar to scenarios, but can be easily changed according to your preferences. Like scenarios, these are hand-crafted maps in which the terrain, starting positions and positions of resources on the map remain constant every game. However, unlike scenarios, other aspects can be changed every time you set up a game, like starting resources, factions and teams.Also, in skirmish maps the map creator also placed some generic entities on the map, which will change according to the factions players choose as soon as the game starts, such as generic Civil Centers that will immediately transform into Civil Centers specific to the faction chosen. Skirmish maps are another option available to the player, on top of scenarios and random maps. (Try the first skirmish map, "Alpine Valleys", bundled with Alpha 15!) The Alpine Valleys skirmish map. User InterfaceEscort / Guard Order: You can now order your troops to protect other units or buildings. When the guarded unit is attacked, whoever is guarding it will come to help, either by attacking the offender, or by healing or repairing the guarded unit.Attack Notification: Whenever you're attacked, you'll hear a sound and receive a chat message, and the minimap will shows some blinking pixels on the map so you can quickly see where the attack is happening.Auto-Garrison Units: When possible, you can ask your newly-produced units to garrison in the production building by setting the rally point in the building itself, using the Ctrl key.Automatic Naval Pickup: When units are asked to garrison into a ship, the ship will sail to the shoreline to pick them up."Back to Work" Button: The last civilian task a unit was doing (i.e., gathering, building, trading, ...) is remembered when ordering a unit to do some military task (i.e. attack, garrison, ...). After you're done defending yourself from an enemy attack, you can quickly send units back to their previous tasks using the back-to-work button. New tech icons. Music and SoundTwo special tracks have been composed for the Ptolemaic Egyptians: "Valley of the Nile" (feat. Shlomi Nogay on flutes and Jeff Willet on percussion) and "Ammon-Ra" (feat. Jeff Willet) (see YouTube videos below).A new generic peace track, "Tavern in the Mist", contributed by Mike Skalandunas."Celtica" and "Highland Mist" now feature an actual Celtic harp, played by Avital Rom."Eastern Dreams" and "Sands of Time" have been completely remade, and now feature Jeff Willet on percussion."Honor Bound" remixed and remastered.New selection sounds. GraphicsBetter Unit Movement in Formations: The units in formations run around less, and now know how to get to the closest available place in the formation. This way, the formation is formed faster, and the pathfinder doesn't have to compute long paths for big formations.New Asian elephant and tiger animations.Some new buildings were added to Brits and Gauls, complete with AO, normals and specularity.New terrain textures. Development Updates, Bug Fixes and Miscellaneous Features The new GUI design, modelled by the new Multiplayer Lobby. New GUI Design: Work on a new and improved user interface design has started a while ago. With Alpha 15 you can see it in action the first time! At the moment the new design is only used for the multiplayer lobby, but other menus will hopefully also benefit from the improvements in the future.Internationalization Work Started: For the next Alpha we intend to include a translation system, and work on such a system has already begun. Volunteers have begun translating 0 A.D. into dozens of languages. If you have the necessary skills to help localize 0 A.D., feel free to head over to the web-based translation platform Transifex!Multiplayer OOS Problems Fixed: Several causes of out-of-sync errors in multiplayer games have been fixed. These issues made multiplayer games with AI players nearly unplayable in Alpha 14 but should now be fixed.Increased Support for Multiplayer Hosting: If you were unable to host multiplayer games before because you couldn't manually setup port forwarding, now the game will try to automatically negotiate port forwarding with routers supporting UPnP. This should allow more people to host multiplayer games without connection issues.Some recent graphical changes make it possible to make particle jet trails and more realistic smoke in the future.Random map generation is now faster. Getting SupportPlease see the "Get Support" page on our website to find ways to get help from the active and friendly 0 A.D. community. We are well aware there is some room for improvement in 0 A.D. Some known issues are: Lag, visual glitches or textures not loaded, missing animations and more. When you provide feedback, we would ask you to focus on some of the other points that could be improved. Thanks. Please Contribute!We are seeking volunteer contributors in programming, art, sound, documentation and more. Programmers are especially welcome and can get started immediately. Interested? Log onto #0ad-dev on QuakeNet on IRC and meet the developers. Also, you are invited to register on our forums and start participating! Why "Osiris"?We name our releases according to development status ("Alpha" or "Beta"), successive release number (1, 2, 3, ...) and a word relating to the ancient world, in alphabetical order ("Argonaut" for A, "Bellerophon" for B, ...). Osiris was an ancient Egyptian god, usually identified as the god of the afterlife, the underworld and the dead. In honor of the release of the Ptolemies, we have decided to dub Alpha 15 "Osiris". For the next alpha, we welcome fan suggestions for words relating to the ancient world beginning with the letter P. Keep it original and related to the time frame portrayed in 0 A.D. (appx. 500 BC - 1 BC)! Subscribe to 0 A.D. Development News Contact info for press, bloggers, etc.: aviv@wildfireNILEgames.com without the capitalized name of Egypt's most important river.

Can't he just edit the hastatus template to display the legionnaire actor? I'm not too good at modding either I don't know if that will require a public SVN but here's how to do it in SVN open the SVN folder to \binaries\data\mods\public\simulation\templates\units open rome_infantry_swordsman_b.xml in notepad replace units/romans/infantry_swordsman_b.xml with units/romans/champion_unit_4_imp_legion.xml in the text file, then save repeat with rome infantry swordsman variant b,a, and e to undo it all, just run cleanup

For Imperial Romans, this will be the elite Swordsman rank (plus front to back crest on helmet). Advanced will have segmentata, but no manacles, greaves, or crest. Basic will wear chainmail and a bronze version of the Gallic helmet.

Or build a super huge Carthaginian fortification on top of your hill and grind them down to their last man! Pewpew pew pew! aaaah! peshcew! fight the athenians their AI is no good with ranged seige equipment yet (use outposts to spot for your towers and fortresses, they have a longer LOS range when upgraded, and buildings can't shoot into the fog of war) (AI likes to buy food with metal and stone, driving up prices so use the market to your advantage) ah, but seriously though. that probably won't work. could be fun though

Shape looks good and textures too, but it looks too boring right now, there are like three or four walls that there's nothing there except a window. I'd suggest to make some openings in one or two walls to show something in the inside of the structure to make it more interesting. Look at the current iberian barracks now. I'd prefer also to make some (if not all) corners a little bit rounded, like the rest of the iberian buildings. And for the textures, could you try to show some bricks at the bottom? If I remember correctly there are some bricks under the texture you used that could give the overal colors of the structure some contrast. This is used in a lot of the current buildings. Or maybe try to use the roof tile texture in the middle roof... (not sure if it will look good) Overall, there's nothing wrong in your model, but since the player is able to place the structures in any angle, we need something interesting for the player to look at from every angle. And since we don't have concept artists in our pipeline, the modeler is the one in charge of the concept of the building which makes it harder than working from a concept in paper. That's why I am suggesting "add more detail" on every step (artistic freedom you could say ).

there is some software for shaders dev. Saddly (for me) most of them are written for windows... I read some time that RenderMonkey (ATI) is a very good software. I never used RenderMonkey, I don't know if it's still up to date or not, if it's good for opengl and/or directx... When I tried for myself to found a software, I found some other (on sourceforge iirc) who looked interesting but all for windows... So I'm writing my own application, it will never as good as RenderMonkey or such (so far).... but it will enough for my needs.

Some major points behind this whole debate: -animals in 0 A.D. fit three roles: be food source, be small nuisances to villagers so you have to worry about them, be decorative. -most sharks don't attack stuff just like that. The two main exceptions are bull sharks, which tend to attack in shallow water, and pelagic shark (such as the whitetip) which are very opportunistic predators because of food scarcity. -we do not have amphibious units. Sharks, even large great whites, can hardly sink vessels. There are recorded cases, but it's oustandingly rare, and extremely unlikely, particularly given the size of our ships. Therefore, sharks don't have melee attacks because that would be unrealistic. If we ever have amphibious units, it is a possibility that we'll add melee attacks to sharks. We'll see. However, for example, it might be good to have pelagic sharks and coastal sharks, the latter attacking only if amphibious units get in high seas. This would be a relatively realistic way of telling the player "units can't just swim forever". About lions and such: those don't really attack humans either, but could if they feel threatened and so on. For the purpose of the game and fitting point 2, they probably should.

I really really like the idea of tying in stats to some form of external motivator like achievements. Even better if that can be linked to 'unlocking' or 'buying' new civs. Many benefits with something like that. Thats somewhat off topic so back to the summary screen. I suspect having peoples play style are summed us as turtler etc, will be one of those things that looks good on paper but not in practice. Is it feasible to have the summary sent as a means of determining balance? If so, I would add trackers to help determine balance but not have all of tracked things visible to the player. (hope that makes sense) I'm still sitting on the fence about if scores are for better or worse. Although I personally am in favour of having a score, I feel like not having a score would be better for what people want.

I believe one of the strengths of the Achaemenid Persians in 0 A.D. is strong buildings. The proposal for part 2 lists Parthians, perhaps Scythians, Sassanids, and (non-Persian) Huns. So in the future it's likely there will be nomadic tribes It would be a good way to set them apart from other factions in terms of gameplay.

Lions and wolves can still be provoked by trespassing their territory or feel threatened by close presence to their young. Unlike sharks only attack out of mistake or curiousity.

Nice:) Will they replace the Bactrians or just an extra champion? Limmited elephants could work for other factions as well, like Rome (maybe after marian reforms at the auxiliary camp?) and Macedon (actually used the quite a lot, if you consider Alexander and Western based Successors like the Antigonids, they probably used more elephants than the Ptolemies and almost certainly the Persians). The Persians could also use some change/buff in the early game, they seem the weaker by far (ranged micro player ability excluded).

Thank you Anything else ? EDIT : Updated with swords also Improved the cask texture.

ok. today, (after I have visited two castles and some chruches ), I have started modelling a church... between two sacking of castles... all good christians need to bless their trebuchets!...

Being a shark enthusiast and actually being a donater to fund protection for sharks, I don't appreciate sharks labeled as hostile animals. Sharks are lazy scavengers of the sea, not blood thirsty man eating predators like humboldt squids.

So looks like you have right... For some strange reason they don't used Nubians. "From their coastal possessions in Thrace and Anatolia, they were able to recruit the warlike peoples of the interiors: Thracians, Galatians, Lycians and Pamphlians. Most of these fought as thureophoroi. Libyans are also mentioned, but wither these are from Greek Cyrene or the Libyan desert-dwelling tribes is unknown. Cretan archers and Rhodian slingers were also prized specialist troops. Judeans and Idumean Arabs were also recruited, but seem to have been used mostly as police and border patrol forces. Oddly, the Ptolemies seem to have made no use of the Nubian archers of the Northern Sudan; which had served to good effect in the ancient armies of the Pharaohs, and in the Medieval armies of Muslim Egypt." http://deadliestblogpage.wordpress.com/2013/12/06/armies-of-the-macedonian-successor-states-the-ptolemies/

LordGood: to be honest, you work way too fast for anyone to catch you between "concept" and "finished model" It's certainly not a bad thing that we have buildings instead of "nothing". It's just that some models could be improved for A16. At least coming from me, certainly do not take it as a criticism.

Ptolemaic Egyptians: