In rP22511#35471, @elexis wrote:

Sure it was this commit? As I understand it's the placement new in rP22545 that is not supported by VS2013?

(01:20:33 AM) historicbruno: sorry, it's the default initialization of the array that is the issue
(01:21:24 AM) historicbruno: new T*[size](); fails on VS2013 with optimizations, for whatever reason
(01:23:06 AM) historicbruno: but as wraitii pointed out, the bug report links have all died
(01:23:14 AM) historicbruno: they even removed them from archive.org :/

-> D2125

Here's the observed behavior in VS2013:

• pre-rP22511: builds and can play matches (tested last week when I was still using VS2013).
• rP22511: builds, but instant crashes on match start (I didn't tested this as I had switched to VS2015... was not reported either). Also introduced memleak.
  • This is important because we hadn't introduced placement-new to fix the memleak. That's evidence that it can be ruled out as the problem. More later.
• rP22545: builds, fixes memleak, but crashes on match start (I also didn't test this on VS2013... but gameboy and Angen did, and reported the crash).
  • Suspicion falls on placement-new, as one might expect, it was all that changed in this commit.
  • I tested after the report from Angen and confirmed the crash. Also suspected placement-new, but while testing things, found that rP22511 crashes too.

So it must be something in rP22511. Three candidates by process of elimination, basically.

• The following diff builds, but crashes:

Index: Grid.h
===================================================================
--- Grid.h	(revision 22551)
+++ Grid.h	(working copy)
@@ -217,8 +217,7 @@
 		for (size_t i = 0; i < (size_t)(m_BW*m_BH); ++i)
 			delete[] m_Data[i];

I guess that's what we get for not testing the VS2013 build. I already switched to VS2015 in anticipation of #5379...

In D2123#88693, @elexis wrote:

The idea is that one can switch into the debugger if some JS conditions are met?

JSI_Debug::Crash still seems gruesome to me, but whatever.

It was added to GUI scripts because it was envisioned it might be useful elsewhere besides hwdetect (remember this is when "GUI scripts" was a global scriptinterface and applied to hwdetect too).

In D2123#88689, @elexis wrote:

Crash, DebugWarn nothing uses that, shall we delete?
DisplayErrorDialog only hwdetect.js uses it
GetBuildDate, GetBuildRevision - displayed in UI menu
GetBuildTimestamp - unused, possibly useful
GetMicroseconds - I added that for occasional UI performance debugging replacing janwas "cheezy" custom UI profiler. Later (a24) added for MapGenerator too but always used there.

It could be argued that hwdetect doesn't need all the JSI_Debug functions, but I also felt it strange to duplicate that function implementation instead of reusing the handy RegisterScriptFunctions.

In D1929#88309, @historic_bruno wrote:

From IRC discussion 20190721, two issues found:

• Toggling Post processing option in-game causes an error
• Toggling shadows on Azure Coast 3 scenario products strange artifacts (not present on SVN or A23b):

https://i.imgur.com/qGpSnVl.jpg

Some profiling results of the old memset code, vs the default-initializers including this diff: P162

Why not allow both right- and left-click for the command buttons? That way we don't suddenly change the behavior for existing users (people will complain), but those who feel it's more consistent to use right-click in both cases can still do so.

Also nspr4.dll depends on msvcr100.dll

nvtt.dll still depends on msvcr100.dll, which causes an error on some systems (particularly, clean installs of XP SP3). Should be rebuilt with VS2015 (vc140_xp toolset)

From IRC discussion 20190721, two issues found:

ROSA applied some other patches to their lib64mozjs45-devel package for fixing arm/aarch64 support:

All tests passed or skipped in release build (some of them timeout in debug build)

Clang build is very noisy, see P155. Most errors are [-Wundefined-var-template]. We could suppress this warning, but it's not available in the oldest compilers we support.

clean-workspaces.sh should be patched: P157

In D2101#87938, @wraitii wrote:

Well it ought to be a common locale, and it makes as much sense as fr_FR given the numeric parsing we do.

Seems it was decided to hold off on this until formation attacks are mechanically practical (I agree, but wasn't sure if this still needed review), since it would be unfair if units can be physically spread apart, but still get formation bonuses.

In D1849#87712, @elexis wrote:

Precisely because they have no idea how to fix this, the one line in options.json is the right fix isn't it?

I haven't build- or run-tested this yet, but the diff looks conceptually OK.

Don't see the problem here. Whatever the % of users who are affected, at least some of them do play the game and have no idea how to fix this, as we don't document it anywhere.

In D1246#53684, @elexis wrote:

I'm reluctant with this. The idea of scenario maps must have been at one point to let the map lock every setting.

Rebased to latest SVN

In D2030#87141, @Itms wrote:

I used the latest one (probably vc12) with the compiler I wanted to build the game with. Recent versions of visual studio can open slightly older solutions without issue ?

Sorry, I should have seen this revision earlier.

In D2091#87068, @elexis wrote:

std::fabs, std::labs?

In D2084#86963, @elexis wrote:

In D2084#86883, @historic_bruno wrote:

All I can think of are exceptions. What if an exception is thrown in CMapGeneratorWorker::Run()?

As far as I see there should by design not be any exceptions thrown in the MapGenerator thread.
If there is an error in mapgen stage, it is passed as progress = -1 to the MapReader in CMapReader::GenerateMap.
One could do some effort to pass over the exception string.

Ah, thanks! :) That makes sense then.

Why 3.0.4 in particular? I've built against 3.0.2 and it works (see also #2891, not sure which version the autobuilder currently uses -- it was 3.0.2 back then). We could simply say "the latest stable release", or something like that.

All I can think of are exceptions. What if an exception is thrown in CMapGeneratorWorker::Run()?

In D1784#75877, @vladislavbelov wrote:

In D1784#75860, @Stan wrote:

For Windows we officially dropped it when we committed #5098. For the rest of the platforms most of the ticket are about being compatible, but there is no clear decision.

What's about 2.9?

In D2076#86770, @vladislavbelov wrote:

source/tools/atlas/AtlasUI/ScenarioEditor/Sections/Player/Player.cpp has some code related to 2.8, I think it should be removed too.
source/tools/atlas/AtlasUI/ScenarioEditor/ScenarioEditor.cpp has some notes about 2.9, should be fixed or removed.

In D2076#86770, @vladislavbelov wrote:

What's about Ubuntu 14.04? We still have such audience (judging by feedback statistics).

Remove some wxWidgets 2.x checks.