hyperion

You might want to clone the git mirror at https://github.com/0ad/0ad instead, beware there are no autobuilds for windows tho and you might be up to a day behind compared to svn.

best isometric RTS

Balancers (some at least) already try hard for all civs to play the same, if all maps play the same as well there is little to look forward to. Except for looks (tho not as bad as it once was) Anatolian Plateau is a great map!

I would like to see the bylaws say neither 0ad, pyrogenesis nor wfg shall be used for politics in any form or shape. The SPI likely doesn't want to see it's members pulling political stunts either for the sake of avoiding controversies.

That should be just some docs. At a cursory glance at the list libfreetype-dev seems to be what you need.

You need to install freetype first, was added as a dep to support font rendering in the future.

The argument for spear and bows to be available in earlier phases is the lower tech requirement for a civ to produce those weapons. I'd equate p1 to stone age, p2 to copper age and p3 to bronze age roughly. The high number of warhorses in p1 of a typical 0ad army is quite off

This would cover 90% if it works. Just imagine you have chained objectives and the second objective would be to capture a building, then you might want to disable can be damaged or captured till first objective is reached or you'd risk breaking the script/flow of the mission.

There should be a way to programmatically enable/disable capturability of an entity I'd say. I can think of quite a few scenarios this might be desirable in campaigns. Maybe there is even a clever way to do it already which I'm not aware of. Campaign support is very limited at this point, basically you are the first to be this serious about it and you are prone to run into many situations where you think this or that would be nice to have. So if you run into such an issue, don't be shy to ask for it to be added if it's not available to make your life and the life of future campaign creators easier. The first step to improve campaign support is to know what is actually needed/desired, then if it's reasonable the implementation should be only a small hurdle. An example of a feature that only makes sense for a campaign would be https://code.wildfiregames.com/rP25393 by @wraitii Anyway, much impressed by your work so far.

I only see two reasons for mercs, the civ predominately made use of them or for gameplay reason we need a unit that wasn't available "natively". Neither seems the case for Han.

Those 3 categories stand for generated, hand crafted and locked setup, mainland-like maps is orthogonal to them and as such a filter like "demo maps" is is a better fit.

There is eject health already defined and structures should switch to "damaged textures" at that point to give a visual clue for needs repairing to be garrison-able again. (Just that the art department only managed to get Carthage done in all those years ) One could make eject health the breaking point for can now be captured as well. This isn't that far apart form @Freagarach's suggestion me thinks.

Just to make sure I understood, you mean a mechanic based on territory influence / weight, instead of capture attack? If so sounds worth a try.

contains the problematic (to large) public.zip.backup, move that file up a level so the game won't see it here. Just make sure /usr/share/0ad/data/mods doesn't contain a public.zip neither and it might work.

Reporting the bug as was done is by far the best course of action

Capturing is the biggest reason, people playing tiny sized maps another and finally the ever reduced average game duration is what made territory less important than it was. This potentially breaks carefully crafted maps, acropolis bay might even be affected. Something else to think about here is build distance restrictions.

Mostly within, also imagine again the super ultra wide display where the exit button needs half a day of mouse moving to reach

If moving to the side due to ultra wide screens is undesirable this is the the next best solution to preserve art. Dead center is almost always problematic. I agree on this one.

Single-player vs Multiplayer, me thinks either both should use a hyphen or neither, tho I admit I'm not that great in English. Also I agree with Freagarach that the center bar is not ideal. For your background it works somewhat but most existing ones will have important elements cut out. They are fine pieces of art and deserve better Maybe an approach like the bottom bar could work with a corresponding font or maybe just move those 3 buttons to roughly where they were in the original design. Guess they won't be any less prominent there than if they are dead center.

Glad someone still remembers this freetype builds out of the box with cross mingw, haven't looked into glad2 as of yet. Also form discussion the move to compressonator is very likely and as such another blocker would be out of the way.

If you hadn't said anything I could still happily think of it as a temple, now I'll be irritated whenever I see it

Splitting anywhere else than project boundaries is a bad idea IMHO. For the sake of argument let's assume binary assets are an issue or are anticipated to become an issue then lfs is a superior solution to some hand crafted custom setup. For me engine and game are two different projects. Two projects can live in the same repo in theory but it takes a lot of discipline. In practice this rarely ever works. Let's have a look at 0ad premake.lua with the lofty goal of building multiple static libs so they can be used on their own outside of pyrogenesis. In practice there is tight coupling, even plenty of cyclic dependencies, further stuff in third_party was made dependent on pyrogenesis as well. Then look at the directory public, supposedly the game, which contains plenty stuff which belongs to the engine making the engine unusable without the game. The engine having a proper API one day is pretty much out of reach in such a setup. pyrogenesis has 0 cve listed, so the most secure piece of software ever ...

The scope of the discussion isn't particularly clear, going by title and poll it seems a debate svn vs git. I'm a proponent of git. For most part either works, and whoever prefers to work with the other can do so independent of what the master repo uses. So what would one gain from migrating to git, there is quite a list but I limit myself to what I think is most important for 0ad mostly based on commit history and what comes to mind right now. Git unlike svn respects authorship. Pyrogenesis/0ad is a volunteer project as such attribution is of paramount importance for many if not most. Git workflows encourage commit often. As such commits are far more likely to be properly split, i.e do one thing only and do it properly. Git workflows don't differ between diff and commit. Often subject and message of the commit are even more important than the code change itself. Using a git workflow both are made part of the review process. With git you push commits. Bad commits, which happens to the best, can be fixed before publicizing. Some points made in this thread I think are worth addressing with a few words. Git and binary handling: Well, the current binaries in tree and their history are a non issue when using git. Stan mentioned lfs, there are other means of binary handling as well, all with their own pros and cons. Discussing them might make sense but can be ignored just as well. Autobuild: It's _very poor_ practice to store build artifacts in the repo irrespective of vcs. Also last I checked there were more Linux than Windows users therefore we need to replace them immediately with Linux binaries to maximize the use for our users. A proper solution if people want to use prebuilt artifacts is to add a script which fetches them from CI. This would work for any commit and not just selected ones plus for all supported platforms. Regular proper pre-releases for testing could be provided as well, so pure testers wouldn't even have to bother with a vcs at all. Split repo: If pyrogenesis/0ad is considered an engine plus a game and not just a game a split is almost mandatory. We can have a very lengthy discussion about this but is out of scope here. First, yes, a proper split is more complex than putting public into it's own repo. Second, as for why spidermonkey as a dep sucks for us/distros is to a large part that it's in the same repo as firefox.

And I bet it ignores relativity, so like most other games a fantasy physic engine. Good choice as no one want's to play a realistic space shooter