Radagast.

Once I'm into it, it will be done. Just fighting with the animation and prop system for our prop demolition system currently. (as a consequence of the juggler which I almost have done but there is an error that drives me crazy)

I'm on it. Just takes some time ... have to pose, add background, render ...

Now using bones. Three balls. Some variation. Transition from end to restart is difficult. (should be seemless animation)

These are another two convincing arguments. Thx. Didn't think of the networking ... nor that it's quite difficult to learn C++. thx for the hope. sounds good.

Not sure if we have a high poly unit around. On blendswap there are some, but it should somehow be connected to 0 A.D. for promotion. Horrible picture btw. I can't feel much sympathy with attackers. Even in the (Austro-German-Japanese) world wars I rather feel with the defenders (no matter which nation). How should we put up such an image? There are awesome knights on blendswap, though. e.g. this one from visnik. This artist even has a splendid Train for a later mod in his repertoire. Or from daren blenderartist, incredible & rigged:

Don't rush, collague. We are not in a hurry. Once you are feeling there is a desire to sit down in the evenings at candle light and dive into viking adventures, examining their culture and style closely, then you may well read the book. My banners are missing the breathe of fresh sea air too. So there is no rush.

Yes I believe that is it. Though if I recall correctly, Konstantinople used a flag with star and sickle. CONSTANTINOPLE The star and crescent symbol was originally used as the flag of Constantinople. According to legend in 339 BC the city of Byzantium, (later known as Constantinople and then Istanbul), won a decisive battle under a brilliant waxing moon which they attributed to their patron Goddess Artemis (Diana in Roman mythology) whose symbol was the crescent moon. In honor of Artemis the citizens adopted the crescent moon as their symbol. When the city became the Christian Roman Constantinople in 330 AD, Constantine also added the Virgin Mary's star on the flag. ISAAC COMNENUS OF CYPRUS Isaac Comnenus was the last ruler of Cyprus before the Frankish conquest during the Third Crusade. He was a minor member of the Comnenus family, a great nephew of the Byzantine Emperor Manuel I Comnenus (1143-1180) and a grandson of the Sebastocrator Isaac. The coat of arms used by Issac Comnenus was a crescent moon and an eight pointed star on an azure background, adopted in relation with his family links to the Byzantine emperor. Emperor Manuel made Isaac governor of Isauria and the town of Tarsus in present-day eastern Turkey, where he started a war with the Armenians and was imprisoned by them. When Isaac was released in 1185, he hired a troop of mercenaries and sailed to Cyprus. He presented falsified imperial letters that ordered the local administration to obey him in everything and established himself as ruler of the island. http://www.welcometoportsmouth.co.uk/star%20and%20cresent.html

Awesomeness has overcome us. Good gracious. Gea la gea. Like Aelfric had put it. (yes oh yes .. the Saxons are on their way.) Edit: Now we have three variants to put in our repository: Red Dragon on Black Shield.Red Dragon on White Shield.White Dragon on Red Shield.Good work Lion. We can reuse the shield for the units too. This is great progress.

usted puede abrir un tema para ti CIV, si quieres. ¡Por favor, ya sea (1000 AC) [Civilization] olmeca o(1000 AC) [Civilisation] olmeca o(1000 AC) [Civilisation] - olmeca o(1000 AC) CIVILIZACIÓN - Olmecaa su gusto. you can open a topic for you civ if you like. Please mention either (1000BC)[Civilization] Olmec o(1000BC)[Civilisation] Olmec o(1000BC)[Civilisation]--Olmec o(1000BC)CIVILISATION--Olmecto your liking.

I think King Arthur is a good idea. We will surely not fall short of historical heroes in all timeframes. At least heroes as the history writers state. I think the 'every unit can become hero' idea is what we (the council) should pursue first. We can still specify in the hero XML when the hero will be born (i.e. the first next unit born will get this name, e.g. Alexander). The when should be a timeframe, not a point of time. To allow for a moment of surprise, e.g. no, not now, can't this hero come up later when we are stronger .. something like that.

You're right on that. I also like the hotloading. Though I have plenty of issues with hotloading in other projects. Ever experienced static classloaded (and not hot-reloaded) member variables loose their values? It's not so nice ... and not so easy to find. I could also define an XML property that defines a logging setting which is constantly reread and setting the logging mode. But that's still not ideal. I don't think so. Instead the logic and variable names as well as comments are converted as is. Only the types give some hassle. And to adapt the storage structures and their use thereafter. It's definitely a time-saver, alone because it saves you to rename our 14968 occurrences of var to the corresponding type. Though still I also favour the option to just go with the SpiderMonkey. Yet I think Yves has the last word here. yes. besides their speed advantage really becomes that high as is anticipated. This would really be huge then. As we could perhaps live with our pathfinder then? otherwise I like the crowd formations very much and will look into it in the following years. So no matter the SpiderMonkey outcome, we will have a solution for our million-unit at a place lag problem. And's that a good thing. (mostly 0 A.D. is critisized for this performance lag in other forums ... though they probably don't know, that we'll get rid of it ) To give a context, I repost a formations and short pathfinder research video here too:

That's what I also thought. It's also customisable. e.g. the local.cfg overwrites the global.cfg and such. I think poVoq is talking of something different. But I think that's exactly what we need to do, just change the keybinding there to no longer interfere with the Hybrid->Uni_Perspective mode.

Cool. The more civs the better. In general we could create a variety of props for each epoch. Then the factions simply get assigned which props they are allowed to use for their buildings and culture. This way Chinese would only be able to construct buildings with for them typical roofs (depending on trade and cultural exchange perhaps others too). Also this would allow to assign each prop a timeframe (starting and end point of time). This would make the factions evolve over time.

I think 0A.D. stands for 500B.C. until 500A.D. Did you mean Roman Prisoner Of War soldiers defending the nomadic Xiongu chief's palisade tent against Han forces? with Roman-Chinese clashes? Object conversion should indeed be doable. Instead, why not add artifacts the are hidden, but require a leveled up priest or campion could "Divine" it by offering maybe resources, fauna, units, whatever will balance, and each with a specific "Divination translation". This patch is related: http://trac.wildfiregames.com/ticket/2243 and could be adapted to create a new unit on tech research instead of altering stats. Sounds like technologies, though it should be a technology that is active while a certain object is in the inventory of a unit to make the tech target the unit, so only one gatherer has increased gather rate.of any building (just like current gathering but with objects). Here the tech would be active globally - until the building is conquered (including all its inventory). To build walls into water? Could be possible I guess. Placing/Building eye-candy objects is not yet possible. More ships have already been created, e.g. here by Stan and Enrique: Ptolemies. Or more ships ingame? The naval battles are not so advanced currently. There is discussion about a new Damage indication system here and there in the trac. Warfare with cannons and storming ships is planned too. Building might be walkable soon - for the ground floor at least. All depends on our planet's open source community's efforts. We will not get this as a birthday present I guess.

Winter is our friend in our ventures. You surely guess why. So next winter we will hopefully have a protoype running, including first campaigns (the storylines). I think it's easy to allow sidequests with the now ready triggers. Do you have some code until you encountered the config already? I will otherwise pick this up. Well, don't really have to as I already have some work done on it for the Hybrid AI. Which is exactly what you discussed here. Interesting I never encountered the topic, could have been a cool motivation. Still what I do does not need a document of any name, it just needs goals. My goals are features and flexibility. How this may be solved is left to individuals. So a goal document is what is enough and does not repell anyone as features don't have to be used. They may be used. But noone is forced to use it. The main quest will be to serve it in small chunks, producing patches for 0AD on the way. The maintenance of those will be horrible (as I have no idea of SVN branching, but I might well look into it). We can indeed use all the resources you posted. In Summoning Wars there strangely was some news lately: http://sumwars.org/wiki/Main_Page . The statues used in FLARE are quite nice. Also I like the defender role a lot. Join with your friends and stop the invasion. Though for development of the individual functionality, this plays no other role than motivation. Also the Never Winter Nights Adventurer role. If we hit performance or patch maintenance problems I already have a plan B, that might look severe to some but opens many doors. First I have to do the Mod Manager though as to get efforts orderly and easily shareable/testable. Only after this I can continue my Hybrid AI works (I forced myself not to continue working on it some weeks ago because of my thesis, it was quite a struggle . If you don't have a repository for the codebase so far, we can put it into generic where I put in my Hybrid AI once I get it compatible to Petra AI and usable ingame. Any idea if there is no other way than overwriting the main config? Btw. which config do you mean? find binaries -type f | grep configbinaries/system/AtlasUI_dbg.dll.2.configbinaries/system/test_dbg.exe.configbinaries/system/AtlasUI.dll.2.configbinaries/system/pyrogenesis_dbg.exe.configbinaries/data/config/default.cfgbinaries/data/config/local.cfgbinaries/data/config/user.cfgbinaries/data/config/atlas.inibinaries/data/config/dev.cfgbinaries/data/config/keys.txtbinaries/data/mods/public/simulation/ai/tutorial-ai/config.jsbinaries/data/mods/public/simulation/ai/aegis/config.jsbinaries/data/mods/public/simulation/ai/petra/config.jsbinaries/data/mods/public/simulation/ai/tauceti/config.jsbinaries/data/mods/public/gui/aiconfig/aiconfig.xmlbinaries/data/mods/public/gui/aiconfig/aiconfig.jsbinaries/data/mods/public/gui/page_aiconfig.xmlThose are all overwritable/moddable. source/tools/autolog/SVNLog/config.ymlsource/lib/config2.hsource/lib/config.hThose not, other than those there seem to only exist the spidermonkey 'config/' folder.I must miss something.

I have to correct myself. A JavaScript to C++ converter might be rare (because JavaScript is so dynamic and typeless). Edit: For completeness sake: There is JS_to_C. Example (UnityScript -> C#). As I still hope for technological breakthrough which would render our (not even that big I would say) performance problems history. I prefer keeping things as they are. But well, we have no choice as it's mozilla's decision .. Do you know if this will give yet another performance boost. Its effect should be very noticeable if your tests of ESR31 already gave 18%. Glest is written in C++ if I'm not wrong (what I would prefer as Open Source implies moddability already, so no need for interpreter language, but well I can live with it, 0AD is worth it). Here they talk about us: https://forum.megaglest.org/index.php?topic=9425.0 (they note our complicated folder structure, I share this .. we should not distinguish props that much, that's horror for my future plans.) Is it to be decided if we continue with SpiderMonkey upgrades? What if it all turns out being a pitfall? Then we have to change the JavaScript<->C++ interface once again. I see three hypothetical roads: no more upgrades. => not good for many entities at small place (pathfinder).upgrades => speed up => good for pathfinder, no dev has to revise it.JavaScript -> C++ => same as directly above.I like the pathfinder's robustness. As to what I read about it, it's quite a solid algorithm. (compare to Stronghold where units go through each other.) Another reason for option 2 would be that Mozilla will ensure huge support and bugs are being fixed (like Yves showed). So they also profit from us like we do from them. => Good for the Open source world. => Good for the planet.

Thanks for clarifying. Valuable insights. As a summary: If speed's not needed the stack scanning as you explained is enough. If performance matters then simply give the JavaScript side the pointer deleting task. If the JavaScript side has to deal with speed issues (complicated algorithms for optimization) then surely they have the capability to deal with this pointer tidying up issue too. So is 'leaving the marking of unused variables via the Rooted<> and Handled<> to the user/JavaScript side' just mirroring the C++ side pointer for deletion marking? If so, all is fine. Otherwise I wonder if the memory leaks that might occur, due to the JavaScript side accidentally not marking heap-pointer as no-longer-used, really worth the complification? As generally the more layers the more actions (conversions, ..) where things might go wrong. Still I appreciate the option to have not to compile the JavaScript. So perhaps the new strategy in the upcoming spidermonkey ESR31 will be really worth it. Otherwise I feel tending towards simply using C++ and wonderbuild compiler. Or simply the not-all-optimized anti-almagamation: [UQLite] not-all-optimized anti-almagamation: I imagine having a program where each new file you create can be compiled without the compiler having to look if now some optimizations can be performed. Then compilation speed should increase and then the JavaScript/interpreter languages would be obsolete at once (for an open system like ours, only non-open programs will need it as they don't let modders compile as they don't share code and artwork.). So for us I think the interpreter language is nice only for those modders that write scripts and still are not aware of compilation. (and I guess those hardly exist as compilation of 0AD boils down to just two commands. ) So getting rid of it would save us tons of issues (JavaScript debugging e.g.) and developer time (mainting the translation from JavaScript to C++). Once we have translated our JavaScript files to C++ of course. But I guess there is a handy automatic conversion program out there.

Okay, that's still vague. What I mean:Hit a target from close. => Target falls dead/severly wounded. (in both cases unit movement stops permanently)Hit a target from far away. => Target just continues to run at you (at least after a short slow-down to better protect against the arrows -- and as long as morale is high enough to not make the formation disband and flee).Hopefully it's more clear now what I want to achieve:Units slow down if under heavy attack. (TODO keep track of the level of attack: perhaps by examining the rate of unit's health's change?) Just like for territory.If a weapon hits the target, the optimal distance still plays a role. Especially true for bow and other initial impulse propelled range weapons. (depends on weight => a stone still has the same effect, no matter if hit closeby or from far away)

Note @list: Italic symbols which was added to the list in the most recent edit/revision. Added today: (this is already WIP) Two-handers Automatically put the shield into the inventar. Two weapons at a time. More choices. Unit chooses what is available/still functional. (in terms of historcal accuracy as I think units had more than one kind of weapons too, critics welcome) @Shieldwolf: That'd really be awesome. So not only distance between borders but also exchange plays a role. (more technology transfer if a lot of exchange with enemy, be it by spies or by special trade or a much talking neutral travelling trader ). I immediately had to think of Robin Hood .. or multiple Robin Hoods that settle somewhere, essentially splitting from their factions. That would really be awesome as you never knew if not soon there will be some robbers settle in this forrest or mountains just nearby (or in the middle) of your empire. Would give much more variety if you had to deal with such unexpected threats. Essentially your own people or those of enemies found new mini civilisations. That's one of my priorities: to give units more self-awareness and individualism (those like Robin Hood or Michael Ney Rudolph that change their course of history if their values are not met). Cool, still I think it's a difference. Not only you hit fewer times the target with increasing distance. The damage/depth of penetration is also completely different. So even if archers hit units far away, there will be hardly any damage. That for reality while in our simulation there is a lot of damage. So I think it would add a whole more strategic depth to have the realism. When you let your archers shoot? Sink morale of the enemy? Or inflict casualties? Where do you place them? In front to have more effect? In the back with little influence? Moving unit formations will become much more interesting then. Micro-management-crits should yet not have to worry as you can leave these decisions to your commanders (if there are enough you trust). The review process might take I was told as it's an important change and all developers should be aware of it. So perhaps also the Council should read and understand the program/map changes. I will have a look into it soon. Currently still trying to figure out the network mod download thing for the Mod Manager to put things together.

For the folder structure it could be easiest to check out from our generic mod-pack github folder. Though there might exist some mods in there at some point. Those could be seen as further examples. Contributing back is easy then too. Just for the case that not everyone wants to create a total mod, but only some specials and extensions. I call it mod-pack to indicate a more modular and reuse philosophy. As the art in there is new/additive (even if it reuses another public mod) it's not really a modification but rather an addition. A addon-pack full of modded or entirely new units might fit best. install git.git clone https://github.com/0ADCoM/generic.git generic

ERROR: CXeromyces: Failed to parse XML file art/actors/props/units/juggling_ball.xmlERROR: CObjectManager::FindObjectBase(): Cannot find object 'props/units/juggling_ball.xml'It doesn't find them. But I put it here: 0ad/binaries/data/mods/public/art$ find . | grep juggl./animation/biped/biped_juggling.dae./meshes/biped_juggling.dae./meshes/skeletal/biped_juggling.dae./meshes/props/biped_juggling_ball.dae./actors/props/units/juggling_ball.xml./actors/units/global/juggler.xmlFirst I have to do convert the prop animation to deform bones like you two explained.

Brilliant work, both model and textures (don't worry Stan because of the textures, Enrique is the commander, we can't measure our humble selfs with the masters, especially me.) The boat looks so great. Hard to believe all this progress currently.

Thanks for the hint. That's easy to overlook. Just thought it had to be square. Having it all on one texture is probably easier to handle in the XML because the texture name has not to be changed? This could also work: (though Enrique's way gives more fine-grained control) Edit Mode (TAB) -> Select handle vertices -> SHIFT+S -> 3D Cursor to center of selected vertices -> change into Object Mode (TAB) -> ALT+CTRL+SHIFt+C -> Origin to 3D Cursor

Click the image to see a draft for the juggling animation. %5BGitHub%5D Juggler source file download. (always up to date). Ball prop animated without bones. I guess this will not work?

Mirror depends on the origin or the mirror object you set. Though I have no idea if this works for bones too ..