In rP22346#34395, @Stan wrote:

Well obviously we can, since this isn't the only change you requested :)

In rP22346#34394, @elexis wrote:

In rP22346#34393, @Stan wrote:

Shall I make another diff then ?

We can't know that without knowing the answer to the question when the TODO case can be triggered.

It would seem they added support for Microsoft Visual Studio 2019.
As of today, still haven't updated the CHANGES.txt file.

In rP22346#34393, @Stan wrote:

Shall I make another diff then ?

Shall I make another diff then ?

The Petra hardcounters implementation seems to come from rP13225.
There is also a countersClasses, but I guess that is not affected qualitatively, unless that // TODO: refine using the multiplier is implemented, in which case the ApplyValueModifications part would be done too if it is done here.
You cited the function that does apply the ValueModifications, I would add the function comment in the two lines above just for clarity:

helper function to return a template value, optionally adjusting for tech.
TODO: there's no support for "_string" values here.

Both come from rP14588. The commit message says Still need to fix the entity.js file to handle properly some things as this uses raw templates values..
So if the function does what the comments claim to do, then the function would be functional if and only if the ._string format never occurs for the passed data in this place, is that actually the case?

Bug n 1.
Run game with postprocessing on in fullscreen, alt tab and go back (solved by D1212)
Bug n 2.
Postprocessing on in fullscreen, alt tab while loading match, return back after match started ( original solution https://code.wildfiregames.com/D1495?id=7570) commited version (this)

(to not forget)

Concern:

• this reverted rP20053 by accident, and we should again disable the login/registration button when clicking on them to prevent acting twice, which crashes.

See inline for where I think we need to fix this.

I don't think there is much value in having both functions, but renaming to AppendPathnames makes sense.

Usually one can write Fixes #5445 to automatically close tickets.
@Itms, we now need a AtlasUI autobuild for windows, not sure that's automatic yet.

Sorry, should have been more specific.

Yeah I was waiting for something like D2009 which I would have done myself if someone hadn't come to the rescue. Will add the keyword soon.

In rP22323#34353, @elexis wrote:

Pass pointers instead of arrays

How are arrays passed?

Fix for rP15576.

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

Fixed Typo

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

Change VIsual Setting

Fixes rP22082.

• Task of the ticket is reasonable.
• Task of the ticket was extended to entail the Trigger keywords.
• Review remarks were addressed.
• Didn't get more compiler warnings than I already had before.
• Tested, works in accordance with the gamesetup filters.
• Thanks for the patch!
• Fix that map -> maps typo before the commit and perhaps 5 -> 15 for better visual layout

Pass pointers instead of arrays

How are arrays passed?

(Fixes rP22317)

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

Fix messages description

Looks good, I got some compile warnings however (gcc 9.1.0):

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

Add "trigger" Keyword in Map settings
Change Checkbox to be 2 by line

You may want to add the trigger keyword, since there is also a filter for that in the gamesetup.

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

Only a small concern, but something that should be fixed for the release. The maps should have the "new" keyword, so that they appear in the "new maps" filter.

Fixes rP22257, rP22260.

@Stan what does "break sound for me" mean, no sound at all (on windows?)? Is this reproduced by others (on windows)?

(Audit comment at D1914#83746)

grep for GetPathnames, notice that this is safe.

Performed, confirmed grep -R 'GetPathnames' -B1

i18n/L10n.cpp-	std::wstring dictName = GetFallbackToAvailableDictLocale(icu::Locale::createCanonical(locale.c_str()));
i18n/L10n.cpp:	vfs::GetPathnames(g_VFS, L"l10n/", dictName.append(L".*.po").c_str(), filenames);
--
i18n/L10n.cpp-	{
i18n/L10n.cpp:		if (vfs::GetPathnames(g_VFS, L"l10n/", L"long.*.po", filenames) < 0)
--
i18n/L10n.cpp-		std::wstring dictName = GetFallbackToAvailableDictLocale(currentLocale);
i18n/L10n.cpp:		if (vfs::GetPathnames(g_VFS, L"l10n/", dictName.append(L".*.po").c_str(), filenames) < 0)
--
i18n/L10n.cpp-	VfsPaths filenames;
i18n/L10n.cpp:	if (vfs::GetPathnames(g_VFS, L"l10n/", L"*.po", filenames) < 0)
--
graphics/MapGenerator.cpp-	// Load all scripts in mapgen directory
graphics/MapGenerator.cpp:	Status ret = vfs::GetPathnames(g_VFS, path, L"*.js", pathnames);
--
graphics/ColladaManager.cpp-		VfsPaths pathnames;
graphics/ColladaManager.cpp:		if (vfs::GetPathnames(m_VFS, L"art/skeletons/", L"*.xml", pathnames) < 0)
--
graphics/ColladaManager.cpp-			VfsPaths paths;
graphics/ColladaManager.cpp:			if (vfs::GetPathnames(m_VFS, L"art/skeletons/", L"*.xml", paths) != INFO::OK)
--
renderer/PostprocManager.cpp-	VfsPaths pathnames;
renderer/PostprocManager.cpp:	if (vfs::GetPathnames(g_VFS, path, 0, pathnames) < 0)
--
gui/GUIManager.cpp-			VfsPaths pathnames;
gui/GUIManager.cpp:			vfs::GetPathnames(g_VFS, directory, L"*.xml", pathnames);
--
gui/CGUI.cpp-				VfsPaths pathnames;
gui/CGUI.cpp:				vfs::GetPathnames(g_VFS, directory, L"*.xml", pathnames);
--
gui/CGUI.cpp-		VfsPaths pathnames;
gui/CGUI.cpp:		vfs::GetPathnames(g_VFS, directory, L"*.js", pathnames);
--
scriptinterface/ScriptInterface.cpp-	VfsPaths pathnames;
scriptinterface/ScriptInterface.cpp:	vfs::GetPathnames(g_VFS, L"globalscripts/", L"*.js", pathnames);
--
lib/file/vfs/vfs_util.cpp-
lib/file/vfs/vfs_util.cpp:Status GetPathnames(const PIVFS& fs, const VfsPath& path, const wchar_t* filter, VfsPaths& pathnames)
--
lib/file/vfs/vfs_util.h-
lib/file/vfs/vfs_util.h:extern Status GetPathnames(const PIVFS& fs, const VfsPath& path, const wchar_t* filter, VfsPaths& pathnames);
--
lib/file/vfs/tests/test_vfs_util.h-		VfsPaths pathNames;
lib/file/vfs/tests/test_vfs_util.h:		vfs::GetPathnames(g_VFS, "", L"*.txt", pathNames);
lib/file/vfs/tests/test_vfs_util.h-		TS_ASSERT_EQUALS(pathNames.size(), 3);
lib/file/vfs/tests/test_vfs_util.h:		vfs::GetPathnames(g_VFS, "sub_folder_a/", L"*.txt", pathNames);
lib/file/vfs/tests/test_vfs_util.h-		TS_ASSERT_EQUALS(pathNames.size(), 5);
lib/file/vfs/tests/test_vfs_util.h:		vfs::GetPathnames(g_VFS, "sub_folder_b/", L"*.txt", pathNames);
--
simulation2/Simulation2.cpp-	VfsPaths pathnames;
simulation2/Simulation2.cpp:	if (vfs::GetPathnames(g_VFS, path, L"*.js", pathnames) < 0)
--
simulation2/Simulation2.cpp-	VfsPaths pathnames;
simulation2/Simulation2.cpp:	Status ret = vfs::GetPathnames(g_VFS, path, L"*.json", pathnames);
--
simulation2/components/CCmpAIManager.cpp-		VfsPaths pathnames;
simulation2/components/CCmpAIManager.cpp:		if (vfs::GetPathnames(g_VFS, L"simulation/ai/" + moduleName + L"/", L"*.js", pathnames) < 0)
--
simulation2/components/tests/test_scripts.h-		VfsPaths paths;
simulation2/components/tests/test_scripts.h:		TS_ASSERT_OK(vfs::GetPathnames(g_VFS, L"simulation/components/tests/", L"test_*.js", paths));
--
ps/SavedGame.cpp-	VfsPaths pathnames;
ps/SavedGame.cpp:	err = vfs::GetPathnames(g_VFS, "saves/", L"*.0adsave", pathnames);

In D2005#83640, @Nescio wrote:

! @Krinkle wrote:
I'm not very familiar with auras yet, can you elaborate on that? Is there a Trac task for that?

Have a look at the screenshots you posted. As you can see all relevant information of the aura is already displayed automatically (the "Religious Fervor" line). Which means the tooltips of iber_monument.xml, maur_pillar_ashoka.xml, and pers_ishtar_gate.xml can now be purged.

Oh, I'm referring to saving and loading :)
That causes problems with Vector3D in D1971.

In D1991#83730, @Freagarach wrote:

In D1991#83555, @Krinkle wrote:

Yes. Test plan I wrote in the commit myself includes those steps, and I've confirmed them locally as well before submitting. The game compiles, starts, and can create a game and select/move units without errors.

Did you test (de)serialising?

If you have some time, maybe it would be nice to have a small video on youtube demonstrating the feature. Nothing fancy.

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

• Some target instanceof Vector3D -> `typeof target == "number".
• Some objects split over multiple lines in "UnitAI.js".

In D1991#83555, @Krinkle wrote:

Yes. Test plan I wrote in the commit myself includes those steps, and I've confirmed them locally as well before submitting. The game compiles, starts, and can create a game and select/move units without errors.

Did you test (de)serialising?

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

In D1337#83716, @wraitii wrote:

Rebased - needs some cleaning, like the anti-cavalry formation no longer has a walk animation which is annoying - I guess I should group the animations better. The limit of one variant per file is quite annoying because it means one must change a lot of files every time -_-
Still would work with D1901

In D1979#83715, @minohaka wrote:

In D1979#83688, @wraitii wrote:

Actually working correctly this time.

What exactly needs to happen for these fixes to land in the public repo? It seems a bunch are testing and get turn off when the unit motion doesn't work as expected?

Rebased - needs some cleaning, like the anti-cavalry formation no longer has a walk animation which is annoying - I guess I should group the animations better. The limit of one variant per file is quite annoying because it means one must change a lot of files every time -_-

In D1979#83688, @wraitii wrote:

Actually working correctly this time.

I guess you don't understand the concept of an iteration or an MVP.

Also, there are quite a few lines of these:

let attackGround = target instanceof Vector3D;
	if (!attackGround)

Would it not be better to instead check for what it *should* be? So target instanceof number -> do entity-related stuff.
This would also circumvent the problem that during saving/loading the fact that the target is a Vector3D is lost.

StatusEffects name is problematic I'm afraid.

In rP22305#34318, @elexis wrote:

If there were sync request member variables, it actually would be better to have the distinction.

Reviewed By: Kuba386

Would have been good if there was mentioned which aspects were reviewed, what was tested.

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

Reworked slightly with better comments and no navcell fix which should not be needed. I believe the GOAL_DELTA was intended to do something slightly similar at some point, and is also removed.

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

• Trade-window resizes to largest of "barterable" and "tradable".
• Removed extra ")" in PetraAI's "diplomacyManager.js".

Commandeering to make small changes @ @wraitii's request.

Well it's up to wraitii to review those, so I guess up to him then.

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

Actually working correctly this time.

Without having looked at detail, the objectives of these two commits look very good. If I understand correctly rP22302 was only the consequential cleanup of rP21865, but did not fix some reported crash on Slackware on the forums (as rP22302 already fixed that), correct? (Otherwise it should be added to Alpha24)

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

@Itms Can you close a revision or should I abandon this?

I think some changes I made in this diff should be moved to seperate minor diffs:

• GetTargetPosition2D/3D-functions.
• FaceTowardsTarget to be like in D1958.
• Formation target/move ranges seperated from the normal function calls.

What do you think, @Stan, @wraitii?

@Freagarach feel free to commandeer this with the fixes above.

In rP22081#34253, @wraitii wrote:

As noted on IRC, this triggers an infinite loop in JS (so contrary to what said above, the segfault is related), because of some unknown (so far) issue with attacking as formation (which was removed by D1220 otherwise).
I don't think we can sanely guarantee that attack-as-formation works right now, even if this particular case may be fixable - so it should probably be changed.

There is a simple, infaillible logic to making the hierarchical pathfinder not a sub-class of the long-range pathfinder: you can perfectly use the hierarchical pathfinder without a long-range pathfinder (the reverse isn't true).
If anything, we could make the hierarchical pathfinder own the long-range pathfinder, but the opposite didn't make sense.

I also made three of the patch's iterations. But it doesn't matter much.

In rP22295#34278, @elexis wrote:

Reviewed By: Wraitii

Reviewed By is reserved for people other than the author.
Comments By: Itms can be added when people influenced the patch without having accepting it.

The reason why I moved the stateful calls outside the functions was mostly in planning of further diffs, which remove StopMoving() and "FacePointAfterMove", i.e. the duplication.

In rP22266#34230, @elexis wrote:

No notes.
That these templates shall not appear in the list of placeable templates may be true, but there are also the generic templates that should not appear in that list.
Also that a template shall not appear to be placeable doesn't mean that it is impossible to place it if it would appear in the list.
Hence unplaceable/ would also be imperfect.
Another possibility would be hidden/, but that also is ambiguous. Everything is ambiguous.
Perhaps unplaceable/ and a README.txt defining unplaceable/ as not appearing in the Atlas list of entities would be the solution that satisfies all problems (including the clarification that a template that may technically be placed may be contained in that folder).

True about the warning. I was merely following the spec at https://github.com/0ad/0ad/blob/master/source/simulation2/Simulation2.h#L193

(Audit comment at https://code.wildfiregames.com/D1736#83668)

Destroying INVALID_ENTITY is valid and should do nothing.
The current code will send MT_Destroy messages when doing this, which is un-necessary work and feels kind of broken to me.
Early-exit instead.

ShouldConsiderOurselvesAtDestination from rP17226.
Agree with that previous name being broken because this is only about the unit, not about the reader.

unit_motion_integration_test.js

trigger scripts usually contain the name triggers:

./random/elephantine_triggers.js
./random/extinct_volcano_triggers.js
./random/survivalofthefittest_triggers.js
./random/wall_demo_triggers.js
./random/danubius_triggers.js
./random/jebel_barkal_triggers.js
./random/polar_sea_triggers.js

Except for scenario folders:

./unit_motion_integration_test.js
./treasure_islands.js
./Units_demo.js
./Triggers_demo.js
./Cinema_Demo.js

(But I technically don't want to spawn another rename clean thing now)

Reviewed By: Wraitii

Reviewed By is reserved for people other than the author.
Comments By: Itms can be added when people influenced the patch without having accepting it.

refs rP22105.

(I didn't check the includes)

As noted on IRC, this triggers an infinite loop in JS (so contrary to what said above, the segfault is related), because of some unknown (so far) issue with attacking as formation (which was removed by D1220 otherwise).

Fixes rP22269.

Regardless of whether and how special/ is renamed, territory_pull.xml must be moved to a different folder.

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

Do what I say above.