- User Since
- Dec 19 2016, 10:38 PM (113 w, 1 d)
Thu, Feb 7
Jan 15 2019
@elexis I sent you a forum PM, please let me know if you want to use a different place for discussion.
Jan 13 2019
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.
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.
Jan 12 2019
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
Jan 6 2019
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).
Jan 5 2019
Jan 4 2019
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.
Hey! Yes I'll find the time. I haven't focused much on DevOps during the holidays but I'll be back to that.
Jan 3 2019
Cannot update this quickly because of https://secure.phabricator.com/T10608
Jan 2 2019
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.
Dec 30 2018
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).
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.
Dec 29 2018
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...
Dec 28 2018
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.
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.
Dec 27 2018
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! 👍
Hi Nescio! I can finally include this patch. It needs to be split however. Can you do the following for me?
Dec 26 2018
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 😉
@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.
Dec 25 2018
Dec 21 2018
Dec 17 2018
Thanks for tracking this one down 🙂