- User Since
- Jul 8 2019, 3:30 PM (19 w, 15 h)
Jul 26 2019
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];
Jul 25 2019
I guess that's what we get for not testing the VS2013 build. I already switched to VS2015 in anticipation of #5379...
Jul 24 2019
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).
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.
Some profiling results of the old memset code, vs the default-initializers including this diff: P162
Jul 23 2019
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)
Jul 22 2019
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
Jul 21 2019
Jul 20 2019
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.
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.
Jul 19 2019
Jul 18 2019
Rebased to latest SVN
Jul 17 2019
Jul 16 2019
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()?
Remove some wxWidgets 2.x checks.