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

@Mister if you have still time for this patch there are a few things left:

• We'd like a unit test (like the one I edited) for the new behaviour. (Basically a copy-pasta from one of the tests, but ensure that the entity to repair/construct is not in the cmpBuilder.Entities list.)
• Our GUI needs some change, you probably need to take a look at unit_actions.js (https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/gui/session/unit_actions.js) and especially in the function around L437 (https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/gui/session/unit_actions.js$437-448).

Fix tests (from Diff 20734).

One could consider making Petra a bit more chatty in debug mode. I.e. add some debug chat about trying to upgrade.

Makes sense.

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

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

Build is unstable, some tests have failed - The Moirai have given mortals hearts that can endure.

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

In D4425#203777, @Stan wrote:

Can't you make it the responsibility of the receiver to destroy objects instead of adding the extra overhead of a unique ptr?

I guess an overkill solution could also be to have a destruction queue that's emptied when trying to push new tasks.

fix the actual memory leak bug

Can't you make it the responsibility of the receiver to destroy objects instead of adding the extra overhead of a unique ptr?

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

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

fix the memory leak

Build is unstable, some tests have failed - The Moirai have given mortals hearts that can endure.

Build is unstable, some tests have failed - The Moirai have given mortals hearts that can endure.

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

Build is unstable, some tests have failed - The Moirai have given mortals hearts that can endure.

apply suggestions from Stan

Windows failed because you broke the debug tests. Possibly a memory leak.

Build is unstable, some tests have failed - The Moirai have given mortals hearts that can endure.

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

Use Future to comunicate the return value and to ensure the task is stoped in the destructor.

Updated version for A26.
EDIT: Removed the repository as it's useless to build it since it will fail.

On lines 23 and 25 of the patched file, there is a call to the sys' module exit() function. That usage is discouraged because redefines the exit built-in in Python's interpreter when importing the module containing such import from the interactive Python interpreter. The usual way to handle exit statuses is to make the main function to return those values (def main() -> int) as integer values and handle them in the calling of the main function like so:

In D4784#203724, @phosit wrote:

Its not only about performance. virtual is just a bad practise.

This is a strong statement. In that case there is no runtime polymorphism (and especially interface) in C++ which is a good practice :)

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

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

In D4784#203715, @vladislavbelov wrote:

A namespace can't have I prefix, because it's not an interface. As it doesn't provide a contract. Which means using namespace in such manner is much more error prone than using a real interface.

The name can also be changed.

I tried to only remove the down-casts.

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

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

const corrections and use getMaxAttackStrength

A namespace can't have I prefix, because it's not an interface. As it doesn't provide a contract. Which means using namespace in such manner is much more error prone than using a real interface. And DummySoundManager can't be used as a mock object in tests.

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.

Ok then go ahead the sooner the better.

I would like to merge this. Is there something about asking translators if they'd be able to get to it? How do we proceed?

And if a decision were made, I'd help implement it. This is an example of how I implemented it on rmw https://github.com/theimpossibleastronaut/rmw/blob/master/src/parse_cli_options.c

Well, I guess I'm repeating myself a bit... a man page can be a bitch to maintain. I suggest implementing a parser like C's getopt or https://theboostcpplibraries.com/boost.program_options , and using help2man to generate a man page (which can be at least customized a little with a template).

I apologise to thous who put time in reviewing.

For now we should put ower time in improving Future and TaskManager.
When we have coroutines we should again take a look at this interface. When all compilers support coroutines we can also use libunifex.

On a second thought someone might expect the profiler to have a livetime like std::clog. Wen using CProfiler in static initialization there would be an dangling reference.
I think it would be bether to have components (HTTP / GPU) be handled by RTTI. Propably I do that in an other diff.

I am in a bit of a pickle. Should this be committed regardless of string freeze?

I am in a bit of a pickle. Should this be committed regardless of string freeze? @Freagarach, @lyv, @wraitii, @bb, @Dunedan, @defc0n

I guess I'll wait then. ^^

In D4777#203603, @Stan wrote:

Ah nvm the last inline then ^^

Ah nvm the last inline then ^^

Now back on the issue if @lyv is right and which is indeed unsafe we might have some issues.

I did check it afterwards and the premake function handles it properly, and`which` not being formally standardized isn't a deal breaker as the game probably won't compile on those systems anyway. The patch did work in that state as well, ultimately it comes down to your preference.

Nice! After I applied the patch, and renamed /usr/bin/wx-config to /usr/bin/wx-config.old, this is the output

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

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

In D4777#203582, @andy5995 wrote:

@Stan Well... who gives a shit what the ticket was about... if there's a better way to implement the ultimate goal of the ticket.