leper

(Thanks for the bump.) As it seems that you are using an SVN checkout you could just pass -writeableRoot to the executable, and have all data in the same place as the game itself. If you'd be using a *NIX system that adheres to the FreeDesktop Base Directory Specification you could set XDG_CACHE_HOME to your prefered path (and even do that just for pyrogenesis/0ad by using an alias or a shell script that does that for the launched command). On all systems you can just create a symlink that replaces the default directory to wherever you want. On Windows this can be done by the mklink command (and I assume you'd want to use an NTFS junction point as you want a different volume) as far as I can tell from the available documentation.

And both of these support sharing libraries too (though in the former case you might end up with a quite large WinSxS folder). Not new, rather decades old. I did not use the static linking moniker without a reason. You can just build something statically (though that ignores what to do with the data) against some quite old (and thus supported everywhere) version of glibc and have it run on most Linux distributions. However both that and these bundle solutions have the same issue as you have possibly multiple versions of the same libraries stored (not a huge issue nowadays with FS compression and deduplication, and huge amounts of storage space available) and have to rely on whoever created that bundle to provide security updates (and I doubt a lot of those have someone responsible for tracking security issues in libraries; while most distros do have that). I do see the appeal of having something that should work everywhere, but then again nobody forces anyone to use a distro that lives years in the past with regard to shipped software. In that case you should create one image (centrally) and mirror that to all the boxes, or even boot of a NAS caching used files locally. That way you have less work administering the whole thing and can spend more time beating your regulars at the game.

Moved this out of the announcements forum to a better place (as that one should be about WFG announcments, I'm sligthly surprised that you could start a topic there). We do provide a ppa, that provides updated versions of the game for Ubuntu versions and doesn't have the shortcomings of emulating static libraries.

(I guess I should write a slightly longer answer to this and related questions since this seems to pop up regularly.) TL;DR: SVN works. Why don't you use git, you can do so right now (either one of the clones on github/gitlab, or via git-svn)? Why (still) SVN? It works. More details: Partial checkouts are supported (which some contributors needed due to network limits), it doesn't require users to download the whole history (same reasoning), checkouts can be resumed (helps with unstable network connections). Apart from using shallow clones or incremental shallow clones this isn't possible with git. Keeping autobuilds for windows users (which is needed for artists) in the repo is not an issue (yes, there have been discussions and plans for how to solve this for git; but that is some work nobody has volunteered for yet). Why not git? There's a git clone (github and gitlab) so nothing stops you from using it right now, and we do accept git patches just the same as svn patches. If you don't like that you can use git-svn directly (which works fine). Educating users about git is more work than doing the same for svn, also this question ignores artists and modders and increases the barrier of entry for new contributors. Also most git GUIs are quite bad, which is somewhat important for those users. Programmers should be able to use their tools and can already use git right now. Why not git-lfs or git-annex or git-whatever? Those are third-party extensions and require more administration work. Of course we could move all to some third-party hosting platform, but those might impose arbitrary limits or just cease to exist. Also that seems to counteract one of the main advantages of a DVCS namely being distributed and not being locked to a single central repository. (These approaches tend to have issues with having the full history available locally, which makes bisecting issues harder. Also they do list merge conflicts for binary files as one of the rough edges. (I'm not sure how those would interact with signing commits, which would be one of the things to consider if switching to git.)) But I want to submit pull-requests? No. Diffs work, man git-format-patch might be worth reading. Why not just merge things? A merge-based workflow creates issues with bisecting issues, so one would have to educate users about rebasing their work on top of the main branch. (Not very entertaining in the long run (and that refers to both points).) What could be done instead? Reroll the git clones in a nicer way by excluding all build artifacts (the current clones have a few incremental stages, and are likely not excluding everything). However this should be planned carefully, since this is going to break the "upstream" for a lot of people and I would strongly recommend against doing this more than once.

Why would a balancing (and art, and maps) mod need to ship that, or components for that matter? Then again I'm not sure why it claims to have no dependencies, when it quite obviously depends on public.

Likely that forum post, related IRC discussions, and the fact that creating a square map in Atlas requires you to edit the map file by hand for quite a few years.

Lack of polish, inconsistency, them not really being needed. Non-circular maps are also still working, but it does seem strange that we do consider them to be deprecated and then make use of that for new maps.

That does seem quite unfortunate.

Square maps are deprecated. So no, they will not be added back.

The tutorials are broken. There are multiple tickets about bugs in them (#3678,#3723), and one about rewriting them to actually use triggers (#2303) instead of the custom AI hack that it is currently using. But apparently someone decided that working on those isn't possible unless #3912 is fixed. I do wonder how we managed to create tutorials without that functionality in the first place, and why making a few things a bit clearer for people that have never played an RTS and are unable to read tooltips can't be done later. Especially since that should just be adding some highlighting to the strings that are needed anyway. (And if that one is really blocking work on tutorials I'm not sure why #1446 isn't listed as another blocker.) So we are aware that the tutorials are broken in many ways, and I'm quite sure that if someone would be willing to work on creating a new set of tutorials using triggers that would be very appreciated.

There was an automated unit balance tester written by quantumstate a few years ago, that used a custom map to place units so they could only attack the units they were tested against, plus some hacky code to get the results of that printed into a file, which was then displayed on some website. The code for that was never released, but it did have the obvious benefit of actually testing what happens in a game (as compared to purely template based comparisons). I guess doing something like that with triggers would be a bit easier.

The latter is part of the VisibleClasses list of the Identity component, which is split by whitespace, so there is no way for the latter (without some code changes that seem to be worth it, unless someone is bored) to have a space. This limitation doesn't extend to translations so you can just translate it to be the same.

We desperately need a (feathered, because we do value accuracy) velociraptor that is then player controlled and can be spawned by a cheatcode ("It's a UNIX system! I know this!"). I might have been asking people to make that for years, maybe someday someone actually will do that[*]. For other animals we should (or do already) include at least an extinct elephant species, and I guess woolly rhinoceroses and mammoths would be nice to have for some mods. Also a great RTS did feature time travel and dinosaurs in its campaign, and a few strange units might be nice for mods or maps (invasion, tower defense, ...). [*] Bribes possibly available.

By reporting packaging bugs in the right place so that it gets fixed for everyone instead of using workarounds and not reporting anything in a place that will get that fixed. Also reading relevant discussions like [1] and following the advice therein which would take you to [2]. While you're at it you should probably also file a report about fixing SpiderMonkey issues with GCC6 [3][4] (but then again all possibly affected packagers should be notified of that). Though whoever does that should take care to point out that only those flags should be added and no other changes to them should occur (given that the commit happened after the SpiderMonkey 38 upgrade). [1] https://lists.archlinux.org/pipermail/arch-general/2016-November/042407.html [2] https://bugs.archlinux.org/newtask?project=5&product_category=33&item_summary=[0ad]+PLEASE+ENTER+SUMMARY [3] http://trac.wildfiregames.com/ticket/4053 [4] http://trac.wildfiregames.com/changeset/18801

The easily exploitable part is most likely fixed by now, or shouldn't be hard to solve for someone knowing that code. Not sure how to make it obvious to players, but I planned to use it on the trade route map (for the trading gaia/AI player) as most of the required code (apart from allowing to issue the right commands from the gui, and maybe some small adjustments in the command handlers in UnitAI) was merged in #3812 (and lots of later commits, and likely some cleanup is still missing).

Split from the units upgrade topic.

That might be a futile endeavour given #3934.

That could be an issue with being allowed to redistribute mods, also someone uploading something who doesn't have the rights to do so. Automatic scans for not yet known things are useless. Being able to disable automatic downloads is a necessity if someone actually wants to do something like that. Scripts shouldn't be able to access the disk directly, but given the possible number of exploitable bugs in the code that executes them (which is partly due to no thought being given to doing that with untrusted code (and running untrusted code is not something one should really do anyway)) and the used libraries.

Signing mods also won't fix the use-case of someone just making a map and others being able to download it right afterwards. Also given that maps and mods can execute nearly arbitrary code (some limitations in some places) I would consider adding automatic downloading of that a security issue.

Took that survey.

Thank you!

Can we get the source files added to the art_source repo?

Which still ignores the fact that the DAE files aren't the actual source files and there have been issues with importing some of those for modification. Also someone wanting to modify some meshes should preferably do so by using the actual source files which should be in the art_source repo, so increasing the size of the public mod by a third without any actual benfit seems pointless and will stay pointless.

Because find binaries/data/mods/public -name '*.dae' -print0 | du --files0-from=- -s -c -h | grep total 484M total that seems like a lot.

Yes, the XML files aren't really needed, but are kept so modders can easily check what templates are used and possibly fix only a single one without requiring them to get the file from the repository. Also the XML files are not that huge, and in case we ever want to update the engine (possibly including updates to the caching format) we can get away with not updating the mod data (the engine would then notice that the cached files are not what it expects and just cache them anew). So we could remove the XML files from the packed release, but I'm not convinced if that would really make anything easier and will likely make one of the few things you can actually mod for a release harder.