feneur

Well, I honestly doubt he's counted them, so unless he says otherwise I'll assume that he's just looked at the pop counter

It depends on what civilization you're playing as as well, some civilizations get a larger population limit, some a smaller.

The next Alpha release is not too far away, but the issue of being able to save games with an AI will take some more time. It's one of the more difficult issues to solve actually, so it's impossible to say how long time it will take. Probably more like December or early 2014 than soon. The AI should work fine in Alpha 14 if you just want to play a game though, it's just saving the game that will take longer to figure out.

Yeah, there's no reason to be discouraged to try things out I doubt something like this will make it into the main game, but if it is implemented as a mod and people enjoy it at least it will be a positive thing for them

It sounds like something that could be useful for testing things.

As I don't read code fluently =) I need to ask, if you just enter the code by itself, does it still convert to the player? (I'm assuming you convert to other players by entering "wololo 2", "wololo 3" etc?)

Most of what you want to do can probably be done via editing the XMLs for buildings/units + techs.

Of course there should be I think Michael's point is that it would take a lot of time to implement that properly, but we might want to have something simpler in the mean time (If you want to tweak things for now you can use the cfg files )

That was quick indeed

What's sad about the Rise of Nations campaign map?

Just went through the registration process in Firefox (though on Windows, so might not be 100% the same), and I didn't see any issue with it. You do have Javascript enabled I presume? It would probably be helpful if you could take a screenshot of it as well, when I tried to resize the window it still showed up fine, so it certainly doesn't seem to be a general FF issue (but again, I don't know how similar FF on Windows and FF on Fedora is, so that might not be too relevant).

I think it might be wise to consider that such a brush could be used for other things than forests. I mean sure, forests is probably the most likely, but unless there is a good reason not to I think it should be possible to paint with any entities the user may like. Perhaps the selection could be limited to trees by default though, to make it less confusing for new users.

Actually, no, they're not. Many tracks do feature both real, live instruments and computer generated music though.

It's just not been done yet, they will definitely have animations before the game is released though. Animating things is one of the hardest things you can do though, so it's not something as many people can do + it takes quite a lot of time, so it might be a while before all animals have animations. Also, we might not be able to animate all animals that have models made for them, but elephants definitely are important enough that we would not consider the game completed without them

Well, since 0 A.D. uses OpenGL and not DirectX this is not relevant to us. It was just an example he listed.

The files are hosted on SourceForge already (and was at the time of this post as well), but we link to them using releases.wildfiregames.com. The problem was that the server where the releases.wildfiregames.com page and URL is was down when this post was created, and thus the link to the downloadable files didn't work either despite the files being accessible via SourceForge the whole time. There isn't, and we haven't discussed setting up a mirror actually. It hasn't really been any issues with the web site, and if it doesn't work we always have FB/G+/ModDB/IndieDB/Twitter/IRC and of course Trac (which is on a different server) so there are plenty of places to stay in contact with the project even during down-time. That doesn't exclude making 0 A.D. available there as well, but the main reason we haven't tried getting 0 A.D. on Steam (or Desura for that matter) is that we feel that those platforms are more suited towards finished games, or at least Beta. It's definitely something we will look into once the game is more mature though. It will always be available in other places though, even if it's also available on Steam or Desura. Yeah, the main reason is that there is no need to use torrents. With all mirrors on Sourceforge it's far more likely that a torrent link would be outdated/not work at any given time. That doesn't mean that people can't set it up themselves, but it's not something we will do officially, 0 A.D. is already available in plenty of places: Sourceforge, IndieDB/ModDB, and of course directly via a ton of Linux distributions. I think there are a couple of "Free software download sites" which has got it as well. And there's of course always the SVN version. Adding more is more likely to mean that the version you can download from one place or another is not the latest than anything else

Ah, that makes sense.

I just thought they meant that information should be included in the actual contract?

I vote in favor of the agreement. (Though as SPI said I think we'd need to add the information about 0 A.D. being available for free, don't we? Or am I misremembering that and it's just something they wanted to make clear between us?)

Hello. Yeah, as the error message says your computers' graphics cards, or at least the drivers for the graphics cards, do not have the features required to run the game.

Cool to hear from you again, hope things are well with you

If the SVN checkout fails it should be possible to just use SVN update to get it all. It's fairly common that there will be some error when trying to checkout everything, but in that case it's usually just to update and you'll eventually get everything.

Have you built Atlas?

Thanks for mentioning that last thing, I don't know enough of it to have any real input on that specifically, but it did remind me of one other thing. Note that this is mostly something we as a team need to consider and not a criticism towards Jorma or anyone holding either opinion. It has always been a goal that 0 A.D. should be possible to run on as many systems as possible (both in terms of Windows/Mac/Linux and in terms of different hardware), but when updating the code to take advantage of newer features there's always the risk of limiting the number of possible computers the game can be run on. Should we strive more for the best looking/running game possible or more for the game that the largest number of people can enjoy and play? Of course we'll have to settle for somewhere in between, we can never create the most visually advanced game, nor can we create a game that can be run on every computer (just making the game 3D has ruled that out). But I think it would be useful for the future if we would make a general decision as to what we would like to aim for.

I have talked a bit with a few of the more active programmers, and there are two things which are clear. First, they think Jorma is a highly talented programmer. Second, that it at least can seem as if he's a bit too prone to rewrite whole parts of the code as opposed to improve on what's already there, even if the task he set out to complete would be completed (and in less time, and easier to review) by improving the existing code. This can of course be both a good and a bad thing. The old code might be so bad that the only way forward is to rewrite/it might be less effort etc. On the other hand, rewriting code means it's a lot more code to review for other programmers, and can of course introduce new errors. It can also be hard for someone else to judge whether the rewrite is a good or a bad thing. All-in-all this doesn't mean that Jorma can't get paid/never should rewrite anything, I just think there are a few things he (and everyone else who makes any substantial changes for that matter) can do to make it easier both to review and to accept bigger changes (these are based on things the programmers mentioned, but using my words. In other words, don't blame them if something sounds weird, and don't give me credit if there's something great ): If the objective of the change is to improve performance it should be demonstrated clearly (using e.g. one of the existing profilers or an external profiling tool) comparing the results before and after the code change. If entire bigger blocks of code is rewritten it should be demonstrated clearly that the alternative of improving the existing code has been considered. I don't mean that the programmer needs to write an essay on the pros and cons of doing things one way or another, but it should be obvious that's not just done on a whim, "I can't be bothered figuring out why someone else did things that way so I'll just rewrite things the way I think is best". Exactly how it is done is less important, it can be done through forum discussions with other programmers, it can be a few lines in the Trac ticket describing the thought process (and preferably offering some kind of proof that the rewrite is necessary), etc. Just something to acknowledge that the old code has been considered and not just thrown away because it seemed easier to begin from scratch. (And of course it depends on the scale of the rewrite how much effort should be spent, rewriting a couple of hundred lines of code or something shouldn't need more than a line or two in the relevant Trac ticket while rewriting entire files/sets of files of code should preferably be discussed thoroughly beforehand.) In conclusion, I think (with the above posts and my discussion with the programmers as a base for my thoughts) that Jorma should be paid with the Pledgie money under the following conditions: 1) that he communicates to the rest of the team and the fans at least once or twice a week in a progress report, and 2) that he communicates to the other programmers why he has made the choices he has.