Maps were checked and good.

Also you should check map scripts if some does want to garrison turretholders by old function

As stated in the forum, the complaints about the worker ele feel off-base because it isn't actually OP. Very few players actually ever train a single worker ele, and this change will make even few players train this unique unit. I see no need to restrict player strategy where there is no actual problem.

Thanks for giving this a look :)

I think the implementation is more complicated than I'd like to have. My points:

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

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

RC 2, fix header.

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

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

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

'Release Candidate' update.

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.

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

Remove UnitAI comment.

Add missing semicolon.

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

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

With the "default settings" I could hardly hear the sound, after lowering the "music volume" and increasing the "action volume" to max the sound is better noticeable.
After increasing the sound with ffmpeg (ffmpeg.org/ffmpeg-filters.html#volume) by a factor of 8, it is now better noticeable with the "default settings".

In D2658#128941, @myou5e wrote:

Here is the schema capability I would suggest to add to the templates for generality's sake.

Kinda late, but that schema looks good. Not sure about the time parameter, though.

(Also mirage the resource-rich corpses then, I suppose.)

Very nice!

In D3865#167041, @Freagarach wrote:

Things I noticed:

• When one entry could not be completed due to a resource shortage, autoqueue is stopped. Is that intended? It feels strange to me ^^ Especially since the GUI still says it is on ^^

Updates addressing @Freagarach 's reviews.

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

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

Don't autocancel on destruction.

While the template_unit_ship_quinquereme.xml has five children, there are only three quinquereme actors. It's not that much more work to add dedicated artillery to all of them.
I quite like the idea. If I understand correctly, those subunits can fire independently, which means the ship itself could have an arrow attack instead (like the trireme) and get additional arrows from soldiers on board.

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

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

Some comment clarification.
Make Status an enum class, forgot enums could be implicitly converted to int and that's terrible.
Make Future never-blocking, keep packaged_task blocking. I think that's easier on client code, and seems to be the direction of concurrency TS going forward (we'll see).

In D3811#167084, @Nescio wrote:

The Ptolemaic ship is not that supersized: it uses the Roman quinquereme actor. Perhaps all quinqueremes ought to have one or two pieces of artillery?

Mostly a prove of concept here ;) May very well be elaborated if it works good enough.

Should the unlock_champion_cavalry.json and unlock_champion_infantry.json be changed from "notciv" to "civ" then?

Thanks! That's one untrue thing less in game.

The Ptolemaic ship is not that supersized: it uses the Roman quinquereme actor. Perhaps all quinqueremes ought to have one or two pieces of artillery?
Are they included by default? Can they be destroyed separately? How does it affect the ship costs?

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

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

I'm moving the dev overlay checkbox to a later diff.
Improve the handling of configdb.

Do you mean vars? That is function-scoped so should just be within the defined functions, right?

One thing to check -> global scripts are run directly in the 'global namespace', not in a closure, so this might introduce some pollution/noise in the global namespace if local variables were defined by these scripts.

(Can we get a screenshot of the GUI setup? I'd possibly like to make the icon optional (as in hidden behind an option) / make it relatively non-intrusive)

Make sure to triple check serialisation, as this introduces GUI - simulation interaction (though at a glance things look setup correctly)

First of all, thanks for the patch! I really like this feature (as a casual player ^^ ).

I was able to apply your already uploaded patch, but I had problems with the .png files, they were not downloaded correctly. If I use the provided .png files from your GitHub repo, then the patch works for me.

Hey, thanks for taking the time to create this patch.
You would need to add context to your patch, try this:

You can download and commit it

In D3862#166998, @Freagarach wrote:

If you upload you patches using the webinterface, could you please set the repository next time? That way our linters will run and check your code :)

Is that sound committed? Or can I just download it and add along with the patch?