I am not so sure whether this is any less arbitrary. In other games, the primary member seems to be the bulk of the army. That doesn’t necessarily mean numerically.
(Just a random thought, do what the reviewer says and you will be good)

typo. 8 -> 18

That 6s performance is achieved by nuking the 27 already IIRC

It helps, but the best I achieved was 18 seconds on 512 8 player mainland. You might have better luck with nani's patch.

(Apparently refs #2264. Overall design seems to be the same.)

Why would I know that? When I first mentioned that none of this stuff are going anywhere, (most of those posts were removed)

I guess someone is confusing Wildfire Games for their personal patchslave.

So, best I can do is guess based on evidence. The way I see it, I am doing wfg a favor.

1. Look at the date on which this was uploaded
2. Look at what was changed
3. Try to come up with a reason

Adds literally nothing of value whatsoever -.-

Nobody cares about tiny maps anyway.

Status correction. Changes are not planned. (at least not relevant to this status)
Also, this is not the only changes relevant for priority.

Patch by smiley

Is it really? ax -> in hardly counts as a change, let alone a patch.
Is there legal meaning behind that?

(There have been a release *after* this was found)

The cathedral and the bazaar
To be honest, i never figured out which was which. It's all cathedrals.

If you've got a way to dramatically reduce that and it proves to work then it's practically guaranteed to be accepted.

https://youtu.be/uCGD9dT12C0

I have already checked out this branch. I feel the constraints took a right step, but I always favored using the objects directly without proxies. I guess that needs a detailed analysis.

You should submit this.

You have done far more valuable things. I guess it doesn't matter if they are here or on a local machine.

Yeah, I found the 6-36 thing hard to believe too. Way less and faster iteration and way more efficient cpu cache usage might be the reason. The significantly JS typed arrays would have something to do with it too.
Anyway, we are now speaking of things which does not matter.

requested changes to this revision.

I don't have any other answer than requesting someone else to commandeer.

I just wanted to point out that the changes to tileclass is unneeded and only removes a possibility. The chance of someone needing to count the number of tagged tiles within a radius is not that far off.

(First two is from a significantly optimized tileclass system)
Without early return.

Setting biome generic/alpine.
Generating Mainland of size 512 and 8 players.
Creating playerbases... 0.221s.
Creating bumps... 2.384s.
Creating hills... 0.593s.
Creating forests... 1.514s.
Creating dirt patches... 0.986s.
Creating grass patches... 0.615s.
Creating stone mines... 0.013s.
Creating metal mines... 0.004s.
Creating decoration... 0.213s.
Creating food... 0.016s.
Creating food... 0.008s.
Creating straggler trees... 0.248s.
Total map generation time: 6.848s.
Total entities: 16350, Terrain entities: 12882, Textures: 13.

In D1501#62917, @aeonios wrote:

I replaced the tileclass member counting function used by constraints with a function that returns either true or false, using early exit for success/failure depending on the type of query. The early exit should moderately reduce the cost of constraints checking, which is probably the largest single cost for generating maps.

I researched it, wrote it, tested it, benchmarked it and compared it with old code on my own. It was definetly not easy work.
To answer the question, past me would have come up with something better than "idk man, i am not sure if thats even something i want at this point". Honestly, from what I can tell, it sounds horrible.

I guess I focused on the wrong keyword there. (given your stance on both, I wasn't sure)
All that matters to me is the intention. Not the phrasing.

If the people/person who cares about the thing can see it, I am content.
Making things public did not really helped much in the past, which probably played a part in that view.

Is it private wip crap?

Irrelevant. I found a defect and I am just pointing it out. With arguments and opinion for why I think it needs to be fixed.
Does it make much of a difference anyway?

I only considered two things, the result is wrong, and this gets called with such points quite often. Since it got resolved with the rewrite, I either had to reintroduce the bug for mapgen hash matching or leave it alone.
I won’t raise a concern. I will leave it up to you to decide whether the current results are acceptable.

I think the gift wrapping algorithm was implemented based on this description: https://en.wikipedia.org/wiki/Gift_wrapping_algorithm#Algorithm

Indeed it is. I found this while investigating a mapgen mismatch following an algorithm change, and found it interesting.
Btw, this does imply this is technically wrong since a placer called for points on a line should at least include all the points of the input. Someone raise a concern or something?
This does get called with such points quite often.

[{x:265, y:26}, {x:266, y:26}] for [{x:269, y:26}, {x:268, y:26}, {x:266, y:26}, {x:265, y:26}] is what the code does. Which vertices would constitute a convex hull. The term convex hull is being bent here. A Convex Hull implies a polygon. Co-linear points cannot form a polygon regardless of how they are connected.

Mind elaborating what the expected result should be for points on a straight line? (Not what the code does, what it should do?)
I am just interested in the reasoning.

Probably. Whether it interests the relevant people is a different question.

(A certain other project also has this feature implemented. Mostly irrelevant, but if this is not committed before the first release, it might be of some interest)

Angen also have a patch doing this. See the mythology mod.

I still have no clue what this feature is? Does it allow giving order to one unit even though you have multiple selections?

80% improvement on some maps. Already decided. As mentioned before, js “pureness” is a moot point. Take what you can.
Btw, JS iterators only have a next() function.

(Maybe add an iterator?, for something like tileclasses, it may not be relevant, but I assumed this was not to be restricted rmgen/ )

But for 15% I'm not so convinced that it's necessary to sacrifice JS pureness.

Somewhere between 30% (most cases) to 50% faster.
Of course, it depends on how much mapgen is spent in tileclasses. Some maps spend more times in placers. But for a giant Ambush map, the 30% was 86 seconds. So, mixed feelings about this. But, you never know until you write code.

(I assume you have checked the other sizes. There is a tradeoff between faster iteration and the number of false negatives.)

Tileclass patch refers to actually using this thing. And there are a few cleanups in there like nuking rangeOP. But the whole performance improvement is the direct result of solely using this.

A giant mainland map doesn’t really prove it. A large grid with a few points is what mainland offers and is exactly what the bool array method excels at. I wonder how it would perform in a grid where it would have to go to the bit-by-bit check quite frequently.

The tileclass optimization patch is using this patch only. So, the performance improvement is a direct result of using this. Or we can always write a new data structure that can eliminate half the remaining grid on each iteration.

how much it would add (more than nanis patch? so much more that it's worth sacrificing the JS-pureness?).

Well yes. The current TileClass.js uses wrong values for the rangeOP. The way I tested it, there would have been no false results like that. That was how the error was found, so I guess the methodology is correct.

whether it's feasible at all (may not result in a JS/C++ interface overhead bottleneck), and if it is,

Back then, I started implementing it in a way which does not expose any tile class to js.
It would have worked something like,

Engine.AddTileClass(ID, size);
Engine.AddToTileClass(ID, [p, q, r]);
Engine.TileClassGetPointsInRadius(ID, p, radius);

There is a mismatch between the < 27 and >= 27 code path, creating different maps, nani had investigated it too. It would be good to know which one of the two is wrong in order to fix it if it's the one we keep.

I guess you would be out of the loop on this one. But the 27 mismatch was found. And I failed to find any mismatches. But nani claimed that he found mismatches in water maps (only). (This was independent work from both sides, so it is hard to establish conclusions).
Regarding, rangeOP, I have plans to replace it with something working on the same principle but much clearer. But, that is not likely in the near future.

Since I was mentioned here and all of this has been discussed with the author before.
Using this would be a significant improvement. Especially for tileclasses. Since it allows eliminating up to 16 tiles in one iteration. This was confirmed by both of us.
Regarding the 27. Just revert the commit that introduced it. Only rangeOp existed initially. And the mismatch issue was found. (I could not reproduce the mismatch you mentioned on water maps, which really does not make any sense to me).
And I proposed moving the tileclasses to c++.

(I am just removing this from the queue of people who actually can do something)

so I don't see anything wrong....

Ok.

(In the while condition? Is that even legal? I'm currently stuck in c++ bytestream hell otherwise I'd have tested or looked up.)

Probably not. (Feeling too meh to test)
Edit: Yes, it is not legal.

Then there's the hypothetical race condition where the user doubleclicks on some XmppClient initialization button twice before it's disabled. But that should be caught already

Evidently, it is not. That is exactly the problem (at least that’s the gist of it.)

Seems like the first steps and the observed problem are missing.

Not registration, just when logging in. Although, the problem would probably exist then as well. The problem is a second xmpp client being created while the earlier one is logging in. And hence an assertion failure.

Press continue, click and accept any of the prelobby docs, see that the continue button is enabled again and press it.

Try now.

Does look correct now apart from this one thing.
(Would accept the revision but that would be pretty meaningless.)

Add yourself to gui/credits/text/programming.json (path might be wrong).
And also remove the unnecessary three files from the diff. Only needs the changed JS file.