dvangennip

Many places in the world have data caps, that is limits on how much you can download. From your nickname I take you are Dutch, and caps do not exist there. 10 Gb per day is feasible and no problem. However, elsewhere you might find that 1 Gb per week is the maximum (or even less) and perhaps not that easy to reach. So downloading 0 A.D. means you can't do much else

It could be that your gift was used by the opponent to construct a defense tower instead of a civilian unit. Maybe that decision was still in the queue waiting for resources to actually be built. Once that happened it triggered this error which probably relates to any limit for the total number of defense towers a player can build. Did you mod that at some point? Were there any errors upon starting the game (when importing entity templates)?

SVN can be used for incremental updates, as Sighvatr says, but it requires quite a bit more than 500 Mb 2 Gb at the least (takes all source files first, after that it can update changed files only). That of course excludes any necessary development environment (e.g., Visual Studio, XCode, gcc) which may need to be downloaded and configured as well (although on Windows it shouldn't be necessary). If data caps and/or a slow connection are the issue SVN does not help much because of the high initial download volume. If ease of use is an issue the SVN version is definitely not better

Yeah, that is quite unsatisfying given all the work and thorough analysis put into it... It's certainly an interesting finding for JS engine devs which goes against most expectations. I don't know if there is a venue to share some of the insights as a way of sharing the fruits of your labour? Hopefully the work makes it somewhat easier to transition to newer SpiderMonkey versions in the future which may deliver some marginal gains.

Why? As far as I know Egyptian armies have often included mercenaries, among them Nubian archers. Perhaps not in every timeframe (I would suspect they were less keen on having them around surrouding the time of Kushite occupation, ±700 BC). If there is no historical basis for these archers, would you have a correct (preferably ranged) alternative?

Thanks for the info. My proposed sqrt function doesn't actually work with 64 bit integers as input, so for now it's off the table. Still, I found that for a 10k sample of input values (logged from actual gameplay) the std::sqrt function gave exactly the same results as isqrt64 (and is 4.5x faster). I had my test code calculate sum of squared errors and it gave 0 for the current isqrt64 implementation versus std::sqrt. If that outcome equality holds true for all other relevant platforms it may be better to use std::sqrt instead, assuming its implementation is faster on all relevant platforms. I won't be able to test this myself (as I only have access to 64bit Intel Macs), but I attach my code and input samples file for anyone willing to do so. If the sum of squared errors for isqrt64 is higher than 0 anywhere (I set std::sqrt as the baseline), it can't be used due to potential out-of-sync issues. At the very least compiling for 64bit and 32bit gives the same results on my system. Edit: perhaps this is better fitted in a trac ticket, so it's not lost. I'll do that later. sqrt_test_with_samples.zip

Ok, I got the game to compile now. Specifiying the c++ libraries is probably doing the trick, as may indicating a OS X version minimum target lower than 10.9. For those interested, I commented on the relevant trac ticket #2304.

Weird. I added a zip file now, hope that works. Perhaps an approximate method can be added alongside the more precise one for when speed trumps accuracy. I'm not sure in which circumstances the square root function is used, priorities could differ in some cases.

This feels best at place here, as it is a response to the comment right below, although it might need its own thread. I happened to come across this piece on Wikipedia on methods for computing square roots. I gave it a try in C++ and compared it with the function currently used in 0 A.D. (its own isqrt64 implementation) and std::sqrt. In my simple test code it turns out to be faster, much faster (sqrt_approx functions). And even the standard library sqrt function appears to be much faster, so it seems there might be room for improvement: Testing different square root implementations.SPEEDstd::sqrt = 0.28508isqrt64 = 1.26607sqrt_approx = 0.085709sqrt_approx64 = 0.114492It is an approximation, so the speed improvement comes at a cost of accuracy (see the spoiler below; although any error is stable and may matter less in a game situation compared to a true simulation). The error can be adjusted by manipulating an extra variable, and should generally be around 4% (the list below omits any correction as it gives worse results for small numbers). I haven't been able to try in the game code by adjusting source/maths/sqrt.cpp, but that should be easy to do. Even then, these faster functions may not be usable due to the need for stability across platforms/processors/etcetera. The currently used isqrt64() and this approximate function are both based on bit shifting so perhaps that is more stable across systems. As I didn't test anything in game, I haven't made a ticket/patch for this. However, if the approach seems promising I'll do that. sqrt_test.cpp.gz sqrt_test.cpp.zip

Nothing I haven't had the time to work on it, and for the past few months 0 A.D. won't even compile any more (thanks to OS X Mavericks being difficult, making progress impossible on my side). The patch you are referring to would help nomadic units that can transform from building to unit and back. As those are not yet to be found in the main game (nor any mod I'm aware of), this patch resides in the backlog for now. Previously it had been moved from Alpha 13, to 14, to 15, without too much progress. It can be picked up and worked on if the need arises. In short, I wouldn't put it back on the list for the next Alpha unless someone volunteers to work on this.

Are you using the regular Alpha 15 (so not any self-compiled version from source code)? Perhaps you can upload the crashlog.txt and crashdump files, so the developers might be able to pinpoint where the problem occurred. Info on all that can be found on the wiki: Reporting Errors.

This can already be done. Look at your configuration file (see full info here on the wiki, don't use the default.cfg as it will be changed on any update) and set your desired resolution: windowed = truexres = 1024yres = 768I don't think you can set a resolution lower then your display's native one and still play fullscreen. Still, this settings stuff would be a nice addition for Alpha 16, especially when higher quality graphics (thanks to OpenGL based shaders) are enabled by default. It would be easier for people to tune the game to their liking and their computer's abilities.

It may be good to include a way to indicate a new version is available, plus give the user the ability to directly go to the website (download page). This can be put somewhere in the main menu, I suppose. Releases are not that frequent to become really cumbersome to go to the website each time. An actual updater is way more difficult and prone to errors. Fiddling with svn/git is not an option for regular users due to the need for having svn/git installed first, and having to do the compilation second (which is error prone). Plus, the svn version requires quite a bit more disk space (±550 Mb for the regular OS X dmg package, my svn checkout is closer to 7 Gb). As for what could be in A16: I assume the updated GUI will see a further rollout, although it's not mentioned so far in this thread?

I believe one of the strengths of the Achaemenid Persians in 0 A.D. is strong buildings. The proposal for part 2 lists Parthians, perhaps Scythians, Sassanids, and (non-Persian) Huns. So in the future it's likely there will be nomadic tribes It would be a good way to set them apart from other factions in terms of gameplay.

What would be the best way to set clang with libstdc++? I suspect doing that may help me to get 0 AD built, but I'm not really an expert on compilers and premake. As far as I can see this is not yet the default setting (?), so I made this change to build-osx-libs.sh which compiles without issue: #export CC=${CC:="gcc"} CXX=${CXX:="g++"} # commented out for nowexport CC=${CC:="/usr/bin/clang"} CXX=${CXX:="/usr/bin/clang++"} # added additional flagCPPFLAGS="$CPPFLAGS -stdlib=libstdc++"A similar adjustment needs to be made to the premake file, but this is less clear to me. I'm not sure how to set CC and CXX here to clang. The generated makefiles list gcc and g++ (although the terminal window title shows it is using clang). So far I've tried this to set the stdlib: (this is around line 345)if not _OPTIONS["minimal-flags"] then buildoptions { -- Added the stdlib part "-fvisibility=hidden", "-stdlib=libstdc++"}endI accidentally submitted my post while this change is still compiling...... Aaand, it failed Most stuff compiled nicely, it seems to get wrong at the final step. I guess that's progress This is the error from the build process: ==== Building pyrogenesis (release) ====Creating obj/pyrogenesis_Releasemain.cppLinking pyrogenesisld: '_SDL_main' in obj/pyrogenesis_Release/main.o contains undefined reference for architecture x86_64clang: error: linker command failed with exit code 1 (use -v to see invocation)make[1]: *** [../../../binaries/system/pyrogenesis] Error 1make: *** [pyrogenesis] Error 2Slight edit: manually updating the generated makefiles to use clang/clang++ makes no difference. The generated pyrogenesis.make reads as follows. I'm not entirely sure the compiler flags are set correctly, or would some other issue be bothering me?

No, you don't need to download the public mod, although it is one solution. The alternative is to reset the svn copy to the state of the original repository (thus, the one WFG hosts). In both cases you'll loose your own changes, but not any newly added files. Because of that it is handier to work in a separate mod folder. Any file found in a mod overwrites the data from a file in an earlier included mod. So let's say you want to mod simulation/templates/structures/egypt_mill.xml, it is best to duplicate that file in a mod separate from the public mod (of course, file structure needs to be similar, so the duplicate would go in yourmod/simulation/templates/structures/egypt_mill.xml). In this case though, all you might have to do to get rid of the error is to open the egypt_mill.xml and look for the parent XML file it points to. Without it its data is incomplete as it inherits data from that parent xml file, hence the errors. Simply put, the game engine takes the file, looks for any parent, takes that data if there is a parent xml file and overwrites any values from the parent with those in the current xml file. In this case the parent info should say: <Entity parent="template_structure_economic_storehouse">The name of this xml file doesn't matter much for the current error. Of course, any unit that should be able to build this structure needs the correct name

As Sander said, check the template files which currently give errors. The messages do not relate to this specific map. Somewhat off-topic: Any modifications would be better at place in a separate mod folder, next to the public mod. This mod can then be included at launch or not, which makes it easy to run the game vanilla without requiring a separate svn copy. Any changes made in svn would also not overwrite or conflict with your changes (although those won't be incorporated either in a separate mod folder). Running different svn copies seems superfluous, atlhough I see the point once you're altering the to-be-compiled source code. Once WFG has migrated to git it should be an easier process to use different branches, reducing the need for svn copies in different places.

It might be helpful to ask people (in a separate thread perhaps) what they look for in the summary screen at the end of a match. I usually compare my resource gathering with the enemies, just to see if I was quicker or better at that (early on I tend to be slower than any bot, for example, so I'm weakly prepared for rushers). Doing so would give insight in the why and what questions As for graphs: could it work to draw any graph in a buffer or to a temporary png file and display that? That way graphs can be used in the GUI without many changes, provided the drawing to a temporary file is easier (something I don't know about).

As I was working on a mechanism for transformable CC's (into carts and back into a building) for nomadic civs some time ago (not finished yet), I wondered what the benefit would be of having such a mobile CC. Currently expansion can be done anywhere as long as you have the resources, plus can get the construction work done (which means units have to go there). One thing that could bring interesting gameplay benefits to nomadic civs is if they could indeed set up shop wherever they want (that is, wherever they could get their CC cart), while other civs could only build a CC not too far away from another, earlier built CC. Thus, there is a clear maximum for distances between CC. I can see some issues with my idea, the most important one is that some maps may limit options for expansion (think of the islands maps). Introducing a max distance could mean there is no suitable location, severely limiting regular civs. As an alternative, giving nomadic civs a similar benefit would be to do away with territory restrictions in general or lower their mobile CC cost (facilitating rapid expansion).

Armor is the defense of a unit. In the case of a human entity, this means his or her clothing, a shield, helmet, and so on. A spear or axe is the weapon (that is, offensive, not defensive) and is unrelated to armor. Assuming you want to adjust a spearman into an axeman, you would have to adjust the Attack properties in the entity's XML file. It is probably easier to let a unit inherit from a generic axeman template instead of the spearman template it is probably now inheriting properties from. In the related actor file the right hand prop has to be altered as well to an axe, plus the attack_melee animation has to be adjusted. I would look at an existing axeman unit and copy those values.

Thanks, that helps me get past the problem I keep running into things though, which makes me wonder if I'm the only one using a clean Mavericks install with just the (late October 2013 version of OS X Mavericks' specific) Command Line Tools, and having trouble? If I am the only one, sorry for bothering you all with my issues.. But I hope it is of help for other people on Mavericks. Currently the build process fails at ModelRenderer.cpp with 20 errors that seem to relate to the command line tools. See the example (the first error encountered) below, and the error log attached. ModelRenderer-errors.txt

Adjusting the folder permissions seems to get the libraries to build. Thanks for the tip Building FCollada on Mavericks does generate a lot of warnings about deprecated stuff though. If you are interested, I saved a log of the terminal output. For now, I assume that will be amended upstream at some point.. However, the game still won't build. Now, I run into a similar issue with some other file. Again, the file exists. The permissions also appear fine, but I have to check and try some more. The permissions might still be a little wonky, although that shouldn't be an issue for new folders generated by the library compilation (?). This tr1/unordered_map file is part of the boost lib, btw. Compiling that library did not seem to give any errors.

I think the priests as healers are a game mechanic, which a player can use to buff her army. Having healers then becomes a strategical choice and opportunity to change the odds in a battle. Essentially, if two similar armies get into a fight, the one with healers will last longer and win the fight (even if the opponent goes for the healers first, leaving them vulnerable to the army's soldiers). While there may be no historical basis (as asking for help is not the same as actually healing someone), I think this is where a game can (and should be allowed to) deviate from reality to make the game more fun and deepen the tactical possibilities. Healing adds a restorative element, next to the damage dealing of the soldiers themselves (similar to the RPG trinity of DPS/tank/healer). If you do not agree, I'm curious to learn why not? How would you see the priest's role?

I tried compiling today on a fresh install of OS X 10.9 (Mavericks), with only the Xcode command line tools installed and cmake (no Xcode installed). I put back a copy of the 0ad svn from my earlier 1.6.8 (Snow Leopard) install, and updated svn to the most recent revision (#14154). As a first step, I cleaned the workspaces and tried build-osx-libs.sh with the --force-rebuild flag. All goes well until it gets to FCollada, at which point the compiling fails. Of course, I never got to compiling the actual game. Trying the build-osx-libs.sh again, simply reports that it skips building FCollada, as it would be already built (it seems wrong to flag a lib as built when it failed to do so). As far as I can see, the other libraries were built successfully (FCollada is the last one in the list). The 'unopenable file' from the error message does exist though. If you know anything I could try to get it going, let me know

Yeah, that's an issue. I'm not sure what the best way of doing it would be, unless there was some sort of splash image / GUI where mods can be activated before loading pyrogenesis.