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.

I skipped updating tests until general approach is reviewed.

Maybe depends on how failure is detected on the CI perhaps? If it doesn't use exit codes and parse the output or something, there would be some warnings because rmgen tests try to override the functions.

No strong opinions but the alternative deduplication proposed earlier in the other revision.

So slowing down loading is ok?

Make TemplateLoader cache thread safe

Is there a strong reason for a possible slowing down?

There shouldn't be. If there are so much calls to get template data, something is done wrong.

Need to trigger a rebuild somehow. This revision wouldn't be updated often. The parent revision would have most of the actual changes related to this.

Should use a shared_mutex right? Most calls should probably lead to a read as the game goes on so seems somewhat unnecessary to just exclusively lock always. Or would that not actually have an impact since the double locking might be more significant. I have a suspicion calls to this might actually be concentrated at the very beginning when templates would not be cached yet.

Fix CParamNode cache issues by disabling it. Measure performance without it. I somewhat doubt its called that much. It shouldn't be called that much.

As far as I can tell, rP3871 added this file without any actual usage, rP4659 added the exact same implementation to the rmgen tool, rP9219 removed the rmgen tool along with the original implementation of noise.

CParamNode

Remove the allocation counter

I guess everyone actually prefers this doesn't exist.

Actually, I think we can replace the static allocator with __libc_malloc instead.

The correct patch file

Simplify glibc overrides

I am planning to change this to a minimal arena allocator, which also would allow to cleanup this code a little bit. More importantly, it makes it no longer depend on the allocation behaviour of external code.

It would be an internal stance only used by the AI.

Feels like this should be a stance then. Obviously, preferably it should be in the AI, but if this route is taken, stances sound more correct than introducing minimum ranges.

Isn't kiting always: hit the target, but retreat if it comes too close?

I guess so. But minimum ranges bring over other side effects with them. The most noticeable being that kiting would end up being forced which might make the AI easier.

Since the ai currently has no per turn fine control over what the units do

Add relative paths. Notice that it won't be possible to resolve out of VFS root. Maybe these should be jailed within the relevant directory. MapGenerator would call with maps/random and be locked in maps/random/.

Savanna forests don't have a covered canopy. The trees are widely spaced. Also no palms I assume. This is relevant because all savanna trees are to be placed identically regardless of baobab or acacia which IIRC are the only two savanna fauna available.

In D4549#194200, @marder wrote:

(And changing any map code was not an option at that moment).

And since the last biome update introduced some non-actors as decoratives, that lead to actual bushes spawning inside/ too close the cc in some cases.

What was the reasoning for them not being actors if they are decoratives?

Yes, already voiced at D2454.

I may or may not have typed in the wrong tab.

Aside from that, it looks good to me. I haven't generated the map and seen the aesthetics, so whoever is commiting can use their judgement on that.

It would be nice to have a snow decal in addition to the base terrain. It would allow to have much more realistic details on the terrain.

This is still good and as before I believe this should be committed.

Case 1 -> Tweaking
Case 2 -> Extending

Btw, just to be clear, I am not suggesting changes in any way.

Random observations. Maybe relevant, maybe not.

I was mostly interested in having another person look at it. As you can see, back when there were multiple rmgen guys around, the chains weren't also really moving smoothly. Although we were reaching a consensus slowly before the almighty stall.

@marder , perhaps you want to continue this. This has extreme potential to make the maps nicer. Currently random maps cannot mess with texture blending priorities. If this were available, most jagged patches can be eliminated.

This is of course not that straight forward as the template mixins, as you still have to change the maps to actually use the new information...

Out of scope so not really relevant.