In D4155#182546, @wraitii wrote:

In D4155#182536, @bb wrote:

Also what happens if github goes offline/kicks us (maybe not likely, neither impossible), we loose our code?

I think this is absurdly unlikely at this point, but even if GitHub deletes the repose unilaterally, git makes it so that we'd very likely have recent-is mirrors on several dev computers & on the lobby server itself. I don't think this should be a concern.

Even if unlikely not impossible. So we will be dependent on a few persons who have the code. Also this doesn't save all comments and discussions.

Why give away the sovereignty we have?

'Cause Phabricator is dying, see https://wildfiregames.com/forum/topic/42181-phabricator-is-no-longer-being-maintained-upstream/

Phab will keep running as long as we keep it running on our servers. Also I saw there were efforts to fork it.

Also sovereignty is essentially kept per the first point.

The first point doesn't keep our sovereignty at all.

In D4155#182536, @bb wrote:

Also what happens if github goes offline/kicks us (maybe not likely, neither impossible), we loose our code?

I think this is absurdly unlikely at this point, but even if GitHub deletes the repose unilaterally, git makes it so that we'd very likely have recent-is mirrors on several dev computers & on the lobby server itself. I don't think this should be a concern.

Why give away the sovereignty we have?

'Cause Phabricator is dying, see https://wildfiregames.com/forum/topic/42181-phabricator-is-no-longer-being-maintained-upstream/
Also sovereignty is essentially kept per the first point.

Why let the codebase fall apart, literally?

Other arguments:

• It's a good way to gain knowledge about GitHub usage, which will help should we decide someday to migrate somewhere else.
• the person who wants to work on this code wants to work on GitHub because it's easier for them

Say if I were to implement a new system of ratings, I did need to change the bots (as I need to compute the ratings) as well as some gui (i.e. I need to show the new rating). Having several repo's makes developing such a feature much harder, so is not wanted.

It's a quite realistic prospect to change the rating calculation without changing the rating display, and vice-versa.
The actual hard problem is deployment, and since we don't actually deploy the bots synchronously with SVN, we'd already have a lot of trouble if you wanted to implement a new system of rating.

In D4282#182543, @Langbart wrote:

This image was only to illustrate my point with deselecting units, but the layout looks nice. Having a bunch of units grouped together to see who is part of a team looks appealing.
Hyrule conquest does it but with control groups.

When I try to deselect some units by holding down the Ctrl key and right-clicking on the icon, it only works for battalions with one unit type.

Do you need to call parse multiple times? If not why do you need the method?

I understand you'd rather I use C++ code. I'm not famillar with C++ actually, so I'll probably not do anymore with this diff.

Successful build - Chance fights ever on the side of the prudent.

In D4155#182309, @Stan wrote:

The idea was to not put more strain on the server as the CI is already bringing it to its knees and instead rely on a third party (here github for the CI)

How is this required to reduce the stress on the CI? Keeping 20-odd files in our svn repo won't hurt that much. If we want the bots to ignore these files, let them (though we have the bots for a reason so we better use them when we need to).
Also what happens if github goes offline/kicks us (maybe not likely, neither impossible), we loose our code? What if gitHub puts restrictions on what we do, do we then abide? Why give away the sovereignty we have? Why let the codebase fall apart, literally?
Now some third party CI might be free, probably many proper things we currently host ourselves are going to be expensive (now the SPI reports says we don't have to worry to much about our finances, I think we can spend our money better)

First reason is that while development of the lobby is linked, it actually lives its own life and evolves at a different pace and to my despair it's not actually completely versioned

Say if I were to implement a new system of ratings, I did need to change the bots (as I need to compute the ratings) as well as some gui (i.e. I need to show the new rating). Having several repo's makes developing such a feature much harder, so is not wanted.
We have files in our repo which haven't been touched in the last 10 years or so and files which are changed every month or so. That is completely fine. So if these files are developed evolve at a different pace: fine. What is the problem? I suppose during CF we shouldn't change the lobby bots either (if there are bugs with them, we need to lift CF for them: fine). Even the more reason to keep them in the same repo.

This is actually a good step towards the engine split.

Splitting the engine doesn't mean having several repo's. In fact we shouldn't have the engine in another repo than the vanilla game or anything else we develop related to 0ad. If we want to split stuff we need to work with directories within the repo: having a separate directory for tools like this within our repo is perfectly fine with me, storing it in source might indeed not be ideal.
Even if we need several repo's, we should host them ourselves.

There is no trac phabricator/instance

If you mean to track tickets/ make comments on pull requests you can do that too on Github.

So we as developers need to look at yet another place for patches, instead of keeping everything in one place.

Unlike all the other tools this one is actually used in production .

So are the translation scripts and probably others too.

You missed the intro.txt (see some ticket I recently created)

In D4283#182533, @sera wrote:

std::cout

Currently std::cout is not a standard way to write to output and logs.

If so, what should I use instead of debug_printf()?

I mean that debian provides or used to provide a man page for 0 A.D. while some other distributions do not :).

In D2432#102349, @Stan wrote:

Just for the record, only debian seems to provide a man command.

In D4283#182511, @Stan wrote:

Did you see https://code.wildfiregames.com/D2432

Build failure - The Moirai have given mortals hearts that can endure.

Successful build - Chance fights ever on the side of the prudent.

I'm not sure debug_printf works at all on Windows. You need to have SysInternals dbgview in order to be able to see such output.

A more involved fix.

You won't need the readme.txt anymore if you have support for help, worst case just run "pyrogenesis -help > readme.txt" as a postbuild command. So no duplication required.

I guess the issue was that we didn't want to duplicate the Readme inside the game's code. D4232 used a rather clever trick for that.

IMHO the right approach is to change CmdLineArgs from an minimalist class to a proper command line parser where you register available options, does validation and has a help string for each.

Did you see https://code.wildfiregames.com/D2432

This obviously isn't finished yet. I wanted to get some feedback before I proceeded.

In D4282#182497, @Freagarach wrote:

Nope, since you effectively give the order to the formation controller, not to any individual member (it has been like that for a long time already).

Nope, since you effectively give the order to the formation controller, not to any individual member (it has been like that for a long time already).

In D4282#182495, @Langbart wrote:

In D4282#182494, @marder wrote:

But why is there only one gather at this tree?

The idly waiting unit does not understand that they should help their friends to finish chopping their tree as well so that they can quickly go to the siege workshop together.

In D4282#182494, @marder wrote:

But why is there only one gather at this tree?

I still have no option to test at the moment but it sounds/looks exactly like the behavior I wanted. Thanks @Freagarach for the quick fix :)
@Langbart I'm a bit confused about the one gatherer in the video. Is the tree too far away for the others to reach it? From your explanation I thought that if the tree is in reach of the whole battalion, it should mean that the max amount of gather per tree try to gather it and the rest of the battalion is waiting for them to finish.
But why is there only one gather at this tree?

Yes this solves the problem described earlier in D2175#182343. The woodcutters look for a new tree after they are done with the first one.

In D4108#182477, @s0600204 wrote:

In D4108#182476, @Stan wrote:

@s0600204 any idea what we could do for macos and pkg config ?

Rebase to take into account recent changes, then add the below suggested line so that the generated .pc file is in the correct place for our scripts to find it. (There's no need to relocate the header files.)

Perhaps look at the availability of technologies as a bonus. So, for instance, for Gauls they could get all of the wood upgrades sooner (bonus name: "Continental Forestry" or something). For Ptolemies, all of the food upgrades sooner (bonus name: "Nile Delta"). Things like this.

I only wish we could make sure to place the walruses at the shoreline.

Well, originally Alpine and Arctic were going to be combined to save the number of textures, but I have since realized that biomes can just share textures if necessary. That was why muskox and walruses were "removed." But "Alpine" and "Arctic" are separate again, so it makes sense that walruses and muskoxes to be added back to Arctic.

Build failure - The Moirai have given mortals hearts that can endure.

Successful build - Chance fights ever on the side of the prudent.

Rebase now that parent revision has been committed