In D4948#219960, @real_tabasco_sauce wrote:

@andy5995 @marder
what is the difference

The people who subscribed to this may want to subscribe to https://code.wildfiregames.com/D4948 instead.

If you want to include it into the mod / appimage I don't mind (IIRC many of the maps in the mod already have that option, so ux wise it wouldn't be much of a change?). Since it's something that specifically the mp community seems to request, one could even include this in the community mod if there is one for a27. Although not sure how much sense it makes to pre-release features in that way.

In D4948#211278, @andy5995 wrote:

In fact I was actually thinking about integrating some of these changes into the cm2 mod (since this patch won't be included until a28). If I could get the guts of this into cm2, that may mean more people would be able to test it. What do you think?

In fact I was actually thinking about integrating some of these changes into the cm2 mod (since this patch won't be included until a28). If I could get the guts of this into cm2, that may mean more people would be able to test it. What do you think?

Works for me on Manjaro 22.0.0 with the js91 package installed and passing --with-system-mozjs to update-workspaces.sh

@vladislavbelov The build on Bionic is fixed. Thanks.

I'll try it out shortly.

This breaks the build on Ubuntu Bionic. libfmt-dev on bionic doesn't include core.h because the upstream version of the 4.0.0 release doesn't include it.

Also there's some info in the meson FAQ about how to use wildcards

And if a decision were made, I'd help implement it. This is an example of how I implemented it on rmw https://github.com/theimpossibleastronaut/rmw/blob/master/src/parse_cli_options.c

Well, I guess I'm repeating myself a bit... a man page can be a bitch to maintain. I suggest implementing a parser like C's getopt or https://theboostcpplibraries.com/boost.program_options , and using help2man to generate a man page (which can be at least customized a little with a template).

In D4777#203603, @Stan wrote:

Ah nvm the last inline then ^^

Nice! After I applied the patch, and renamed /usr/bin/wx-config to /usr/bin/wx-config.old, this is the output

@Stan I'm sorry for using abusive language like that. You didn't deserve it. I had some anger that's not at all related to you and unjustly took it out on you. You're dedicated on work very hard on this project, and definitely I was wrong to state my difference of opinion in such a hostile manner.

In D4777#203583, @lyv wrote:

I am not sure the check should happen earlier. It's only relevant for the pyrogenesis atlas make process, building the other dependencies does not require wx.

Maybe easier on CI I suppose.

@Stan Well... who gives a shit what the ticket was about... if there's a better way to implement the ultimate goal of the ticket.

I was thinking something like

Ok, but why not check for its existence near the top of update-workspaces.sh?

Looks good @Stan , but the check and fail should happen earlier, before the Collada build.

Is it guaranteed that we'll get the error for compile settings earlier?

I did some more testing. Teams are correct in a 3v2 or 2v3 or 3v4 or 4v3, but in a 2v4, the placement is incorrect.

imo, this is a bug fix, not a new feature, so it should get merged before a26 is released if it can get reviewed in time.

Works for me. Thanks @marder

It seems like I see Latium played pretty regularly in the lobby. But I think it could be replaced by a rectangular map that supports all the biomes, like Mainland Rectangled in community maps. Nothing special about that one, it's just Mainland but with canyons on each side so the playing area is rectangular. Although Latium has rivers on each side, so more like Yekaterinaville (also in community maps).

Thanks for reviewing. It sounds pretty confusing and complicated to me, probably partly because I'm not proficient in Javascript. I'll free this up in case someone else would like to do it.

var clPlayer = g_TileClasses.player (painted in the createBases function)

Simplify

I suggest we give all removed maps to the 'Community Maps' mod, if the curator of that mod wants them.

In D4303#198634, @smiley wrote:

This is the desired positions for this placement right?

In D4303#198624, @smiley wrote:

I haven't looked at the actual arc function in detail yet.

(who freely and ethically admits to pinching code from other sources)

Well and good, but would need a link to the original in a comment with the relevant code. And licensing details of course unless the code is public domain and is sufficiently changed.

I understand there's a feature freeze now. Is there a chance we could get this in before the a26 release is if we removed the BesideAllies code and associated function, and then just keep the existing placements that we're already using for Frontier. So Mainland and African Plains would still have the same options for Team placement in this patch, but without the new BesideAllies placement (Then we stick that in *after* the a26 release). @marder

rebased against code in github master and fixed merge conflict in mainland.js

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.