dvangennip

I know most of the behaviour is defined in UnitAI, so that would be my first step to check out (unless things have changed over the past year or so). The other change would relate to the GUI, so only three options are shown. I guess it suffices to simply omit two of the current five stances. Finally, there may be changes necessary to unit templates as those templates may set a default. If the name/string doesn't match, that may cause trouble of course.

I think different levels of detail are hard to do (lots of modeling work, not that many 3D artists are active at the moment I believe). And LOD works well when objects are both close (need high detail) and far away (can be low detail), as you might have in a first person view. The top down view of a typical RTS game like 0 A.D. has to have most of the things on-screen at the same level of detail because those are equally distant from the viewpoint. It would only provide a benefit once people zoom in or zoom out quite far. So I don't know how strongly this game would benefit from LOD changes, although that also depends on the amount of mesh complexity reduction that could be achieved. Keeping the extra meshes in memory (ready to be swapped in and out) also comes with some cost in memory. Instancing would probably have a larger impact as the average player will have many times the same building on-screen (such as houses, towers and walls), the same goes for the environment (trees are a good example). I'm no expert so I wouldn't be able to guess how much benefit may be obtained and whether it's worth spending development time on that (and drop support for any non-OpenGL 3.1 compatible systems).

There already is a model of the Colosseum in the game. It's an older model and not as detailed as more modern 'wonder' additions to the game. It also lacks proper texturing, but it would be a good base to work from in getting the Colosseum in game at some point. If you look at the actor viewer in Atlas, you should be able to bring it up. I included a quick render (untextured) in Blender below to give an idea.

Putting 0 A.D. on Steam has come up a couple of times, for example here, and here. Unless the team's position has changed, the perspective is that bringing 0 A.D. to Steam would require a more mature version of the game. The current work-in-progress state of the game might be detrimental to the public's opinion, which could hurt the long term prospects. I don't think it's ruled out for a (near) final version of the game.

I believe you should mod the civ.json file, which your mod probably has for a civilisation. There is something on starting units in there that you may alter.

?? That's one way of interpreting what's going on, but I guess for most people the fallen will look like they're deceased... At the very least, for the topic starter: units do not suddenly pick themselves up from the ground when new units are trained, instead they vanish after a while. I'm not sure if this behaviour can be adjusted with the regular, downloadable game. It's not an in-game setting, although with some file tweaking it could be possible to let fallen units vanish instantly so no death units are shown to linger around. To do so, within the game's mods/public/simulation folder, the file template_unit.xml should be adjusted slightly: <Decay> <DelayTime>0.0</DelayTime></Decay>DelayTime can be set to 0.0, so they vanish straightaway instead of after 80 seconds (the default). Other entities, such as ships and buildings, would not be altered. I assume that is less offensive to you? The only issue is that in the default download, all these files are zipped and use a compressed/compiled format that makes it hard to adjust. If possible, a regular (but tweaked) template_unit.xml file could be placed into the zipped package. Now I think of it, this would be perfect for a small mod that only overwrites the template_unit.xml file to achieve what you want.

The added easy level has been added to the code, but won't make it into the regular download version of the game until Alpha 18 comes out. In the mean time, players could access it if they play the development version of the game (which needs to be downloaded via SVN, and then compiled). The SVN route is not really recommended if you're not ready to deal with the technicalities, or would like to play games against other players online.

Have a look at the game's sources, it's there and indeed there's a new 2014 version of the theme music Music on Trac

Making the font smaller has other issues, and it's not exactly a large font at the moment, so there isn't much room to make it smaller. For long words where an English translation did fit an abbrevation may work better, perhaps with the full word in a tooltip on hovering the mouse over. I wonder how many instances there are where words do not fit? Perhaps it's good to get an idea of that, before considering alternatives.

Increasing the total width of the game window isn't going to fix column spacing and such, although it would give more space to play with. But I would opt for changing the parts that don't fit well with many languages, if there are such parts of the GUI. On the other hand, trying to fit German words into small spaces will always give some tension, given the propensity of this language to produce long, compound words It's one of the reasons I never used Dutch as the language on my mobile phones. Similar to German, long words are common and don't fit, so typically abbrevations are used. Those abbrevations often weren't obvious to me, so it was more confusing than just setting the phone to English. Still, abbrevations could be considered if those are clear to German speakers. On the resolution debate: please also consider that the numbers may lie about the useful resolution. A new MacBook Pro 15" may give a 2880x1800 resolution and seemingly be very safe for any cutoff, but it's simply 1440x900 with higher resolution imagery. It still fits the same amount of elements on screen, so for GUI design this 2x multiplier doesn't change much. It's a bit odd to exclude high-end machines like that (I also assume Windows-based laptops have similar display resolutions).

I believe doing another fundraiser might not really work if it cannot be shown that previous funds have been put to good use. So far, very little has been spent towards the development of 0 A.D., and it does not logically follow that more money will be effective. I expect people to be skeptic, especially as communication around and wrap-up of the previous campaign was less than ideal. I understand that the funds gained last year were not sufficient to have a developer (or two) work on the game for a serious amount of time (if I recall correctly the aim was $160K, something to the tune of $33K was donated), although that was the proposed plan. The two people most visible in the fundraiser have since left without much clarity around their departure, at least not via the channels available to those who donated (I wouldn't count the forums in general and IRC logs among that). I personally viewed my contribution as a donation, so I'm not too fuzzed about perks (not even sure if I opted for anything). While I'm convinced the team has and will handle the funds with care, a clearer picture of how the team intends to use the funds for development would help. Maybe something is in the works, it's just not that clear to a casual follower. As for the paid expansion idea, selling stuff that's open source is not going to work without any additional services or perks (licensing issues not considered). People would just download the source files, as that may be just as easy. The very small mobile operating system webOS suffered a similar issue, as its apps were very easy to copy and distribute illegally. webOS apps were built with open webtech, such as html, css, javascript. 0 A.D. mods are XML, javascript, and image files, making it similarly easy to copy a paid-for mod. It's very likely the limited gains do not warrant the costs.

If you open template_unit.xml (in simulation/templates), you'll find this piece on Decay: <Decay> <Inactive/> <DelayTime>80.0</DelayTime> <SinkRate>0.01</SinkRate> <SinkAccel>0.0</SinkAccel></Decay>You could simply increase the DelayTime or make it inactive alltogether. Keeping the slain units around does increase the amount of rendering that needs to be done, so it might have an effect on your framerate.

It can be done, but I'm not sure the added complexity is worth the confusion. You choose archers to have ranged troops, and swordsmen to have melee troops. Letting archers do both means the choice you have to make is less pronounced. I would argue against this idea, except maybe for some hero/champion units, as it negatively impacts the role of your strategic decisions. If you want archers, you have to choose and accept the negatives (no melee) along with the positives (ranged attack). My view is that this double attack-type idea doesn't aid the game. However technically, it can be done and the elements for that are partially in place. The animation part wouldn't be hard. A swordsman uses the same body and can use the animations as an archer to perform a bow and arrow animation. Given that both animations are necessary and available anyway, there is no additional animating necessary to let a swordsman use a ranged attack animation. The actor file readily supports this, including overwriting props to go along with that animation. So an archer can hold a bow in rest and its attack_ranged animation, and props can be reassigned for a attack_melee animation. In fact, this can be used now to give an archer a dagger to use for an attack_slaughter animation when dealing with domestic animals. In other words, the animation system supports different attack animations depening on what the UnitAI code requests (I was involved in the patch for that two years ago). There is some rudimentary support in the UnitAI code for choosing between different attack types. Domestic animals will always be attacked with a one-hit-kill Slaughter attack (which was implemented to ease the use of animals as a food source). I believe there is some code in place that tries to pick the optimal attack type to use if both melee and ranged are available. I think it takes the strongest of the two for a chosen opponent and just goes with that. Assuming archers do more damage as archers than by using their sword, the game will simply always use the ranged attack. If an opponent is too close for that to work (there's a minimum distance), the archer will move away and try again. Changing unit behaviour to favour a melee attack when too close for a ranged attack (instead of walking to increase distance beyond the minimum required), probably means your ranged unit is going to behave much like a melee unit, especially if enemy troops advance and close the distance (which is what any opposing melee unit does). Archers typically have weaker armor, so staying as far away as possible is a better alternative. Going by the numbers that's simply the best thing to do, and the UnitAI does so accordingly. I guess that realistically no archer would use a sword or dagger as long as the bow can be used. Only if it broke or he/she ran out of arrows it makes sense, but that doesn't apply in this game. Use torches for attacks against structures might be a nice idea, but I'm not sure if units will be changed to capture instead of destroy structures in the future.

That really depends on the moment in game (how many units are there at that moment? how many are moving?), how complex the map is (scattered obstacles such as trees really increase the time necessary to find a path), and some other stuff like that. I think if you press F11 a profiler shows, which indicates the time spent per frame/turn. If you press 5, it will show more detailed stats for the simulation update. ComputePath and ComputePathShort are the ones of interest. Early on, those have no impact on gameplay, but later on the inefficiency of the algorithm shows. Problem is, it's fundamental to the game and its behaviour directly affects gameplay. More than being fast, it has to be correct, so that needs a lot of testing, etc., which requires someone with both intimate knowledge of the game code and time to do all this.

At the risk of straying from the topic here, it may be useful to have a demo mod available with all kinds of interesting exemplars that modders can refer to. Tanks, planes, mages shooting fireballs, that sort of stuff which is not found in the core 0 A.D. units.

It would help if you could some more information. Which version of the game are you playing, on which platform? Which maps did you try, and what were the settings? Is there a way someone else could replicate your findings?

At the moment with version Alpha 16, I'm not sure Atlas is actually working on a Mac. I believe there are some issues that may of may not be resolved by now. If you would use a command line to start 0 A.D., you would use something like $ ./pyrogenesis -editor to start with Atlas, instead of the regular game. But normally, starting Atlas from the in-game menu should work. And yeah, there is no separate application. Atlas is the core game running in a different 'mode' (to put it simply, I'm not sure of the details).

It should be make -j3 (and just make will do as well, the -j<number> parameter determines the number of processes used). When you type make j3 you specify make to use a makefile with the name j3, which of course is then not found

It works now, see below... ------- I tried building as a loose binary, and did a forced rebuild of the libraries (which failed). Just to be clear, I do not have Xcode installed, only the command line tools. I just checked and my svn checkout has no changes or adjustments compared to the source. Yes, Mavericks it is (10.9.3). I tried that a minute ago, as follows: export CFLAGS="-std=c++11 -stdlib=libstdc++" LDFLAGS="-stdlib=libstdc++"Which quickly terminated the subsequent build-osx-libs.sh thusly: Building zlib...~/0ad/trunk/libraries/osx/zlib/zlib-1.2.8 ~/0ad/trunk/libraries/osx/zlib ~/0ad/trunk/libraries/osxpatching file configureCompiler error reporting is too harsh for ./configure (perhaps remove -Werror).** ./configure aborting.ERROR: zlib build failedIt seems to relate to the c++11 configuration. Just setting libstdc++ (instead of the now default libc++?) lets me compile, with the same error message. ----- OK, success I can now compile the libraries and the game successfully! I'm not setting any variables or standard libraries this time, but I had to make one small tweak to build-osx-libs.sh While wxWidgets was compiling I noticed it configured itself with 10.5 as the min-osx-version, as per its defaults. While there is a way to honour a command line parameter, by default someone wouldn't use that. Other libraries are now hardcoded to 10.9 using a mmacosx-min-version variable, but wxWidgets gets set via the MIN_OSX_VERSION variable which is empty by default. So adding on line 89 of build-osx-libs -> MIN_OSX_VERSION=10.9, it gets set even if the user wouldn't specify it. wxWidgets picks up 10.9 and compiles happily, if slowly I had a quick try and the game works as it should. Atlas does crash, and there is already a ticket for that (2650). Thanks for your help, it set me on the right path. I think I know why no else ran into this issue. Running the bundle script does set the MIN_OSX_VERSION variable, so wxWidgets would never step out of line. Perhaps the build-osx-libs.sh file can be amended so it works if someone goes for a loose binary.

I gave the current SVN version a go using the command line tools (Mavericks, no XCode installed) and I ran into a build problem for wxWidgets, a 'type_traits' error: Perhaps there is a simple fix for this, but I might have missed that.

Hi, it works by adding a <Pack> node within a unit's or structure's XML template file to indicate into which template it should transform. See the trebuchet for an example. The code of the patch adapts the entity Pack component handling such matters. Currently (the 0 A.D. code as it is now), can handle unit -> unit packing and unpacking. My patch would facilitate unit -> structure, and structure -> unit, so a civil centre to cart and back is possible. I'm not sure if this patch interacts in any way with the fixes by Sanderd17... There may be potential bugs in how it handles garrisoned units (because those need to be transfered to the new entity as well), and training queues. Other than that, it would support the kind of play you guys are discussing. When I did some testing, I did not really notice clear benefits from a moving cart and the transformation to civil centre. Having a unit walk over and build a civil centre is just as easy (albeit slower to construct). Within the gameplay of 0 A.D., having such movable civil centres allows for very quick landgrab, so that opposition cannot build their civil centre on your territory... unless the territory influence of nomadic entities remains small (that would be realistic I guess). More advanced structures such as castles do not fit well with the nomadic idea, so in end game situations I suppose a permanent base will always be favourable/necessary. Nomadic civs definitely require a rush strategy to work. One think I thought of back then was to restrict normal civilisations as to where those can expand or create new territory. If those could only expand (thus having a maximum distance between civil centres, not being able to capture land wherever they want), that would restrict their grip on territory and open up advantages for nomadic civs if those do not have such requirements (and can set up shop everywhere). I feel such a restriction would be necessary to make nomadic civs truly competitive at later stages of the game (also because defense and siege is likely weaker from a historical perspective, and fleeing to fight another day isn't really an option). A clear downside of this territory expansion restriction is that some maps might pose problems as there might be a minimum distance between civil centres due to landscape features (think large bodies of water, or mountain ranges). A civ would then not be able to expand at all, unless the restriction can be lifted for maps with large bodies of water.

Just as a note for anyone thinking of coding this: I did some work a year ago in preparing a patch. It's on trac as ticket #1919, and includes a (then) working implementation of packing and unpacking of structures into units and back. I'm not sure if it also accepts structure to another structure and unit conversion to unit. For anyone interested: It should be easy to get the code to work with the current codebase and see what bugs remain. I stopped short of implementing a proper GUI button placement (the pack/unpack button went on top of the first other trainable unit/buildable structure button). But it would be useful for truly nomadic civilisations to have this patch updated and added to the codebase. I remember there was some discussion back then to use a more generic Transformation component instead of the additions I made to the Pack component.

I don't think having heaps of RAM helps that much, the game won't use it. Having 2 Gb free should be enough, which is pretty common these days if you have 3 Gb or more installed. More graphics memory might help as well to a certain extent. These are the settings that I am using right now in local.cfg (never change the default.cfg file, as that might be updated on newer revisions, and user.cfg gets overwritten by the game when/after it's running). As you can see, this really is as bare as its gets. I keep silhouettes drawn to spot units behind trees or buildings (costs a small bit of performance, but I feel it is absolutely necessary to keep track of what is going on), but other than that this is the minimum. Note that this just improves graphics performance by reducing visual splendour (especially water looks less than great). Depending on your system the graphics performance may not be the bottleneck, though.

I guess a tournament as a way of attracting bright ideas for solving AI issues works when the problem to be solved is relatively simple. This means a reasonable amount of time invested can give some good results. In the case of 0 A.D. I don't think that putting in (let's say) 100 hours is going to give an AI capable of beating Aegis, because it's such a complex task. This is most likely the reason very few people actually work on the AI code, it just takes a lot of time to understand what's going on. That said, simpler AI's might focus on doing one thing very well. Maybe such an AI can't beat Aegis, but against similar bots it can give a nice tournament setting. If you would do something like setting a 1 month challenge for people to hand in their bot code, it might yield some interesting results. Of course, intermediate leaderboards could be nice; pitting the various bots against each other to get the scores. It would require a relatively complete basic API for the AI's to interface with the system for getting data and pathfinding and such things (I'm not sure how this is currently split between basic AI and Aegis AI). For example, one bot could aim to win by simply rushing with starter resources. It might give a win every 4/10 times, which perhaps is as good a result as another more complex bot. That would be interesting to see. Not because of Aegis crushing performance (I'd be surprised), but it might yield some insight in the various ways to create a bot for 0 A.D.

You want to run 0 A.D. in a browser Or do you want to do a remake in a browser? I would not use data URL's for images. Just have them served statically as jpg files helps with caching.Similar to using javascript: put all javascript in a separate file (or files). It's easier to edit and no reload of the data is necessary upon subsequent visits.I don't know if webGL supports everything OpenGL does, but since 0 A.D. uses an older version it should not be a problem.You will run into problems with all the C++ code which you would have to translate to javascript. I don't that's fun or will run well at all (sssllllooowww).You'll need to implement a different way of interpretting the game's XML data, which could be done in javascript. It still requires a lot of work.Quick load... hmm, most of the loading probably goes into XML files, 3D models, and texture images. So the loading will be similar to downloading the game.I'm not sure if you are really playing to do this, but it would take considerable effort. Good luck though