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 sun angles 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.

Fix tests and minor reverts.

The lobby ratings bot suggests that its available at least for rated game. 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.

Replace with SDL functions

This is the desired positions for this placement right?

It seems like team placement patterns is purely an rmgen2 construct currently. However, the consensus at the time was to rewrite the maps using the rmgen2 proxies to instead just directly use rmgen. However, that is not an easy effort so this wrapper around rmgen is here to stay I guess. _kali had made several interesting maps and deleting them is not an option without rewriting them, and rewriting them is going to take ages (the effort was started with D1577). Refs #4947

SDL_GetCPUCount (IIRC it uses sysconf(_SC_NPROCESSORS_ONLN)

Indeed, https://github.com/libsdl-org/SDL/blob/main/src/cpuinfo/SDL_cpuinfo.c#L638
The smart thing to do would be to let SDL handle as much sysdep stuff as possible. The actual usage of these code is really not worth the effort of maintenance.

Could have a filter that darkens the background perhaps? The gold on yellowish terrain wouldn't be an issue then. As done for the paused overly currently.

Okay, that sounds about right.

But why should the timer be reset when an ally dies trying to protect the team wonder?

Doesn't it seem unfair that you get punished for doing so?

I would say in this case the timer should actually be reset because the team holding the wonder got stronger with the addition of a new ally. Moreover, it also implies different timers for different players depending on when they allied.

Apparently Han Chinese is the demonym. In which case this isn't exactly right either. I would imagine this is equivalent to calling Roman fortresses, Rome fortresses.

Yet another option is to just have named exports on the module entry file for onInit and onTick. Both of these methods would work the same way (other method being explicit registering via Engine) under the hood, but this might be more natural JS code.

Thinking some more about this, maybe we'll want the Engine to pass a writable Engine.entryPoint attribute that we set the init() functions to, as a way of expliciting the hardcoding?

I have non-exhaustively tested this and LGTM.

Nothing obvious remains as far as I can see.

(This adds a proxy to cmpTemplateManager, it doesn't keep a static local template loader. But I do agree with the sentiment that globalscripts shouldn't have to rely on such details. Passing around a function not guaranteed to return the same output is also somewhat meh to be honest, cmpTemplateManager.GetTemplate shouldn't have to mirror TemplateLoader.GetTemplate for things to work.)

Won't be possible to resolve files outside of the VFS, when you meant Won't be possible to resolve files like 'gui/something.js'

Its usually unlikely that modules would have to resolve anything outside of their root. However, that doesn't seem to hold true with the structure in gui/ though. Then there is the case of trying to import code from globalscripts. Which would be somewhat messy without absolute paths.

Fix filename going out of scope as JS::CompileOptions::setFilenameAndLine does not copy
Use ScriptConversions

Assertion failure: aDst + aNElem <= aSrc || aSrc + aNElem <= aDst (destination and source must not overlap)

Fix build

AutoCheckCannotGC needs a scope

Add tests

Add hotloading

Covert to class to keep cache exclusive to a ScriptInterface

The cache cannot be shared over interfaces as the modules themselves are bound to a compartment.

I find this an improvement over the status quo.

Ideally this would be a whole new thing that stores the canonical game state I guess.

Relevant discussions on D4486, D4612, D4613, D4618 and D4630 regarding the overall added complexity of trying to make the existing code work cleanly.

Sounds like bandaids on top of bandaids. In which case I would much prefer to move the GetTemplate call one level above to whoever is calling loadCivFiles. Although I don't really care enough to outright reject this either.

I have already considered this approach dead to be honest mostly because the costs of actually making this global really outweighs the benefits without some major refactoring. Especially the CParamNode fiasco.

As far as solving the problem goes, honestly I find it wrong to let that function be used in global scripts because global scripts ought to not have to rely on C++ class details. This even adds a CTemplateLoader to the component manager because it's ScriptInferface also needs to register these functions. Everything that needs global scripts now also needs a CTemplateLoader which just seems wrong to me. Notice that this isn't the case for engine globals such as the VFS.

It might be somewhat worse because it adds convolution instead of duplication.

The point was that it's unknown without looking at the macro. They resolve on the source layer, not on the syntax layer. There are far less unknowns if it's an actual function of a variable even if you don't know how it's defined because those have restricted scopes.