Radagast.

Please open a topic if you work on something. This topic then will be linked here and striked through once finished. (Civilization)==TASK== Generic: Specific name (Faction)Post below if there are any things you would love to see. Eras / Civilization Variants to model: source: http://www.jref.com/japan/history/ Note: If no more significant/longer existing variant/dynasty comes short before or after a minor civilization faction then we can create art, otherwise we should avoid it. Though there might be special buildings and units which we could create if worth it. 3D 2D Animation Map/Campaign

Honourable goal and I would love it to be the way you describe, to teach history combined with wandering through forgotten worlds of history. As history is the reason why our world is like it is currently. The Lombards stay then. Will now try to update the Roadmap.

That's what I'm looking for. If it's distinct enough and they are important enough (and due to the mongol invasion I think they well might be) then we can add it as a target for new art creation. That's it. We should try to figure out the significant and distinct cultures or rather their variants. We can still subdivide into more subtly distinguishable sub-variants later on. But how would Bulgars and Slavs be called under one umbrella? Found the answer here: Or would we just add both Bulgars and Slavs civilization tags to the common art assets (that's what I prefer as this dissolves the problem immediately as tags are easy to add and remove later ).

I also wonder if the art/building style et al. really changed that much from one dynasty to another. Wasn't it better to abstract the civilisations a bit and introduce them as a tag for each kind of art. This sounds much more flexible to me. Shouldn't we let them be part of the franks and other crusaders? They didn't really differ ... I think we never should create redundant art and the franks were the franks no matter if in Jerusalem or in France.

First thx for those awesome list of both of you. thx will fix it. Isn't the 'Part I' and ' Part II' and 'Part X' more useful to denote the order or priority? It's also useful for grouping the civilisations to know which to include in a release. Thus to me, it sounds reasonable to think that way (but I'm open to critics): - pick the major civilisations/regions of world history. - compile those into a Roadmap as to when in the timeline one of those major players changed that significantly that we need to provide new art. Then: - create art according to our roadmap. - tag it with one or more civlizations/major player variants + time [+ location/region/direction]. - let the engine handle the rest (which ever comes first, e.g. new civilisation pops up by a revolution/ civilization branching via tech research as we already have for celts and so on ). I appreciate niek's & flavius' effort to limit our civilization count. In this sense I wonder not that much if the Asuka Japan fit our timeframe but instead which of the Japan History should be modeled? Which is significant enough. If Asuka is, then we should go for it. If it's not and there was one much more significant dynasty short before our 'hard-coded' timeframe of 500AD (which I don't like being that hard-coded as it's artificial and not really important for the big picture) then we should choose the prior one and stretch it a bit until we can create art for Asuka Japanese. I have definitely to read more about the timeframes. I'm happy you discuss it in good detail. In this sense I would go even further than Flavius Aetius and write it as follows: - Persians (new Abbasid Caliphate art because of their significance) - Persians (new Sassanids art because of their significance) Tech research will decide which way you follow. If nothing is researched until the first occurrence time tag, then the engine will choose from both as per the region/location tag. Also it could provide a tech to choose one of both Persian 'variants' once the point of time of the first occurrence/revolution/split or whatever is reached.

As of the navies: PetraAI of mimo & wraitii now has naval support (in the SVN trunk, not Alpha 16). Mimo asked for feedback/testing in the PetraAI topic. We generally tend to version B as Niek pointed out, but we're waiting for open source enthusiasts to make it happen. Bridges are, at least MuteLovestone is not far from it. He made fences buildable recently. Check out his mods. Excuse my noob question, but with moles you mean spyholes in the ground? Such that units can hide in holes? Or in caves you dig?

It's okay for a start, we can improve it later, e.g. the Obelisk. Thx for fixing it, Niek. Does anyone know if we don't have textures other than AO? Do we always use egypt_struct.png? And if we do how is it possible to have different UV mapping for AO and diffuse? I didn't know that's possible.

The civilizations design document will be compiled into this wishlist indicating status of progress and priority as well as guiding the way to the topic where the art is being developed (those ==Task threads). - please post below if there are any things you would love to see. - 3D Byzantine or Generic RowboatViking Longboat (stanislas62)Viking weaponry. Sword (stanislas62, niektb) 2D Animation Map/Campaign Crusades100 Years War

There were problems with GIMP with player colour before. The solution was to use an alpha channel mask or similar. I don't really know, but it's all documented here: [Resolved] Texture weirdness Cool it's playable. Well done! (what code is broken, what should I fix? are there errors?)

Indeed that's a massive task. Though the last link provided by our stan just seems to do it. Though I'm pretty sure we'll run into problems which will take time to solve, especially to get it compatible and to produce accurate enough results. It might be something for a thesis if anyone looks for a topic. (me personally I first wish to have all 3D models modeled and rigged and prop pointed ... and textures ready before I start really getting into helping out in the animation sector. Once we reach this phase and we're still serious then I'll try to help with all means to get a toolchain/workflow ready for hopefully amazing attack- and defence- animations. Though we might need a stunt(wo)man... 8))

Don't worry, you are not alone. The 0ad council of all modders will help, at least for my part. Also we should note the different art iterations for the Japanese in the Roadmap topic where I'll then link this topic we currently write in. The roadmap was designed to get newcomers started easier. Btw. we have plenty more 3D artists than stanislas, but true, he's the only real 2d 3d converter lol (though he's quite busy and we should rather push him to learn for his exams instead of modeling for us .. he can help after those exams, we have to settle our roadmap first anyways or we'll lose overview). (incredible sketches once again, I see this civilisation come to life soon. And btw again: We separate each civilisation for the future anyway as it's way too complicated to split multiple civilizations from one folder into several, while we have the engine which does the opposite. Thus it's clear that we have to separate each civilization into its own repository and mod folder. Releases are the exception where we bundle it all.)

Indeed, no mix/generic buildings. Instead only the as close as possible placeholder entities until we have the unique ones ready. Is this something we can build upon? We are open to suggestions. Thx for the initiative for the Tang. The proposal of Sander sounds the way to go for gun powder units. Canons and stone throwers which we have in the Medieval timeframe too, could follow this procedure also (bigger projectiles, cannon balls / stones/rocks ... ok, those could reuse the catapults/bolt shooters. Instead the Indian mounted cannons on the back of camels is more relevant to the above outlined procedure, instead of the unit, it's just a camel which needs new cannon-prop + animation then.).

I hope you're not angry if we took over your post in our Roadmap topic? Have linked back to this post of course. Please tell me If I shall remove it again.

Great you solved the first issue with parenting (selecting all prop-point-empties and afterwards select the parent object, then press CTRL+P [the last selected object will be the parent!]). You can texture it and if you join it, then at least the UV maps should be joined too. Of course you can only use one texture and thus you have to make sure the locations of the different UV islands don't overlap. => It's easier to first join (CTRL+J as niek said) and then TAB into Edit Mode (just like the workflow you recalled above): Define/Mark seams to cut the mesh into islands (not required in your case as your object already is constructed of individual islands, i.e. sets of connected vertices). Press U for Unwrap and choose an option (e.g. Follow active quads or simply normal Unwrap depending what gives better results). Now choose one vertex of one of the many islands (connected vertices) in the UV/Image Editor window. Press CTRL+L to select all connected/linked vertices. Press G to move the island where it fits best on the image texture. (repeat this and the previous step for all islands until they are spread nicely over the image texture) (optional & not recommended in general) Fine tune the individual vertices by arranging in such a way that it doesn't look distorted/unnatural. (probably the most difficult part, often it's best to keep the UV vertices in the UV/Image Editor view as is after the Unwrap otherwise it will be distorted. It's thus better to adapt the image texture to fit these UV vertices, best even export the UV map and paint the texture to fit this UV map perfectly using External Autorefresh.)

Okay, the black artifacts mainly fixed. Yet a new prob with the head body transition popped up ... cheetah.blend.zip

Don't worry. I like both the low and the high poly version. It's a fantastic animal to have and you made it possible. We can still either use the high-poly version or fix the UV. Thanks for all your effort.

We've accidentally talked about it in more detail here: http://www.wildfiregames.com/forum/index.php?showtopic=18645&findpost=291427 An other option would indeed be to test each (affected/camouflage-capable) unit for the proximity of a tree and then flag this unit as hidden for as long as the proximity isn't left. (we have to check every entity for this, thus that's more expensive than the other in the link mentioned variant which we could get with 0 extra cost as we check the proximity for enemy units anyway. nevertheless it's an interesting option to have this proximity check at least for all trees.)

Camouflage would be really useful. But how to do it? Could we tag units that they're not 'seen' when the UnitAI picks attack/other operation targets? And the pathfinder? Should it still treat the camouflaged units as obstacles or pass through by temporarily (for the duration of the spell) removing the units' obstructions? (the latter would be interesting for ghosts too) The question is how we could allow to have another unit which counters this camouflage, e.g. breaks this 'mist' and makes the obstructions and unit renders reappear? And what happens to poor units which come directly to the same spot? If the camouflaged units attack then the camouflage is gone. Is it true even for the hero? Best have it moddable via a setting in XML/JSON. Again this poor unit, will it uncover individual camouflaged units if it reaches the same coordinates? To reduce vision range of nearby units severly (to e.g. 10..1m) would be an option for all of this, though how costly will it be to examine all those units nearby and especially how to reset the vision range to the old value when they leave the certain proximity and are no longer affected by the camouflage? The units probably should have ghosty silhouettes even .. and I wonder how we ever should make this happen without Ykkrosh.

Okay. It's not now committed. Figured that the portrait for the Egyptian swordsman_2 existed but the .png ending was missing in the actor.

ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/portraits/technologies/structures/temple.png"That one I will fix with the next commit. Thus there's only one issue left and I'll fix it by providing a dummy image from the ptolemies in the next commit too: ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/portraits/units/egypt_infantry_swordsman_2"

Wow, yet another 3D artist. What's the giant ball? Is it a brewery? The textures of the props you don't have to care for. They are just dummy/placeholders/ how it would look to determine the attach-/prop-points' positions. You don't export those with your building's mesh. Instead you define the props to your chosen attachpoints in the Actor XML file.Hence the props don't need texturing (if you didn't create new ones, did you?). I would assign materials (and with those some textures) to each of the mesh parts of you building, e.g. the big tank, the stairs, ... until it looks as desired.Then I would follow this baking process to generate a texture: http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Bake#Workflow After that you can use External Autorefresh Extension with Photoshop or GIMP to improve the textures, add some details, special effects, all you wish.Then after all looks promising, export the mesh and all the prop-empties (which have to be children of the building).Export to File -> Export -> .dae (COLLADA) Give it a proper name, i.e. egypt_farmstead.dae and put it into the folder: data/mods/Aristeia/art/meshes/structural/Now we need to create an actor, use any other farmstead as template. Create it in the folder: data/mods/Aristeia/art/actors/structures/egyptians/farmstead.xml<?xml version="1.0" encoding="utf-8"?> 2 <actor version="1"> 3 <castshadow/> 4 <group> 5 <variant frequency="100" name="Base"> 6 <mesh>structural/ptol_farmstead.dae</mesh> 7 <props> 8 <prop actor="props/structures/ptolemies/farmstead_cart.xml" attachpoint="cart"/> 9 <prop actor="props/structures/decals/iber_corral_mud.xml" attachpoint="root"/> 10 </props> 11 <textures> 12 <texture file="structural/ptol_struct.png" name="baseTex"/> 13 <texture file="structural/ptol_struct_norm.png" name="normTex"/> 14 <texture file="structural/ptol_struct_spec.png" name="specTex"/> 15 <texture file="structural/ao/ptol_farmstead.png" name="aoTex"/> 16 </textures> 17 </variant> 18 </group> 19 <group> 20 <variant frequency="100" name="Idle"/> 21 <variant name="death"> 22 <props> 23 <prop actor="props/structures/ptolemies/farmstead_cart.xml" attachpoint="cart"/> 24 <prop actor="particle/destruction_smoke_small.xml" attachpoint="root"/> 25 <prop actor="particle/destruction_dust_small.xml" attachpoint="root"/> 26 <prop actor="particle/destruction_dust_small_gray.xml" attachpoint="root"/> 27 <prop actor="props/structures/decals/dirt_3x3.xml" attachpoint="root"/> 28 <prop actor="props/structures/decals/farmstead_mud.xml" attachpoint="root"/> 29 </props> 30 </variant> 31 </group> 32 <material>player_trans_ao_parallax_spec.xml</material> 33 </actor>

Allowing walls and palisades to be built in the water? It can't be too hard as in Atlas you're free to place it in the water. I guess MuteLovestone would have water-buildable palisades ready like a bolt.

well, this may work. essentially everything works. And this forum might be the quickest option, so feel free to post it here. (or on dropbox or on google docs or onto your own server/webspace or whereever you like and have access to it to work on it as you desire.)

Oh, I should have known it from your Avatar. As said, we don't kick our own people - not even if they're not online for a longer time. We're finally modders and striving to surrect a order or food chain or something similiar weird. When you find a time slot, then we're grateful, otherwise we know that there is a real world also begging its attention and we won't be angry on our councilors. Oh, is there a special type? I think we should not push it into a certain direction. I start disliking only squared buildings. Each form is allowed, the rest will simply be obstruction (and even then I could define obstructions like I did for the Egyptian civ which should allow units to just walk in the middle of a building -- anyone tried to pass through the nice door of the Egyptian Civil Center? not sure if it really worked, but I defined it as such to have the door traversable.)

The topic will be renamed from Civilization Database & Export into XML/JSON into Design Document Parser & Civilisation Editor for XML/JSON