In D1955#81505, @wraitii wrote:

I would suggest "phenotype", which has fewer connotations and is more generic.

That is a good name!
Should we try to allow more than one? So that one can have an "elvish" "child" or will that be too much?

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

missed one

Gender is used in every template... That should be renamed in another patch

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

I like the feature, haven't really looked at the implementation (except for inline comment), but this needs to be renamed. Beyond the fact that "gender" is more likely to lead to flame-wars, this should be usable for more things than genders, such as a unit that could be elvish or dwarfish in appearance for example, or variants of robot, or "child" vs "adult" for example.

wraitiis version does that too, but splits it at the costs of removing the split of the JSInterface from the GUIObject.

I don't think we're at risk on windows, particularly if we drop VS2013 (soon-ish): https://stackoverflow.com/a/15142193
I also believe we're fine with GCC 4.8.1 and clang 'ought to be unproblematic', so I believe we're in the clear.

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

• FIxed typo's in serialise.
• Local variable in "CCmpVisualActor.cpp".

@Angen If you can launch this patch that may degrade performance, let me test it. I want to test this patch to help you.

Vladislav told he will look into his older patch, I tried to but cannot solve it, unless we remove something but it might lower performance.

@Angen When will there be a solution to the water problem?

@gameboy not related to water problem

@Angen How is this going, my friend? Is there a good solution released? I can test it for you.

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

• Moved random function to Init.
• Hopefully serialised properly.

In D1955#81447, @elexis wrote:

( ... The voice would also depend on this identity property, not stating that it has to be done in this patch.)

IIRC that is already the case?

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

Applied @Angen's comments.

attack animation does not play and sometimes will not attack ( if player commands )

(Feature was also requested by wowgetoffyourcellphone and others, as it's what AoK has. The voice would also depend on this identity property, not stating that it has to be done in this patch.)

To make @elexis happy

I appreciate it, but it's really in every code users interest to have this file split well, as there are already 3 random functions that are uncommon for JSInterface GUI Objects but defined here (committed or not).
Ticket was created at #5442.

some comments

yes, needs to be serialised

@wraitii could you check that?

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

Linter.
By the way, I guess that the gender ought to be properly serialised? Otherwise you could have a diffently gendered army after loading?

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

Seems to be working now. I tested it using a replacement tag in a female citizen.
I currently one-lined (and hard-coded the genders) in the "Identity.js", but should that be more readable?

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

Small cleanup

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

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

again.

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

add missing lines at end of files.

Re add missing files.

In rP22344#33832, @Stan wrote:

I probably should have asked that before, but wasn't std::thread broken/missing features on windows ? https://stackoverflow.com/questions/13134186/c11-stdthreads-vs-posix-threads

Damn it deleted all the files...

I probably should have asked that before, but wasn't std::thread broken/missing features on windows ? https://stackoverflow.com/questions/13134186/c11-stdthreads-vs-posix-threads

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

Use every instead of some.

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

Working version, animation is weird.

Looks much better to me, perhaps changePerspective can be avoided by using just the checked() value as the state (I don't remember and didnt investigate why thats a separate variable), controlAll might or might not be buggy because the state is in the simulation and if cheats are disabled (in multiplayermode), then clicking this will not succeed to control all units, but the checkbox might or might not still be ticked (I didn't test). (I mean that might be the case before the patch already, and I didn't check what this revision does to that aspect...)

Ah, ok, then It's probably done in the follow-ups, D1916, D1917 or D1920.

In rP22344#33828, @wraitii wrote:

I don't understand the question, sorry?

In rP22344#33825, @vladislavbelov wrote:

Why pthread_t was replaced only for the main thread and not for workers?

Why pthread_t was replaced only for the main thread and not for workers?

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

To be honest I think the best system for the GUI could be similar to what the 'mobx' library does (on top of React), where views can have internal state or depend on external state, and updating any of that state redraws appropriately. It sounds like it would be implementable for 0 A.D.

In D1928#81321, @wraitii wrote:

This is kind of blurring the sort of MVC pattern we had before. Now the part updating the GUI and the part holding the state are in the same component. It's not necessarily an issue (particularly here since this component isn't intended to be re-usable elsewhere) but we should perhaps think of a more general solution.

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

Last version I made (probably needs rebase)

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

First rebase by me.

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

Third version by Sanderd17, will fail as well.

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

Second version( will fail)

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

First version by Sanderd17 (will fail)

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

Do not display bonuses equal to 1

This is kind of blurring the sort of MVC pattern we had before. Now the part updating the GUI and the part holding the state are in the same component. It's not necessarily an issue (particularly here since this component isn't intended to be re-usable elsewhere) but we should perhaps think of a more general solution.

I guess allowing modifications to add new bonuses is maybe out of scope / not doable yet?