fcxSanya

See this Philip's post for explanation, this part is most related:

Of course it would be good to have tutorial scenario(s), but currently we don't have triggers and we want to release solid playable 1.0 version of the game as soon as possible and since properly implemented triggers are massive feature we plan to postpone them to after 1.0 version. I can't say this better than Erik said, so I will quote his words from another topic:

FLARE has a nice-looking Wyvern now: Model + 3 additional skins (CC-BY-SA 3.0, made in Blender, 1436 Tris, 7 animations at 8 frames each). Can we borrow it?

It is defined in config files: default.cfg/local.cfg (see settings for more info).

Maybe it would be good for now, but in the far perspective it would be better to have these things customizable at least for the default/generic bot.

Yes, funny that they have two list items with the same links: <li>For Microsoft Windows Vista*, go to <a href="/support/graphics/sb/CS-029635.htm"><strong>Have Disk installation steps for Windows Vista</strong></a><br /> </li><li>For Microsoft Windows 7*, go to <a href="/support/graphics/sb/CS-029635.htm"><strong>Have Disk installation steps for Windows 7</strong></a></li></ul>

Have you tried the 'Work-around' section from Intel's instruction: http://www.intel.com/support/graphics/sb/CS-022355.htm ?

First of all: please note that this functionality most likely will not be added into 0 A.D. even if there will be a patch for it, because we already have trading which is basically the same generating-resources-from-nothing but with more strategic elements, like you need to carefully place markets (on the maximum possible distance to get maximal gain (which raises non-linear depending on distance), but making sure that trade routes are safe enough or risking) or trade with allies which provide more gain etc. And if I correctly understand your idea you just need to create a priest, move him into a safe place and start generating resources. But if you want to implement this just to make yourself familiar with the code or want to make a mini-mod, this sounds like a good exercise. This is probably a good document to get acquainted with simulation architecture: http://trac.wildfiregames.com/wiki/SimulationArchitecture . From quick thinking you will need to implement following things: a simulation component, unit ai functionality, gui representation and interaction between simulation and gui parts (via GuiInterface and commands). More detailed: Simulation part: 1. Add a simulation component like 'Priest', it can contain some settings and logic (see binaries/data/mods/public/simulation/components) 2. Add your component to some templates (see binaries/data/mods/public/simulation/templates, probably to binaries/data/mods/public/simulation/templates/template_unit_support_healer.xml), this will define which units should have this functionality 3. Pass some info from simulation scripts to gui scripts via binaries/data/mods/public/simulation/components/GuiInterface.js : GetEntityState , like: var cmpPriest = Engine.QueryInterface(ent, IID_Priest); if (cmpPriest) { ret.priest = <...> } 4. Add a command into binaries/data/mods/public/simulation/helpers/Commands.js : ProcessCommand (this is what will be called by gui part): case "pray": <...> 5. Implement UnitAI functionality (binaries/data/mods/public/simulation/components/UnitAI.js): what unit should do in the praying state (i.e. generate resources after time intervals, this will use functionality from Priest component) Gui part: Add a command into binaries/data/mods/public/gui/session/utility_functions.js : getEntityCommandsList , like: if (entState.priest) { commands.push({ "name": "pray", "tooltip": "Pray for resources", "icon": "pray.png" }); } I'm not sure, but I think this should display a button under unit's portrait and bind click to it with sending 'pray' command into simulation part. In all these places you can look how other things around are implemented.

There is a public domain file, which indeed can be used as an Easter egg, it is up to our artists though.

Apple promise that it is not: http://www.apple.com/macosx/mountain-lion/security.html :

Currently the game is in alpha stage, so we just release installers/packages of full version of 0 A.D. for each new alpha every couple of months. Those, who want to follow development more closely can use the SVN version and update it whenever they want. In the beta stage it probably will be the same and AFAIK for open-source games this model usually used after alpha/beta stage too. Patch is something more related to commercial games world, with it's deadline rush before fixed release date, which is set be publishers without much taking into account the state of the project; then feature complete, but buggy release, complaining users/reviewers and a post release bug-fixing rush with 1.0.0.0.X patches. In open source games there is usually no one feature complete release, but rather incremental releases with either bugfixes and new features with relative long testing phase. And release will be rather delayed than released with known bugs or untested functionality. And all bug fixes and new features even if they are done after few days after release are delayed until the next one. We have a plan what features we want to have in 1.0 version and what features we can delay until later, so when all needed features will be ready we will switch from alpha stage to beta and work on fixing bugs/balancing etc. until the game will be ready to release, then we will release 1.0 version and theoretically there should not be any small patches right after this. We are not sure what will be next: 1.1 or 1.5 or 2.0 (i.e. how large will be changes in subsequent releases). As far as I understood ricotz does some 'update' packages in 0ad.dev PPA (Ubuntu packages). And there was some discussion on IRC about something like build-in update system, but we don't have any steady plans about it.

It gets fixed for me if I rename it into buildOffence.js (as other files named), the same with CivicCentre.js and TrainDefenceUnits.js, I don't know how it is related to filenames. There is also missing double-quote character in attack.js:319 and something else, what I don't have time to check because it's time to go to the work.

The game can be easily redownloaded/reinstalled, but you can't get your savegames back once you deleted them. In my experience games either don't delete saved games or explicitly ask about this in the uninstaller dialog. Our savegames probably not so worth as savegames of some RPG with tens of hours invested to gameplay, but still, we can get some unhappy users if they will reinstall the game by some reason and notice that they lost all their savegames.

Michael/Jonathan added them with the new attack bonuses system in r10804.

Maybe I misunderstood the problem, but why can't you check something like: ent.hasClass("Javelin") ent.hasClass("Bow") ?

Lets rename it into "Hard Code" and do all things via console.

Spahbod, you can just unpack your public.zip file too (so you will have a 'public' folder inside the 'mods' directory) and change files inside it, and game will use files from the directory.

Session gui layout is defined in the binaries/data/mods/public/gui/session/session.xml file. This particular block is: 337 <!-- ================================ ================================ --> 338 <!-- ALPHA LABELS (alpha, build time, revision) --> 339 <!-- ================================ ================================ --> 340 341 <!-- Displays Alpha name and number --> 342 <object size="70%-128 0 70%+128 100%" name="alphaLabel" type="text" style="CenteredLabelText" text_valign="top" ghost="true"> 343 ALPHA VIII : Haxāmaniš 344 345 <!-- Displays build date and revision number--> 346 <object size="50%-128 0 50%+128 100%-2" name="buildTimeLabel" type="text" text_align="center" text_valign="bottom" font="serif-12" textcolor="white" ghost="true"> 347 <action on="Load"><![CDATA[this.caption = buildTime(0) + " (" + buildTime(2) + ")";]]></action> 348 </object> 349 </object> You can try to add hidden="false" to the alphaLabel object, or comment/remove the entire block (in case if it is not referred from other code, I did not checked this).

It is more question how the looter component should work. Looter is called from the Attack component. If you kill your own unit using the gui command, it directly use the Health component, so looting is not performed. If you will kill your own unit by attacking it with other your unit, then looting probably will take place. But as far as I understood you can't order one your unit to attack another your unit. I suppose that this will overload the main screen area with details, but if we don't have other ideas I can do this and we will look how it works.

No, I was temporary very low active in the 0 A.D. development (busy with real life, tired by regular work etc.). I fixed some minor issues with the UnitAI, but not this part: In discussion with Philip I find out that it is currently hard to check the reachability of the target market, so I decided to keep it as is for now (trader will try to move to the market and discard order if it can't reach it). I implemented this: and added a coefficient to the trader component template, which allows to adjust gain for separate unit types (can be useful to make some civs better in trading or to change land/water trading gain proportions). Also I implemented tooltips on hover: they can display following states of a market: * "First trade market"; * "Second trade market. Click to establish another route."; * "Set as first trade market"; * "Set as second trade market. Gain: <number>."; I don't know where to place the tooltip area. For now I placed it above minimap, but surely it looks very ugly because the minimap/formations/unit info panels have different height, so my tooltip area hangs in the air instead of sticking to a panel.

Here is part of the Indentity.js file: 11 "<element name='Civ' a:help='Civilisation that this unit is primarily associated with'>" + 12 "<choice>" + 13 "<value a:help='Gaia (world objects)'>gaia</value>" + 14 "<value a:help='Carthaginians'>cart</value>" + 15 "<value a:help='Celts'>celt</value>" + 16 "<value a:help='Hellenes'>hele</value>" + 17 "<value a:help='Iberians'>iber</value>" + 18 "<value a:help='Persians'>pers</value>" + 19 "<value a:help='Romans'>rome</value>" + 20 "</choice>" + This is the definite list in the code file, this is why I said 'hardcoded'. But this is a javascript file, i.e. script, so Michael is right, you don't need to have developer tools and recompile the engine (an executable file) to implement changes, you can just edit this file with a regular text editor and your changes will be in the game. This is not much different from a config file editing. And if we will just move this list into separate config file (to not have it hardcoded in this sense), this still will not solve the discussed issue. More details about engine and mods support: 0 A.D. (as a product) consist from the engine 'pyrogenesis' and the mod ('public'). Engine compiled from C++/C/asm source code into a platform specific executable file. Mods are folders with resources, config files and scripts; they are platform independent and don't require to recompile the engine to implement changes. You can create your own mod with any civs you want. You can fork the public mod and add civs to it. The problem only arise when you want to add civ into existing public mod (i.e. extend public mod with your own mod). Even in this case you can copy the Indentity.js into your mod, add a civ into it and it should work correctly with the public mod. It is just not a perfect solution, because you will need to update your mod when the Identity.js is changed and you will not be able to enable multiple such mods simultaneously. We need a mechanism like what Ben implemented for setup screen: there is a separate json file for each civ (in the civs folder, and the loadCivData function in the functions_civinfo.js, so you can just add corresponding civ files into your mod and this will not conflict with civ files added by another mod. Hm, maybe I misunderstood something, but how do you add new civs in this case and what is this: <Identity> <Civ>celt</Civ> <SelectionGroupName>units/chin_infantry_spearman_b</SelectionGroupName> <SpecificName>Chang Mao Bing</SpecificName> <History></History> <Icon>units/chin_infantry_spearman.png</Icon> </Identity>

Do you want to copy a column from the table in this post? In firefox you can select cells with pressed 'ctrl' key, other browsers can have other methods.

Please note that I don't know much about such things, so it is just my dilettantish suppositions. If this is common for FreeBSD then in 'FCollada/FUtils/Platforms.h' probably should be a check like: #ifndef __FreeBSD__ #include <malloc.h> #endif // __FreeBSD__ As a workaround you can just try change 'make' to 'gmake' in line 47 of 'update-workspaces.sh' (and probably in line 64 too). Maybe you can do something before calling 'update-workspaces.sh', like turning 'make' into symlink to 'gmake'. It looks like it is not so rare problem (using GNU make files under FreeBSD), so it is better to search what people do in such situations.

Hello. From quick googling it looks like you can try to use gmake instead of make to build FCollada.

You can edit it in your local copy, but the question is how you will distribute your mod. I think you can copy this file into your mod and it should override standard (0 A.D.'s) one, but in this case it will be compatible with 0 A.D. only until it is unchanged in 0 A.D. and it will be incompatible with other mods which distribute their own version of this file. It is why I said 'Currently it is impossible to add more civs to extend 0 A.D. properly'. You definitely can find some workaround now, but for true support of moddable civilizations list we need to not hardcode it.