Radagast.

Did you have a look at the wolf's (attack) animation? The trample effect (e.g. for the elephant's you mention, also for horses) is planned. On a per visual base I would say for the beginning one attack animation is enough. Also because we don't have a reaction system, i.e. play defensive animation if you are attacked. More animal animations is what Romulus surely also needs for the Colosseum. Though me personally I would not tend so much towards war. Only the fact that the animals are around is already quite impressing. If they are put to piecemeal, then it's a loss for the visual richness of 0AD (as they currently can't reproduce).

So do you think we shall rename the civ? Do you know which factions already have xml/json files? <- I can see it in the repository @CivDesignDocuments: I would love to have it in a database (i.e. a webpage which we can edit, add units, ...). Then we could generate the XML and JSON files on the fly. This would imply we could edit the civs in almost realtime, always outputting the correct files for 0AD on Thamletts server (if he's finewith it). (if we were to have our repositories on Thamletts site, we could even have it real realtime, i.e. without having to overwrite the civ xml and json files in the repository manually.) Does this look helpful? If not, what kind of tool would help you? What I need to know: Is using a website instead of a Offline-Document convient for you? (Export in DOCX/ODT is still doable if we have a webspace/server with admin rights.)Or do you prefer uploading your document somewhere. (this seems inpossible because everyone uses a different syntax!) Yet the second is what we needed as we already have plenty of art design documents? If we have a significant amount (how many?). Then we should go for point 2. Thus further knowledge is required: Which file formats are the files written in?Can anyone create a list of all files that we already have, so that I can have a look at each syntax the individual researcher used?The goal is: Generate the civ files (including their units', buildings', ..) out of the design document. @Lion: We must not lose track of your non-final 2D art, you produce many shield-emblems on the way to the final civ's logo. This colour variation for example: (or will the colour for the units be player colour?)

True. We better not start such efforts before the author of that site really helps us. That's also why we should consider to share the content of Veridagorin's and MuteLovestone's mod. The story each Mod-leader can develop individually. The art efforts at least should be joined on one Fantasy project at max I guess. Otherwise we fall into redundancy. We can add special derivations (of meshes, textures, ...) later on. The question is if MuteLovestone is fine with combining the art efforts? The concepts and story can still be put into xml and json files independently. (as this will be no problem for MuteLovestone .-- our biggest problem is rather the art team.)

We could join efforts and translate his work into JSON and XML files, could we? Then we need the models and there you are. (textures too, engine does not like bare models without textures, graceful engine ) Without the textures we might make it. I fear the texturing most. And then the animations .. this might take years then. Best exclude them first.

Ah thanks. Now I see what it's for. Strange it doesn't fetch it from the public mod. Or perhaps it's because of old Alpha 15. That's what I thought too. @Shieldwolf: http://trac.wildfiregames.com/wiki/BuildInstructions#Windows Just check out SVN and use the autobuild in binaries/system/pyrogenesis.exe . So you don't have to compile anything. Nor have you to deal with Visual Studio (just like Niek once told me in the Group PM). It's best you check out the Engine on Windows from SVN. You just need Visual Studio - any version. <- That might be the biggest challenge. The rest is a one-liner. I can't provide a batch file, but the 0AD devs have already updateWorkspace.bat which does most of the work for you. The git repositories may still go directly inside the SVN folder structure (just like for git). @Sander17: https://github.com/0ADCoM/Aristeia thx for the help. I simply can't find it. Have looked from TextureManager.cpp's CTexture::TryLoad() on. Yet it must be somewhere on the JavaScript side. I guess it's because he used Alpha 15? Because I grepped the whole repository for formation and checked all occurrences. There seems to be no issue with that. Though things like concatenation of variables I didn't check: iconPath = basePath + type + formationIconPath

egypt_support_female_citizen_house and others are not defined. Do we need artwork for that, Lion? Stan ist the definite buildings' master among us. This is really strange: /common-api-v3/ @Shieldwolf: You tested with the Alpha 15? Niek, can we somehow guide him to the SVN windows? Or did you try to compile the git version, Shieldwolf? Where are you stuck? We'll try to help. Perhaps I can create batch file to make it a 1-liner for Windows too.

I have looked for it, to no avail. We don't have it double. At least in the mods/public/ revision I have here locally. Will make an update. Best we just wait for another playtest. Maybe it's fixed by your formations fix. Usually you find the GUI for this in public/gui/session/session.xml.

Have committed an AristeiaAttack typo fix. We forgot a terminating }. Good work of you Aristeia creators (idanwin, Lion). Thx for fixing Niek. Didn't realise it was really playable until Shieldwolf opened my eyes. ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/icons/formations/formations/scatter.png"ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/icons/formations/formations/box.png"ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/icons/formations/formations/columnclosed.png"ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/icons/formations/formations/lineclosed.png"ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/icons/formations/formations/columnopen.png"ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/icons/formations/formations/lineopen.png"ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/icons/formations/formations/flank.png"ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/icons/formations/formations/skirmish.png"ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/icons/formations/formations/wedge.png"ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/icons/formations/formations/battleline.png"ERROR: CCacheLoader failed to find archived or source file for: "art/textures/ui/session/icons/formations/formations/phalanx.png"We don't have those images? That's strange.

Good find, looks promising to me. The problem is, this algorithm does not take terrain height into account. The branches are generated by The difference for us were that we needed to avoid high ground when connecting two points. So following the steepest slope (gradient). For this to work we first had to determine the higher of the two points, otherwise we never could reach the counterpart. Looks like a terrain with determined height precondition!? FeXoR's algorithm - in contrast - seems to erode the terrain while developing. This might be difficult impossible to bring into harmony with the proposed algorithm in the link. So FeXoR's rain river algorithm is more powerful. The other could still be used for adding rivers to already created maps where height is settled. Thx FeXoR for the fun (and the snow tips). I will take a look at the rain. I imagine you even visualised the drops. It must have taken years to show us the results. Weren't there once this nuclear fusion reactor which went into service 4 years agon and whose form had to be calculated for 12 years by a supercomputer? Oh, I forgot another difference - should we intend to consider Niek's linked algorithm. The width volume (due to narrow passes, obstacles) of the river can follow the colour darkness algorithm:

Thx. I didn't play the game for months. So the Spidermonkey doesn't allow passing undefined values anymore? Now I begin to understand agentx ... or am I getting it wrong again?

AI also uses Command.js: It's about training a unit. The Metadata seems missing. But why is not obvious from your error message gameboy. Can you post the commands.txt? var cmpTechnologyManager = QueryOwnerInterface(ent, IID_TechnologyManager); if (cmpTechnologyManager.CanProduce(cmd.template)) { var queue = Engine.QueryInterface(ent, IID_ProductionQueue); // Check if the building can train the unit if (queue && queue.GetEntitiesList().indexOf(cmd.template) != -1) queue.AddBatch(cmd.template, "unit", +cmd.count, cmd.metadata); } else if (g_DebugCommands) { warn("Invalid command: training requires unresearched technology: " + uneval(cmd)); }Look for the file: logs/sim_log/<number>/commands.txt

I thought 0AD was all about realism. You are confusing me now. The countering system (e.g. cavalry 2.5x vs. infantry) was extra added due to realism. The only 'new' of my post is to rework the armour system if this 'countering' really is to be taken out of 0AD. (as mentioned somewhere in the IRC log) As a replacement so to say. Just like in reality: The crossbow archer can't shoot 200m far. 0AD also does not have a system that says, that close-up archers hit infantry in 100m distance with 2x force, 150m with 1x force, >200m with 0x force and so on. You see? It's not natural to introduce an artifical system for this (by defining in the XML that this archer hits the target in 200m distance with 0.1x force, that target in _m distance with _ force. etc..). That's why it's not so nice to have the countering system, too: A lot of micro -- this time in the game balancing. That's why Mythos_Ruler wants to get rid of it. I can't see what impossible new I said in my post again. The hero arguments were just supporting the current system like it already his: namely restricting the amount of heroes available.

If I'm not wrong then the countering will be removed. But I think the countering is quite realistic. In a way at least. Imagine you were an archer. Would you target the enemy where he is vulnerable? Would you target the full-plate-armoured knight which is approaching you or the non-armoured men-at-arms? Me I would try to never have to decide this. Because deciding upon life or death is not nice. Nevertheless I think the countering system is a bit artificial. In reality archers were bad against mounted knights simply because the cavalry reached them quickly (speed) and because the archers' arrows had a hard time penetrating the armour. (though even King Philip VI and Edward IV were both severly wounded by arrows too (Philip died), despite them surely wearing the best armour on the field.) It's still cool that this was implmented once - the artificial way. Perhaps we can replace it by a reworked armour and speed system (including terrain-analysis, i.e. mud, slope, vegetation, ...). Limiting the amount of heroes is a good thing. It's also quite natural as heroes often were either the leader ... or outstanding soldiers that were very decisive in battles. Both were quite rare in numbers. The former because there were seldomly more than one leader during an era. The latter because even if this soldier was decisive in battle, it's very unlikely he survived a long time.

Have figured more. The .dae file contains the bones nodes as childs, see: <library_visual_scenes> <visual_scene id="_" name="1"> <node id="Armature" name="Armature" type="NODE"> <translate sid="location">-5.55873e-4 0.06135082 4.854146</translate> <rotate sid="rotationZ">0 0 1 0</rotate> <rotate sid="rotationY">0 1 0 0</rotate> <rotate sid="rotationX">1 0 0 0</rotate> <scale sid="scale">1 1 1</scale> <node id="root" name="root" sid="root" type="JOINT"> <matrix sid="transform">1 0 0 0 0 7.54979e-8 -1 0 0 1 7.54979e-8 -1.5 0 0 0 1</matrix> <node id="ball3" name="ball3" sid="ball3" type="JOINT"> <matrix sid="transform">1 0 0 -0.5 0 1 0 0 0 0 1 -7.54979e-8 0 0 0 1</matrix> </node> <node id="ball2" name="ball2" sid="ball2" type="JOINT"> <matrix sid="transform">1 0 0 0 0 1 0 2 0 0 1 7.54979e-8 0 0 0 1</matrix> </node> <node id="ball1" name="ball1" sid="ball1" type="JOINT"> <matrix sid="transform">1 0 0 0.5 0 1 0 0 0 0 1 -7.54979e-8 0 0 0 1</matrix> </node> </node> </node> <node id="Icosphere" name="Icosphere" type="NODE"> <translate sid="location">0 0 0</translate> <rotate sid="rotationZ">0 0 1 0</rotate> <rotate sid="rotationY">0 1 0 0</rotate> <rotate sid="rotationX">1 0 0 0</rotate> <scale sid="scale">1 1 1</scale> <instance_controller url="#Armature_Icosphere-skin"> <skeleton>#root</skeleton> </instance_controller> </node> </visual_scene> </library_visual_scenes>In our code we use the hangle up towards root method to find the skeleton's root. I here propose an alternate method with respect to wazim's Collada tutorial: While the above may be viable alternative, it's not said we have any benefit from changing our current solution. Any input of the 0AD team appreciated. The problem for the Juggler indeed may be the connection issue. => Just testing what happens. <-- tested, to no avail

Wow. Even longer than mine. ^ I wonder if we could exchange the burn armour/damage properties with a temperature range (e.g. ideal temperature 10..30°C otherwise damage depending on how far off the temperature is). This way also the cold could do harm using the same system. It may not seem natural to have heat- and freeze-resistance in one. Yet the temperature range could easily be researched for realism too as it's readily available property in lexica of fauna and flora (hence suitable for 0AD). Perhaps the best tactics against them is to not approach at all. Never come near to those. I wonder if the archers destroyed their muscles by the sheer force? An interesting article about the longbow from 1300..1500 (100 years war) can be found here: Longbow. The English used the archers at the flanks of their infantry, very wise ... they drove the enemy away from their flanks. The French used crossbowmen to attack from infront the battleline. Yours use a longbow for sure, so will it be a tall tribe? As a small people might not be enough for that distance. For the artwork it will be difficult for others to know what you imagine. Other than that you have faction going. Need some heroes though. http://www.lordsandladies.org/flail.htm by Linda Alchin I favour this situation. We will have trouble as horses are more vulnerable to arrow due to their bigger extend and thus areas of attack - and because of missing armour. Horses were abased by using them as cannon fodder. Horrible to me. I hope they have equal armour. ..hm .. will the horse be able to walk with so much armour?? I note the bandits, just reminds me of The Council's Robin Hood extension plans of the 0AD minifactions.

This error was fixed, needed some object. Typically the next error was just waiting. I figured the cause (no root bone found): // I can't see any proper way to determine the real root of the skeleton, // so just choose an arbitrary bone and search upwards until we find a // recognised ancestor (or until we fall off the top of the tree)Valuable information in the code. I love open source. The code is the best Wiki.Bones either have to be connected or the parent is not properly saved in the COLLADA merry-go-round_vertical.dae. If bones have to be connected, then we obviously can't ever get my loose-bone animation ingame. The complete function: => I have to figure out if COLLADA saves my in blender set parent bone correctly. Or if I have to make them connected. (then I had to redo the animation it seems as bones move totally different then)

Yeah, good idea, the shader - if it works out performancewise. I have thought a bit about snow variation with altitude but I can't find a functional connection. Nor a diagram to derive the function from. So I guess we have to use a linear function first. This is all what I could find, about snow height in The Swiss Alps: http://link.springer.com/article/10.1023/A:1005310214361#page-1 Have posted in the Random map topic as the random map functionality had to be used for the creation of this visual snow layer too (to give it variation).

I had something wrong above: local is clear already, private it should be. The function not assigned via prototype is the only chance to have private variables. I think it's convention, to put it in the class body directly only if you desire this private functionality. Else better keep it outside. @FeXoR: We talk about snow here. It involves a local duplication of the terrain (only visually) that varies in height to emulate the snow fallen so far. In summer the height sinks due to melting, the snow-height also depends on height of the local part on the map. To have it not as a exact duplicate of the underlaying terrain-height would look more natural. Do you know of a function that would give the snow-height visual layer a bit of a natural variation (in height => form)? The snow-height depending on altitude could be solved by a linear function. Unfortunately it seems difficult to find snow-height variation data over altitude. Mostly it's snow-height variation over years (due to climate hype). Also this might be of use for us: (abel.math.harvard.edu/~divac/SAR/pchap1.pdf‎) I also thought about the possibility of a global wind factor, needn't be local (too complex?), but should be able to change over time. Though I wonder myself which effect this wind should have. And how to visualise this wind? You are the natural functions expert here, so I thought I'd come by your thread and lay siege to it.

In this context what really interests me is to combine blender's capability and pyrogenesis'. Both alone are already so powerful. How then would a hybrid feel? Of course the creator of Krum himself is a neverbeforeseen master and yet, it took years to accomplish. So this is where the problems arise. Look into blender forums and how many different people work at so many different projects, without real thrust behind any of their developments. Why? Noone knows why the gap behind Krum is so big. Perhaps because just work for themselves? The union is the solution, the fellowship. Without this human is lost. I wonder if we could reuse this shader? If look at our water shader then .. wow .. it's already the peak of the everest. Yet it could be interesting from a technical aspect. http://blenderartists.org/forum/showthread.php?170812-Non-Glsl-water-I-made-for-the-Krum-game Blender and pyrogenesis are different worlds, the one plenty of units -- the other only some characters. Yet a hybrid is possible. (and I love the idea)

I'm stuck with random crashes: list_name ... okay. Now I have it. Just forgot how I fixed it. omg.

There you hit a diamond among the open source world, blender is your friend. http://blenderguru.com/ is uberawesome. You should check it out, it's a crazy lecturer with crazy talent teaching you a crazy program in a crazy but effective way. And I don't want to miss Andrew Price on this planet. There are also other good tutorial sites, like http://cgcookie.com/blender/ or the tutorials of Sardi Pax. Also check out the much more relevant tutorials of Enqrique throughout the forum. It's hands-on knowledge, just to get things ready for 0AD. (though a without basic interface knowledge of blender it might be hard to follow) If you have a problem type Spacebar and search for what you looked for. e.g. arh, I wanted to do a ring cut here => search for cut .. or ring .. try as much as possible. Blender is a highly shortcut driven program. It is not easy to learn. But the power is endless, you could create IceAge yourself with it if you really wanted. Oh, I didn't think of racism. I must create a unit that frees the world of that. Lochatons are not so nice it seems. I like nochatons much better. I really can't imagine bald Imaldra currently. Omg. If enough people warp drive projects, everything is possible. Writing books is what feneur also likes, perhaps you can turn it into a film too. Though that's nothing for me until our Open Source community has not finally succeeded in their biggest project: making this world a better place. Only if humanity joins efforts in a open way, we can achieve this.

Ah, hm. You can keep the repository with your account of course. But how can we access it. Can you add us as administration? Or do you have a paid account and this is incompatible, it should not? Don't you like it as public account (then still only Administrators can change it but everyone can see)? I think there are only two possibilities: You could add us as collaborators.Convert it to a CoM repository by transfering owndership of your Anorithia repository via Settings at the right in GitHub.

Didn't know of that. The map looks interesting. A real desert ... In the last weeks we had Sahara dust around in Europe. Usually goes to the Caribbean. This is what your desert reminds me of. The unis will cross it easily with their giant speed in comparison to the map's sizes that we currently can perform. The Sea in the North, wait, is it the South? - is it crossable? Looks like a good ranged units standoff. Is a story connected to it. It's looks quite specific, a scenario or skirmish map we could include into the main game? Edit: Thanks for the link. I need the location for the mod manager. So you helped me out. (and fcxSania)

To clarify. Research showed, we have to decide upon where we store the special data, either: In a information file on the 0AD side. If modders change things, like category, they change it on the 0AD side. (and changes to take effect takes until the next 0AD release, not so nice, will produce Modders setting up their own system)The information file goes to the mod files. On the 0AD side we still need a e.g. from a database generated text-file containing all mods, in form of a URL. If we instead want to have a file for each mod, then I would opt for making it a file containing:Mod name as filename.source-URL inside,metadata inside. (limited information and generated in contrast to above solution 1)In the latter case we have 2 files, one that points to the source-URL and maybe base64 encoded preview image inline? Also some metadata that changes seldomly, like type, function, ... We here have all variables that change seldom with 0AD. (so modders don't have to come by often to change it, e.g. Version number whenever they change the mod). This extra data like dependencies then goes into a file that comes with the mod. The first solution saves us the file with the mod. All data is on the 0AD side, so if something changes, e.g. version/dependency, features, then the modders need to edit the data (either URL&type-list or the individual files) in the 0AD repositories. For the case the URL changes, of course as we can't guess it, the modders have to re-register their mod or change the link somehow. Personally I don't prefer any solution over the other. Just easy to get confused and thought we should clarify. Concerning the Mod name as the filename: I think as modder already have to be aware how the 0AD structure works (folders, .. which has to contain what to make it work, etc.) it really might not be a problem for modders to stick to filename pattern. Just saves us reading one xml-tag or json-entry and limit the mess (e.g. 100 files named mod1.zip). Sidenote: Does anyone know if we have functionality for file-download already. If not I have a solutoin. If yes, please help me out and show me where and how you recommend to use it.

Going crazy too now. Spending years trying to post long ones ... Trying to decide if XML or JSON shall be our data structure. Feel symphaty towards XML as there are unique paths (xpath) (allowing interesting solutions, one of which I will hopefully conrtibute in a few weeks). XML is handled by Xeromyces in pyrogenesis C++. As we have to deal with heaps of files we have to deal with another C++ module anyway (VirtualFileSystem). We could use JavaScript to parse JSON but it has to be delegated to the Engine anyway. A lot of data passing forth and back then. So I think the JSON has disadvantages (though it's cool too). JavaScript had to do the renaming of files via the SpiderMonkey anyways (better rename than have to alter the mod-config-file's content). Any inputs? Our base is Sander's structure. I recall here: The scheme is definitely what we need. Though the shasum I don't like. Only modders can mod their files and to check the downloaded file's correctness is impossible via the sha12sum because which modder will update the SHA sum in the 0AD sources everytime a change is made? If file already exists, I would append a number simply. That's easy to remove for nicer displaying later.Recalling more posts for us not having to over and over look for the relevant parts spread out in our large and diverse Council topic(s): To have the url-encoded source- or download-URL as the filename allows ultra-quick sorting. Could also put the mod name in there. What I don't want is to have a non-saying filename. Filenames have to be unique anyways, so you have to care for how to name that file anyway. The URL can be the filename. It is unique and the might change seldomly. Though me personally I prefer a descriptive mod name (not 1 not mymod not changed_number, ...). We can have tags/description though. The filename can easily be parsed into a display ready name, e.g. "_" to " " conversoin or CamelCase analysis. It doens't matter if the people have to care for defining a well-thought name inside a JSON or XML tag. Or if they need to think of a well-thought filename. I prefer the latter. Dependencies: At first I thought we could resolve dependencies via SHA1|2 but as the file changes, it might still be compatible, so only equal is possible and not >= <version>. => so we need a version number. Might be extracted from the filename (Mod generic name). How about changing the dependency check entirely to: Analyzing the type of the mod (e.g. sword, bow, ...).Analyzing the generic or specific name (e.g. Pilus Spear).So if nothing were to be found we still could fall back to using any spear. Would be quite handy and the more natural way too. If You want a pizza then you also don't ask 'hey the pizza is not looking like I showed you in the picture, it's darker!'. The answer would be: 'Well, the function is still the same. No pizza is identical.'If we adopt this for resolving mod dependencies we get a rigid system. e.g. in the case of a map: You want the Acropolis Map of 0 AD. well it could not be found, the Mod is broken or what ever. As the mod manager analyses the function/target of the map, i.e. Greek and ancient, it can simply choose the default map as it's Greek and Ancient and meets the requirements (dependency). So each mod could fulfill a function/target and this has to be specified anyway in some configuration file. We could simply reuse this configuration file as the <mod>.xml. If so then we have to add optional xml-tags: download-URL (simply url does it.)...Still the organisation as is currently in 0AD can stay unchanged. i.e. If launched with pyrogenesis -mod=<mod-pack>. Then all the dependencies are being resolved. Finally the relevant mod packs (where the needed mods are located) will be activated (this time not all overwriting) or even better the mods are handpicked from the mod-pack's subdirectories without having to care which files overwrite which.The order the dependencies are listed in the mod's configuration file determines the order in which mod-files are loaded, overwriting existing ones.