In D1042#71075, @Nescio wrote:

Still to be decided:
1 what to do with the scenarios/Height Map *.png files
2 what to do with the three Azure Coast scenarios (identical maps, different player numbers)
3 what to do with the two Flight_demo scenarios (different maps, similar function)
4 what to do with the two Sandbox - Ptolemies scenarios (different maps, similar function; all other factions have only one sandbox)
5 how to differentiate similary named skirmishes, e.g. Corinthian Isthmus (different maps, similar names)

How about the following?

• 2, 3, 4: keep only one version, delete the others
• 5: rename them to _small and _large

@elexis I sent you a forum PM, please let me know if you want to use a different place for discussion.

It would be nice to have something that detects such infinite loops and creates JS errors instead of engine crashes.

I'm rebasing this one, and I'll try to include the binaries for Windows in the diff.

In rP22023#32208, @Angen wrote:

@Itms no logs no dump files, no errors. Just crash.

That's wild! This commit should not be able to create a segfault, so it probably just reveals a bug in the engine. The commands file should be enough to find the bug and fix it.

I think _p or m_p would be acceptable names since it's one letter.
This might conflict with D1395, which I should prioritize.
The other warnings shall be fixed by upgrading Boost and/or deleting old unneeded dlls.

Okay, you're right. Go ahead and thanks for the patch!

I think we do not need to include boost::system because we don't use anything from it, but we need to link it because boost::filesystem depends on it. I think only the build-osx change should be kept, as bootstrap is clever enough to build the boost::system lib while now excluding it from distributed includes.

This doesn't work for me. Linking of pyrogenesis fails with undefined references to boost::system stuff. I will retry tomorrow with a clean checkout.

The patch looks good and it works for me too! However, I tested building Atlas and got the following warnings:

• C4458 in AtlasObjectImpl.cpp line 292 and in AtlasUI/Object.cpp:547
• C4456 in MapDialog.cpp:173 and in ScenarioEditor.cpp:742

Addressed comments above, and tested the JSPROP_PERMANENT thing.

Ah right, sorry. But I'd be interested in knowing how much of the cases are actually ent == INVALID_ENTITY. It doesn't sound like there are a lot of cases where an entity would be deleted several times?

I really think all the things that happen after this early return are inexpensive. In particular, when posting messages, if the entity is actually fully destroyed, no component subscribed to the message will be found, so there won't be a lot of overhead. If it's not actually fully destroyed, the patch is wrong (I do not think that's the case, but I might be wrong).

In D14#69171, @Kuba386 wrote:

Well, button said "resign as reviewer". I've only intended to cancel my old review that is not correct anymore.
I'm still working on this.

I think this is a good change and I share the opinion that removing the "always entering"/"not always entering" distinction would help tracking down some subtle bugs.

I could not send this commit on Phabricator for automated testing, so please report here if any bug related to that is found.

I do not know why I thought we were using alpha10 of premake5: we are using alpha 12. The fix above was included in alpha13, that is correct.

This still works for me, with the same results. I didn't test a mod but the cli flag seems to work for the public mod as advertised.

In D14#69094, @Vulcan wrote:

Build was aborted.

Hey! Yes I'll find the time. I haven't focused much on DevOps during the holidays but I'll be back to that.

Cannot update this quickly because of https://secure.phabricator.com/T10608

🎉

If that works for you it might come from an old module you have installed.

This is a nice bear, and it works! All my apologies for letting this one aside for so long 😶

This patch looks harmless and sensible, but I disagree with renaming unused code into dead code.

This now needs a rebase after rP22005, sorry for that (I thought it would be better to plainly change mauryans to mauryas everywhere, to avoid mistakes as much as possible).

I used this and D1713 to perform the change, which I'm committing now.

I am Perl illiterate, but I tested the updated script and it works fine. It detected the following issues for me:

Loading maps PMP...
Duplicate terrain name 'medit_city_tile' (from 'art/terrains/road/medit_city_tile.xml' and 'art/terrains/biome-mediterranean/medit_city_tile.xml')
[...]
Loading GUI XML...
Can't stat ../../../binaries/data/mods/public/gui/modio: No such file or directory
 at checkrefs.pl line 61.
Can't stat ../../../binaries/data/mods/public/gui/modmod/help: No such file or directory
 at checkrefs.pl line 61.
Can't stat ../../../binaries/data/mods/public/gui/msgbox: No such file or directory
 at checkrefs.pl line 61.
Can't stat ../../../binaries/data/mods/public/gui/termsdialog: No such file or directory
 at checkrefs.pl line 61.
[...]
Loading terrains...

Thanks for the comments, addressing them today.

I agree with this change, it makes sense. What do you think of bringing up the usual debugging window instead of killing (in Debug mode)? I'm talking about the window that pops up when an ENSURE fails, for instance.

Not sure either why VS2015 doesn't get the error. Could you try to see what happens when the version check is removed? It doesn't make sense to add this new conditional as-is. The only meaningful patches would be, In my opinion, no conditional (the warning is silenced on all versions), or a conditional that keeps the old behavior for 2013 and introduces a change for the new version (that would be <= 1800).

In D1510#68005, @elexis wrote:

It still seems very wrong to neglect the differences between a SpiderMonkey pre-release, a SpiderMonkey release and a Mozilla Extended Support Release....

Yes, sorry about that. However SM developers themselves use the terms "release" and "ESR" liberally, for instance in bug reports, hence my sloppy use of the terms. I'll be more cautious. To clarify: when Firefox has an ESR release, SM developers create a pre-release of SM as soon as possible, and mark it as a release when they are confident the product is good enough.

In D1510#67827, @elexis wrote:

@Itms you mentioned somewhere to plan to go to sm60 after sm52, but I still didn't see any information that indicates that sm60 is planned as a release [...]
Knowing about these things beforehand may increase the platforms 0ad can run on, so it may be worth to explore (or describe if already explored).

About the ESR versions of SpiderMonkey: yes the documentation is poorly maintained, and releases of SpiderMonkey are not well announced (more on that below). However, I confirm the past released versions of SM were 38, 45 and 52. The current version is 60. Version 68 is the upcoming ESR. SM60 started to be developed on 2018-01-22, was released 2018-05-19, and will receive fixes until 2019-10-21 (two versions after the release of SM68). Those dates are taken from https://wiki.mozilla.org/Release_Management/Calendar: SM releases match the releases of Firefox ESR, as stated in the documentation.

This works for me 🎉 and is based on D1716. arcanist should theoretically be able to patch in chain...

In D1714#67739, @elexis wrote:

was it quicker than looking if the directories exist by hand/eye/grep?.

Thank you! That is a big patch. You should just update D1342 with this new version, though, in case there is a discussion on the patch, let's not scatter it.

You can patch your arc as in the link Stan provided, or you can set a property that I won't commit:

svn propset svn:mime-type text/plain garrison_flag_maur.xml

Whatever is easier for you.

I confirm that kush.json is the only place referencing the emblem, and I agree that it is way more simple to make the kush emblem follow the convention used for all the others.

Thanks for the remarks 👍 I posted a comment on the diff I missed, and I am going to take the opportunity to go through all the resources to see if there are no other unneeded paths. I'll create a diff for my findings.

Ah sorry for missing this patch, I committed the simplest fix for #5155, which was just adding the translate call.

👍

Thanks for the splitting! 👍

I'm committing this with the indentation fixed. I tested the pot generation and the missing strings are correctly extracted.

I am working on this and so far I am not having issues, it's just a bit time-consuming (so holidays are perfect for me). So if you don't mind someone else commandeering this @wraitii, I'm taking it.

In D1560#67463, @elexis wrote:

(I was wondering if one couldn't push the changes from the modified *po file to transifex using the commandline thing)

Hello @mmoanis, and thank you very much for the patch! As you may know we had a large period without accepting patches, because we were preparing a re-release of the game.

• The changes to our maintenance scripts seem unwanted/unneeded.
• The changes to the Swedish pot files must be done from Transifex, else they will be overwritten.
• The changes to the po files are unneeded, they will be performed by the autobuilder.
• The changes to our code look good, but they probably need to be rebased now.

@s0600204 This is a wonderful patch! 👍

In D1395#67451, @elexis wrote:

Why are UTF8 strings preferable over UTF16 ones? Might be, but I didn't see the reason mentioned, and

1. usually data is kept in the way the original data is provided (I failed to find the place where the strings are constructed)
2. most of the changed lines use wstring

Hi Nescio! I can finally include this patch. It needs to be split however. Can you do the following for me?

This looks pretty cool, I'm eager to have this in!

Rebased this patch before committing it.

That is even more complete than what I would call complete 😉

lol, D1705

In rP21947#31815, @elexis wrote:

(Version bump to a24 ought to be the first commit)

Fixed by rP21925 and rP21926, right?

@elexis Are we good with this? The remaining issues should be fixed by upgrading premake and committing a few patches. If I'm wrong we could really use a ticket to document our findings.

In D14#67127, @Kuba386 wrote:

+ binaries/system/test_dbg
Debugger launch failed: No such file or directory
Trace/breakpoint trap

Thanks for tracking this one down 🙂