sanderd17

There are ways to solve this. Like we can provide a zipped git repo that you can just unpack to get a (slightly older version) of the git branches. Those separate files can be distributed in any format, and can also be resumable. I think we should release a zipped git repo on every alpha release. So people can just download that, and manually update to the current git revision. We could also split the git repo in several repos, though that'd add more management issues.

AFAIK, the game just doesn't read this tag. It just assumes everything is in meters. The only thing you have to watch out for is that the tag used in the exported file is the same as in the imported file (I think by default, most programs use meters to export, so if you import a collada file with a different unit of measurement, your 3D program will scale it to meters on export).

I think we can take inspiration from existing schemas, s.a. the Arch Linux PKGBUILDS: https://wiki.archlinux.org/index.php/PKGBUILD Instead of Bash, we're more used to JSON. Something like { modName: "Millenium AD", // name of the mod that will appear in the GUI modVersion: "0.0.1", // version of the mod url: "http://moddb.com/myMod" // link to your mod page engine: ">0.0.15" // Minimum version Alpha 15 required source: "http://my-server.be/milleniumAdMod-0-0-1.zip" // Download of the zipped mod depends: ["someNiceGuiMod >= 2.0"] // list of mods this depends on, with optional version information (using >, =, etc to denote minimum and maximum versions) sha1sum: "..." // checksum for security // other keys: "provides", "conflicts", ...}With this scheme, WFG only has to host those small text files. While the actual downloads are on other servers. For users, it's still safe if people can only modify their own mod file, and by using the sha1sum. We can also make sure that the mods are loaded in the order required by the dependencies (and alphabetically otherwise).The base file name should probably be the same as the mod directory it installs to, to avoid mods overwriting each other, and the file should probably be present in the mod root directory (so we can still check dependencies, even when offline)

If you use photo's to texture stuff, you must obey to the license (even if the photo is under CC-BY-SA, you still need to mention the source or original author). If the photo isn't available under a free license, you can only use it for inspirational purposes.

And what were those errors? The script is just stopping because it doesn't recognise the "--with-system-enet" (which is wrongly interpreted as a command for some reason). You can't run into this problem when just using a terminal. EDIT: also, can someone turn place that log after a spoiler, or move it to a paste site? The forums don't react when I try it.

Thanks for your work. Looks like the tickets are completely removed from history now.

Translations for the project can be found here: https://www.transifex.com/projects/p/0ad/ They're not included in the current version, but we will include some good translations in the next version we release (see the latest announcement). And I don't understand your remark.

It looks like a weapon shield to me. The wrench and the M are quite clear to me, but I don't find the C. It looks nice to me, also very recognisable at small sizes.

I do see that the script has problems with using '\' to unmark the line ends. You could put those arguments (like --with-system-enet) on one line instead.

If you're using a package, it's the responsibility of the puppy maintainers. If you use a source tarball, we need to know the steps you followed to compile.

The output is too big to find the issue. If you would build the project as lined out in the wiki (without codeblocks, without cleaning between the builds, and with the default options), it won't rebuild the stuff it already build. So you won't have all those useless logs and warnings, only the real errors.

Could you share the errors with us in that case?

I don't see any errors, only warnings with a 3rd party library. Is something not working?

I'm sorry, but your post is very hard to read. It looks like you're throwing all sorts of suggested and even planned features on a pile. In any way, when we have triggers, map makers will be able to do all these sorts of things. (except capturing, as that's not implemented yet).

Maybe that's the same (admin Utility and regular Utility)? I don't know this specific issue. Forwarding ports is indeed opening a small gate to your computer, so it is a bit more dangerous. But I don't expect any problems. As long as no applications are listening on it, not a lot can happen (your computer won't process the messages it gets). And if an application (like 0 A.D. in this case) is listening on that port, hackers can only change 0 A.D. behaviour. Which means they still have to find a hole in our code to exploit that before they can access other parts of your computer. As we have very few players (and even fewer players that forwarded the port), it's not worth for hackers to find an exploit in our app. Off course, when we know about an exploit, we will try to fix it as soon as possible, and when more players become active, we will need to have more people working on security. But I don't foresee problems in the next few years.

Following the minecraft-server guide will work if you replace the port they use (25565) with our port (20595).

Athenians can do that too, and mauryan warriors can be trained from a hero elephant. It's not really a problem for me. We make abstraction of the entire grow-train-fight cycle. It's just a nice trait some civs have.

FexoR, you're working on terrains, right? The log you posted now complains about a missing terrains.xml. Something you modified there?

That's because it's compiled without Atlas. Did you compile it yourself, or where did you get it?

There are still multiple ways null pointers can get into our code. The problem with yours can be related to something we don't initialise, a file that's being read too slow, or something else. And it can be totally unrelated to the other issue.

@Stan: not for Niek. Third question, can you bisect SVN to see which commit caused it the first time?

This is just a null pointer (and the logs don't tell where it comes from). Is there any way to reproduce this reliably? Also, are both of you using windows? I might be a Windows specific issue.

Hi, nice to see someone applying to program on the graphics side. As a programmer, it's not really needed to apply for a position. You can just start working on something you like (either something you want to improve for yourself, or an existing ticket). Then you can submit it for review, when it's good (coding style, performance, added features ...), it gets added to the game. Then after some time working like this, programmers are invited to become part of the team (basically, that's just getting commit access). When you want to discuss something with us (ask help, ask for a review, ...) or if you just want to chat, you can join the #0ad-dev IRC channel on QuakeNet. We're mostly active during American day and evening. Some links that can help: Guide to submit patches: http://trac.wildfiregames.com/wiki/SubmittingPatches (don't hesitate to contact us personally on IRC too) Beginners tickets (those don't require a deep knowledge of the 0 A.D. source code): http://trac.wildfiregames.com/report/16 All open tickets: http://trac.wildfiregames.com/report/1 General documentation, getting started stuff: http://trac.wildfiregames.com/wiki Thank you again for wanting to help out.

What build options did you use? Plain "build_workspaces", or make with some other options? You should check the dependencies (if you use system nvtt, you must make sure it's installed), and give the complete log if possible.

Ubuntu is updated twice a year, in October and April. Mint is based on Ubuntu (at least their main version), so they update their version a bit after the Ubuntu update (normally about a month later). But with most software versions directly from Ubuntu. As in October, A14 was the most recent version, that's the one you will find in Ubuntu and Mint. During those 6 months between releases, only bugfixes or security problems get updated. No new features. Also, because Ubuntu is based on Debian, they take most of their software from the Debian repos. So if you release software in October, it won't make it into the October version of Ubuntu.