I've started;

gdb ../pyrogenesis

The crash happens here:

So it sounds like it segfaults due to an attempt to dereference an uninitialized pointer p.

In D1584#76329, @Stan wrote:

You refer to the constructor of std::mt19937, right?

No even the number generation is slow.

Okay, thanks for having tested.

First of all thanks for the clear information, I agree that

static const OsPath tempCacheFileName = VisualReplay::GetDirectoryName() / L"replayCache_temp.json";

is wrong because it was intended to use the value after g_args was set in RunGameOrAtlas of main.cpp.

:)
Do I need to make sure that Jenkins has nothing to complain about? Because quite a few things it says is not due to code I changed but was already there.

It's okay ;)

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

Sorry, didn't wait for reaction about the currency, I implemented it during lunch.

It's also a Microsoft Implementation, used in Erlang and Cisco projects. (http://irclogs.wildfiregames.com/2019-04/2019-04-25-QuakeNet-%230ad-dev.log 22:05)
https://rosettacode.org/wiki/Linear_congruential_generator
http://pi.math.cornell.edu/~mec/Winter2009/Luo/Linear%20Congruential%20Generator/linear%20congruential%20gen1.html
https://github.com/cisco-system-traffic-generator/trex-core
https://github.com/erlang/otp

During variable creation, tempCacheFileName and also cacheFileName are created at VisualReplay.cpp :

In D1584#76094, @Stan wrote:

Yeah but it slow as hell.

You refer to the constructor of std::mt19937, right?

Okay, from what I see it is almost done?
Things to discuss:

• resourceTradable/resourceBarterable/resourceTributable Objects are not used by me and can be removed I guess? Unless someone sees any useful application for it?
• Connected: If the above is done, the question about the caching is not relevant anymore, right?
• Duplication in the Resources.js and in the test_Player.js can be reduced. (I'm sorry, but I do not consider myself up to that task.)
• Should I add a currency parameter in this patch so that @wowgetoffyourcellphone and @Nescio are happy? ;) (see this thread)
• Are there any other things that ought to be done?

And a question, there are no reviewers, should I invite them or do they pick differentials themselve?

In D1190#76305, @Angen wrote:

if slot is in players territory, he can use it

I guess that's a use case for the player if he captured enemy walls.

Perhaps draw vs. display can be made consistent.

Which two other places are traditionally kept in sync with this file?
Also, how many mac players will look at default.cfg?

You're correct, currently the generic fishing boat template does not specify a status bar, which means it defaults to the values of the template_unit.xml file. If desired, I suppose I could insert those into the fishing boat to preserve its status bar size.
However, is it really important that the fishing boat has a status bar different from all other ships? Does it convey some information to the player that will be lost if it's standardized?
For comparison, without this patch:

they are global, not local (territory capturing, range manager to get list of them)
if slot is in players territory, he can use it
they cannot be destroyed by selecting, because they are visible only when placing walls (and actually are green now)
but they are removed by any new foundation placed on them.

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

Fixed confusing names, AI tribute requests and removed unnecessary test in code.

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

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

In D1751#70488, @vladislavbelov wrote:

I think we should restrict the number of pings, because I'm sure there will be many spammer on servers.

Rebase and apply the proposed changes

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

Ok, seems like I shouldn't try using the private svn for phab ^^

Rebase

In rP22230#33084, @Polakrity wrote:

So it was intended. :d

So it was intended. :d

The ones after {{ and before }} also, at least judging by the examples.

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

Remove spaces and quotes

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

Some minor fixes.

@Nescio This:

(See remarks about quotes and spaces)

In D1754#76234, @Imarok wrote:

In D1754#76083, @elexis wrote:

(Also am I the only one using libboost 1.69.0-2 or am I just the only one too stupid to resolve the build errors? I better get them resolved if I want to commit my own patches)

See https://github.com/boostorg/random/issues/49 (Found by Vladislav)
(Also see discussion at irclogs 2019-04-04 around 21:44)
TLDR: just ignore the notes and wait for boost 1.70

This several hundred times, since february or something:

In file included from /usr/include/boost/random/detail/integer_log2.hpp:19,
                 from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
                 from /usr/include/boost/random/detail/const_mod.hpp:23,
                 from /usr/include/boost/random/detail/seed_impl.hpp:26,
                 from /usr/include/boost/random/mersenne_twister.hpp:30,
                 from ../../../source/graphics/ParticleManager.h:24,
                 from ../../../source/graphics/ParticleManager.cpp:20:
/usr/include/boost/pending/integer_log2.hpp:7:59: note: #pragma message: This header is deprecated. Use <boost/integer/integer_log2.hpp> instead.
 BOOST_HEADER_DEPRECATED("<boost/integer/integer_log2.hpp>");
                                                           ^

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

Missing GUI credit, from 2009-08-12-QuakeNet-#0ad.log:

16:26  * Philip- ignores the licensing stuff for now, and just commits cygal's patch
16:31 < cygal> thanks for the commit :)
16:31 <@Philip-> Hmm, I suppose it'd also be useful to have a list of contributors' names, to go in the credits screen etc
16:32 <@Philip-> It's hard enough keeping track of all the official WFG members who've contributed :-(
16:32  * Philip- wonders if cygal has a real name he could add to the list, and maybe an email address if he doesn't mind it being public
16:33 < cygal> Quentin Pradet <email redacted>
16:33 < cygal> (but I don't really care about credits)

Update comment

In D1754#76083, @elexis wrote:

(Also am I the only one using libboost 1.69.0-2 or am I just the only one too stupid to resolve the build errors? I better get them resolved if I want to commit my own patches)

See https://github.com/boostorg/random/issues/49 (Found by Vladislav)
(Also see discussion at irclogs 2019-04-04 around 21:44)

In D1754#76083, @elexis wrote:

(Also am I the only one using libboost 1.69.0-2 or am I just the only one too stupid to resolve the build errors? I better get them resolved if I want to commit my own patches)

Actually JSdoc documentation is incomplete, see https://github.com/jsdoc3/jsdoc3.github.com/issues/115
Should still use Google Closure Compiler syntax that is part of JSdoc only exceptionally.

• @return {{ "killed": boolean, "change": number }} - the status change of the entity.

In D1752#72574, @elexis wrote:

I guess worldclick doesn't work since it only reacts after left-click; unless we make that hotkey a modifier (minimap click + hotkey(default shift) for instance).

Yes.

So the question is how minimap ping should be implemented for the people who don't have a third mouse button.
Isn't the usual way to add a button near the minimap, that if clicked changes the input.js state, and if that state is set, both the minimap "worldclick" events and the clicks on the actual 3D world would equally trigger the 'minimap ping'?

Anything else we should fix ?

So the outer brace comes from the @return defined here https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#return-type-description
The inner brace denotes an object, defined here https://github.com/google/closure-compiler/wiki/A-word-about-the-type-Object

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

Fix indent spotted by Stan

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

Rebase. Disable Website button if selected mod has no url.

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

@elexis Thanks for the detailed discussion and looking it up. Appreciated.

• Add dashes
• Readd the anonymous return object.

• - I would recommend to use the hyphen for @param (http://usejsdoc.org/tags-param.html http://usejsdoc.org/tags-property.html) and so forth, so that the first word that isn't part of the following sentence is visually distinguished.

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

If the convention is wrong, we may not follow it but have to change it.

Apply comments of elexis

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

• Remove unneeded parenthesis.

(Long discussion because it's a Coding Convention change in question)

The current rev makes it walk faster than before rP20230 and probably running (fleeing) at the same speed as before rP20230.
Possibly changed in rP22197.