In D4155#182547, @bb wrote:

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.

Er, we technically depend on a few persons now. If the servers were to crash irrecoverable and backups didn't work, we'd lose everything as well. Point is, I don't think this is much of an argument either way, though there are pros & cons for both.

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

AFAIK none support SVN, unfortunately. And well, it's true, but it'll also keep all its security flaws (if any) & its general slowness & never get any new feature.

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

In D4108#182476, @Stan wrote:

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

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

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

Further reducing the need for expansion which you already see as an issue? Also Roman and Kush already have this build outside of borders feature, so not unique in any way, just reducing the uniqueness of those already having such.

I believe the higher hp are historically correct for being bigger ships, however if this is affecting the balance I suggest reducing the movement speed a little, adapting to their larger size and weight (also because they can carry more people). The lower movement speed adds historical value and should solve some or all of the problem, as well as avoiding making civilizations even more equal.

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

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

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

Intersect camera at corners of polygon, instead of using an imaginary horizontal plane based on averaged terrain height (see previous diff for that).

In D4279#182399, @s0600204 wrote:

If we calculate the intersection between camera-view and ground for each corner:
("Vesuvius (6)" skirmish map, the camera orbiting the peaks in the centre of the map.)
Admittedly an extreme example, but the top edge wobbling all over the place happens on most maps.

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

In D4280#182385, @ValihrAnt wrote:

One thing to consider is to make pyramids easily captured.

They're already captured in the same time as a house or storehouse but can't be garrisoned at all, so if you get pushed off a resource they're an easy target.

Their cost is reduced to 150 stone, build time to 120 seconds. Can someone elaborate on why this is good costs?

It makes the pyramid more affordable. What's the point of moving it up to village phase if players will at most build one at their farm economy and then forget about them existing like currently. The idea is that the reduced build time allows players to place it early on and the reduced cost to afford 2 in the village phase after some minor stone collection.

I would like to see 75 or 100 metal added to the cost, so you can still build one with the starting metal. However the metal cost makes it less spammable and thus less easy choices.

I don't think it really needs any cost increase. It could be maybe given 50 metal on top of the current cost but not more I think. The fact that it is a capturable building already gives it a risk factor. If you balance the cost for it not to be spammable in the late game you simply won't see any in the early game and if we go by how it is currently, you'll rarely see Kushites build them in the late game either. Also, keep in mind that the reduced aura indirectly increases the cost, and the funny thing that placing a pyramid in the best spot steals away the best spot for a storehouse.

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

more redundant lines, from unit templates

In D2175#182398, @wraitii wrote:

Formations are supposed to be about fighting and battlefield shape, which is why using them for gathering makes little sense.

Agreed, but I would say the story is different for battalions, as the are/ could be seen as a more general organisation entity. That's what I liked about the previous patch version :) but yes this it getting off topic, sorry about that.
As I said, the patch is still nice and an improvement as it is now, so no objections from me. Although I would like battalions to be usesefull outside of formations to reduce micro or formations generally being less broken.

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

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

Attempt to use the average height of terrain in the camera's view, instead of just the height of the centre point of the view.

In D4279#182375, @wraitii wrote:

[...] you could actually just query 4 height map points and draw a more accurate polygon.

This is getting off-topic, but maybe the right thing to do is make double-clicking select the control group instead of all similar units, if the entity is in a control group?

I agree, control groups and formations with battalions do overlap, but they differ in key components.
Control groups are limited, but they are able to group buildings, which is what I use them for the most.

In D4280#182376, @wraitii wrote:

@Langbart: Check that it works with non Kushite units but if so yes.

Seems to work. 0AD has special civ related structures (e.g. camp_noba, temple_amun, ...) still in the units/{civ} templates. Would it make sense to create a patch and get all the structures for all civs into the mixins/builder.xml file? See below, one needs to get into seven files and remove the redundant line now.

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

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

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

Correct indentation

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

Moved the icon location to be after the house and removed now useless lines.

One thing to consider is to make pyramids easily captured.

They're already captured in the same time as a house or storehouse but can't be garrisoned at all, so if you get pushed off a resource they're an easy target.

Their cost is reduced to 150 stone, build time to 120 seconds. Can someone elaborate on why this is good costs?

It makes the pyramid more affordable. What's the point of moving it up to village phase if players will at most build one at their farm economy and then forget about them existing like currently. The idea is that the reduced build time allows players to place it early on and the reduced cost to afford 2 in the village phase after some minor stone collection.

I would like to see 75 or 100 metal added to the cost, so you can still build one with the starting metal. However the metal cost makes it less spammable and thus less easy choices.

I don't think it really needs any cost increase. It could be maybe given 50 metal on top of the current cost but not more I think. The fact that it is a capturable building already gives it a risk factor. If you balance the cost for it not to be spammable in the late game you simply won't see any in the early game and if we go by how it is currently, you'll rarely see Kushites build them in the late game either. Also, keep in mind that the reduced aura indirectly increases the cost, and the funny thing that placing a pyramid in the best spot steals away the best spot for a storehouse.

Well yeah the logic of control groups is really similar, one might say that control groups and formations are overlapping behaviors, if you take aside the fact that a control group can contain multiple formations.

Interesting idea!

In D2175#182381, @marder wrote:

Would just be a bit sad if something that can be useful in many situations (selecting a bunch of units with one click)

Would just be a bit sad if something that can be useful in many situations (selecting a bunch of units with one click) is tied to something that is halfway broken. But as @Freagarach said, probably something for another patch.

In D4279#182375, @wraitii wrote:

I believe Vlad's point is that you could actually just query 4 height map points and draw a more accurate polygon.

Not really, the problem with the patch's approach is that it uses a single point. And it might differ significantly in neighborhood.

Their cost is reduced to 150 stone, build time to 120 seconds. Can someone elaborate on why this is good costs?

I think you should merge this, it's a nice improvement & I'm sufficiently available to fix the CI if need be.

@Langbart: Check that it works with non Kushite units but if so yes.

I believe Vlad's point is that you could actually just query 4 height map points and draw a more accurate polygon. Though by itself the polygon would still be somewhat inaccurate because the field of view is not a perfect rectangle on hilly maps. The cost of doing that is likely not much worse than doing one query.

Yeah using formations for anything but walking / patrolling is various kinds of broken, which is why the default setting is not 'no override'.

I agree that this is better than the alternative. See here for reasoning: https://wildfiregames.com/forum/topic/56973-are-civs-in-a25-more-uniquespecific/?do=findComment&comment=455533