Rebased against master at d25309b (Wed Mar 2 05:00:23 2022 +0100). The only merge conflict I saw was that "chicken" was changed to "starting_animal" in mainland.js and african_plains.js.

I tested the patch and it works on Manjaro 21.2.3 with python 3.10.2

@Jammyjamjamman attempts to fix the remaining linter messages

Betterize the code

Computes the gap between allies based on radius(g_PlayerbaseTypes[pattern].distance)

In this example (mainland, medium), the 3 players are on the same team, but do you think they are too close together? If so, any suggestions or pseudo-code ideas on how to alter the algorithm on how to prevent that?

Fix placement of players when they are not assigned teams

Me and @Jammyjamjamman have found that on a setup such as a 6 player game, when 2 players are on T1 and the other 4 not assigned to any team, the placement is not correct:

Another attempt to remove linter errors

fix opposing teams spacing, finish de-linting

No, the circle doesn't look right either

@Jammyjamjamman the opposing teams are so close together (3v3 medium map)! Is there anything we can do about that?

Fixes more linter errors

Attempt to fix most linter errors.

As long as the scope of this patch as already expanded, I wanted to suggest enabling "allied view" as the default option. I just anticipate that the majority of hosts or players would want to see their allies when the game starts. Any opinions on this?

I added the besideAllies placement option to Frontier and Ambush

removed some of @Jammyjamjamman 's crazy comments

This fixes the error about the playerIDs.map function I mentioned in the previous diff.

This mostly uses existing code that's used for Frontier and Ambush to create the TeamPlacement drop down box, and adds the same options to Mainland and African plains, plus adds the "Beside Allies" placement option.

Duplicate of D2432

In D4283#182540, @sera wrote:

I'm not sure why you've mentioned implementing a command line parser. 0ad already has this.

A poor man solution only.

In D4305#183373, @Freagarach wrote:

In D4305#183351, @Langbart wrote:

[Dropdown] Map state: Concealed, Explored, Revealed.
[Toggle] Allied view

Given the rather minor impact of the bug fixed, and the (seemingly) large (code) readability improvements created, I'd say do that in this patch (which should also fix the bug this patch fixes now).

In D4303#183343, @andy5995 wrote:

In D4303#183277, @Langbart wrote:

Should the option appear if there are only two players? Better just disable and gray them out.

That would be a separate patch. The random option is also presented for the Frontier and Ambush map.

It seems the default when using "TeamPlacements" is to add that random option (not the randomGroup which is completely different); So any patch that changes the code to remove the random option would affect all maps that use TeamPlacements in the .json file.

In D4303#183276, @Langbart wrote:

In D4303#183277, @Langbart wrote:

Should the option appear if there are only two players? Better just disable and gray them out.

LGTM!

In D4303#183237, @andy5995 wrote:

I think it would be good to also add the "stronghold" formation that's used on the Frontier map. I haven't figured out how to implement it cleanly yet though.

I think it would be good to also add the "stronghold" formation that's used on the Frontier map. I haven't figured out how to implement it cleanly yet though.

temporarily revert african_plains to original version

remove unused tight_arc from g_PlayerbaseTypes (setup.js)

implemented TeamPlacement (per-map) settings similar to Frontier

In D4303#183165, @Freagarach wrote:

Also, have you seen the Frontier random map? That seems to have what you want.

clean-up

removed 2 duplicated variables

Still trying to get the value of g_MapSettings.EvenPlayerSpacing for the newly-added condition in the .js files. Still getting the same result. Always evaluates to true.

No changes, just regenerated the diff with 'git diff -U9999 master'

I completed removed african_plains_tg.js and mainland_tg.js. The option is now in the .json files.

So now I've avoided duplicating the maps, and just use 2 distinct json files, adding the setting "EvenPlayerSpacing".

These 2 maps are from the stock mainland and African Plains map.

After applying this patch, rebuilding, I tried this with a skirmish map I made. It didn't turn out correctly:

I understand you'd rather I use C++ code. I'm not famillar with C++ actually, so I'll probably not do anymore with this diff.

In D2432#102349, @Stan wrote:

Just for the record, only debian seems to provide a man command.

In D4283#182511, @Stan wrote:

Did you see https://code.wildfiregames.com/D2432

This obviously isn't finished yet. I wanted to get some feedback before I proceeded.

Sure. I'm currently building the game+developing this patch from the github mirror. What would "adding this option to atlas" involve?

Me and @Jammyjamjamman just tested it with an Internet game; no problems.

I didn't get any warnings or errors while patching.

imo, I don't really see any value in having periods at the ends of all these incomplete sentences.

My bad.. he ran make clean before re-compiling but didn't run clean-workspaces.sh. Doing so now.. I'll update here shortly.

In D2745#121607, @andy5995 wrote:

My friend who is using Manjaro 20, gcc 10.1.0 gets this error, before and after applying the patch.

Linking Collada
/usr/bin/ld: ../../../libraries/source/fcollada/lib/libFColladaSR.a(FAXInstanceExport.o): in function `FArchiveXML::WritePhysicsRigidBodyInstance(FCDObject*, _xmlNode*)':
FAXInstanceExport.cpp:(.text+0xbfc): undefined reference to `_xmlNode* FArchiveXML::AddPhysicsParameter<FMVector3, 0>(_xmlNode*, char const*, FCDParameterAnimatableT<FMVector3, 0>&)'
/usr/bin/ld: FAXInstanceExport.cpp:(.text+0xc12): undefined reference to `_xmlNode* FArchiveXML::AddPhysicsParameter<FMVector3, 0>(_xmlNode*, char const*, FCDParameterAnimatableT<FMVector3, 0>&)'
collect2: error: ld returned 1 exit status
make[1]: * [Collada.make:94: ../../../binaries/system/libCollada.so] Error 1
make: * [Makefile:177: Collada] Error 2

He's compiling the latest code from the 0ad GitHub repo, btw.

My friend who is using Manjaro 20, gcc 10.1.0 gets this error, before and after applying the patch.

I have a friend who can't build on Manjaro, an arch derivative, using gcc 10. He's going to apply the patch tomorrow, and I can post results here if still needed. Still needed?

I can't update this revision without creating a new one apparently. So I'll paste it.

In D1617#64738, @Itms wrote:

In D1617#64735, @andy5995 wrote:

I tried. Travis apparently has a 50-minute limit on tests. It terminates the build.

Would it be possible to make Travis pre-generate and cache a development environment where the libraries have been downloaded and built? This doesn't need to be done each time. The rest of the build process will take less than 50 minutes. At first glance this part of the documentation would be the way to go.

but it would be better to figure out how to make macOS work

In D1617#64692, @Imarok wrote:

I think Itms has the best overview about our CI and such things.

Based on @wraitii 's comment in this forum thread, I've removed the osx test from the PR on GitHub.

I tested this patch using Travis..

I applied D1582 and then this patch (@s0600204 said it's dependent on D1582) and I got a complete build on Slackware64-current with gcc 8.2

After reading the comments, I don't really understand what I should do next, if anything. Sounds like you want to fix this with another method, and need to discuss the best approach? I know it's low priority but just thought I'd touch base in case there's anything else I could do with it at the present time.

I tested this patch and added my results to the ticket.