I would like to understand why you implement a method to retrieve SupportedBiomes if you already have it in atlas

Mostly because I wasn't aware you could parse JSON in atlas before writing this and just left it there. This is somewhat abandoned by now.

In D4775#205195, @Mercury wrote:

The order in which a client generates messages is preserved even if they go over the network.

Seems to be the case indeed.

Fix syntactical errors.

In D4802#204817, @Stan wrote:

if the JSON specification says arrays are always parsed in order.

It does, see JSON RFC.

Is there any advantage of having an index attribute rather than relying on the order of definition? I guess it would allow having similarly named tracks grouped while not having them played like that, but is that worth the tradeoff? An attribute also makes it abundantly clear to someone not familiar with this code.

Haven't gone through all yet. Just some skim notes.

Properly handle none team players

• Make config variable naming consistent
• Check whether the passed in upgrade at least exists

• Minor lint changes
• Set plan ID
• Move damage priorities to config

Note to self/anyone else interested: One could also use this in the army manager to upgrade units as well. If the army composition is more melee, the persian champions could instead be switched to archer variants to balance it out and whatnot.

Makes sense.

const corrections and use getMaxAttackStrength

Now back on the issue if @lyv is right and which is indeed unsafe we might have some issues.

I did check it afterwards and the premake function handles it properly, and`which` not being formally standardized isn't a deal breaker as the game probably won't compile on those systems anyway. The patch did work in that state as well, ultimately it comes down to your preference.

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.

I wonder if the checks should be flipped. Since the variable is set after reading the wiki, if trac is outdated or the distro suddenly decided to ship it as wx-config, it would fail unnecessarily. Also, I think we should remove that part from the wiki and instead make this error message more descriptive so the flag only becomes relevant when wx-config is not present.

Won't just changing the repeat time be somewhat obsolete since units would go out of sync after the first attack anyway once the UnitAI takes over. If players retarget, this wouldn't really change anything as the animation won't be repeated. Assuming the mass in sync can one shot an enemy unit of course.

This doesn't exist currently, but there is potential to introduce a very ugly bug upon serialization-deserialization cycles. For example, if BuildingAI or a similiar component doesn't serialize the cached value and instead just refresh the cache, it would be OOS.

Pompeii and Empires is also problematic.

Those were not forgotten, and there are more than two team cases as well. See the comment on the diff.

What should be the outcome when there are 2v2v2 and other related configurations?
The current code would place three slots on either side and divide one team. Which might be acceptable. But 2 slots on one side, and 4 slots on the other side with no divided teams is also an option. I would actually prefer the current behavior because asymmetrical placement would get quite messy with extreme configurations.

General high level observations. Maybe wrong, I have not dabbled in this code enough to say with certainty.

• Is the gaia animal UnitAI supposed to handle the behavior of the player entities being attacked?
• Should cmpAttack actually care for this at all?
• Perhaps UnitAI should instead do this in INDIVIDUAL.ATTACKED state transition if the attacking entity is a dangerous animal and call nearby entities with the same owner.

I don't understand the purpose of the standalone="no" tag, below some related IRC conversations about it. Can I remove them?

Yes you can remove it, its only relevant when DTD is used to make sure its only used for validation. standalone is by default considered as no, so its doubly unnecessary.

pull0ad is convenient and probably enough for me as I rarely have to patch binary files.

I download the raw diff and apply it with patch. For most cases, it works good enough. I simply don't have arcanist installed is the main reason. Using patch is by no means a better workflow though.

the files are always empty and not deleted

If you are applying with patch, you can use the -E flag. I generate patches using git diff which has a slightly different format (even phab shows those files as just deleted while this revision shows the files cleared). If you are using arc patch I have no idea what to do.

Forests might be some trouble though as they should preferably have same style as the rest of the map, and to balance them is not an easy task in my (now blurry) experience. The amount of trees can vary quite a bit for fixed parameters, and hard constraints can make them look unnatural.

Is it okay if they are roughly the same? Being visually similar in size might actually be enough.

fix build

So it seems there would be now two distinct groups of resources. The primary group directly adjacent to the CC, starting animals, small forest, berries and two mines. And a secondary group somewhat far away but still part of the greater player base. Neutral resources would be outside of the greater area I suppose.

I believe simplifying it rather than allowing for tile by tile priorities is actually the way to go. Which can then fit in nicely with D4680.

Superseded in rP25816

Following an IRC discussion, a former undertaker of GUI unspaghettifying recommended switching over to an OOP approach.

Refs #6580

In favor of D4680

Superseded by D2710 and retrospectively speaking, unsure if getPointsInBB with filter callback was actually the right call over a simple for loop.

Overlapping logic is present in the tileclasses currently. If a generic bit array structure is desired, it could be placed into globalscripts and TileClass could be updated to use that for the underlying storage.

I am not sure if this is actually going to be that usable unless the map scripts are explicitly designed to be balanced. And having the overall balance of it tweaked via Gamesettings seems somewhat ineffective. Having the option doesn't really matter if the underlying generation isn't updated too.

I will leave the biome thing to your judgement. However, generic biomes tend to go together. They are meant to be interchangeable. And the grass issue sounds like something all maps using the biome have, i.e, the biome needs to be fixed then.

The weird formatting led to fish being missed in actorHS.

Relevant history for the archaeologists among us.

• The ai could potentially use it to build a wall I guess. But it requires significant code from the ai to calculate the actual wall vertices. Maps could do it quite easily since the number of tiles are 16 times less.
• And then there is the whole tile vs navcell grids. Every tile would be 16 navcells to check against the pathfinder grid when used in sim as mentioned above. This could be abstracted away, but the performance when scaled up is a concern.
• Walls already allow overlap, so I would assume that wall builder returned walls would be buildable as well. It needs to be checked though.
• If this is something we want, the wall builder needs to be designed to be agnostic of internal rmgen details. So no direct references to constraints (the core functions could take an allows callback instead). ***

Unless there is a need, I find no reason to do so.

The wall builder changes are out of scope and somewhat extensive, so it could be refactored later.

I would rather just remove all the houses and possibly replace them by e.g. one temple or a market.

Agreed.

Texture and metal placement changes are good.

Go right ahead.

Some leftovers from the previous iteration.

I personally like lower sun angles as it creates better shadows and afternoon-ish sun colors, but we need variance.

rmgen2 is a convenience library over rmgen which handles more details implicitly and generalizes parameters. At the time it was introduced, it also contained some other generation code such as bluffs and whatnot. However, libraries of libraries usually suggest an anti pattern. #4947 and several commits later, most additions brought by rmgen2 has been ported over to rmgen1, and by now, its mostly just proxies. Maps written without those proxies ought to not have a dependency on it, and maps written with those are preferred to be without them. rmgen itself should have a usable enough interface that could be used without a wrapper around it.

The placement function and the map changes need to be split.

8a3068b3 Fix pyrenean_sierra map following a332ffe6 and 2988b811
a941a25c Remove now unused TILE_CENTERED_HEIGHT_MAP flag and replace getTileCenteredHeightmap with getTileHeight
2988b811 Use tile height for constraints and placers
a8c6755d Explicitly differentiate tile and vertices count
bd3947e1 Fix random map scripts following a332ffe6
a332ffe6 Rename heightmap functions and introduce a function to get tile centric height

It seems there are somewhat distinct changes in this that could be split out to another revision. But its not a large patch anyhow, so meh.

Fix tests and minor reverts.

The lobby ratings bot suggests that its available at least for rated games. But that's hardly useful. Significantly biased towards a few maps (read mainland).

In D4687#199200, @Stan wrote:

Any tests to make sure everything is working properly ?

The name biomes need to be changed to variant or something. Biomes has already outgrown the name. It's used to set day/night, and seasons. And with this, it would just get more divergent with the name. For instance what if we have maps that have mixed biomes under two variants? Refs, P275.

In P275#2245, @marder wrote:

Here is my list of random maps that are very similar to each other/ offer a very similar gamplay.
I don't think it will hurt to only have one of them left or combine them using biomes.

List updated.

@wowgetoffyourcellphone @marder and all other resident map judgement experts.

Seemed interesting from an old branch although I don't think this was a good idea, just an experiment that didn't work out.

Something fancy like capture/attack resistance being scaled with number of units within the vicinity is also an option. But that is a whole lot of range queries.

A terrain refactoring needs to happen at some point and might as well put the requirements here.

lint

Return a map of team ids and player ids.

That might make it needlessly complex.