In D5229#223356, @wowgetoffyourcellphone wrote:

In D5229#223126, @marder wrote:

if you want me to test this you need to send me the pmp file.

The pmp file isn't included in the diff?

In rP25894#61879, @Feldfeld wrote:

The function scaleByMapArea takes its default max area from a map size of 256 which is incorrect, as it should be 512 like the above function scaleByMapSize. Calling that function with that default would lead to incorrect results.
Since all random maps call it by the intermediary of scaleByMapAreaAbsolute, which uses its own maxMapArea, this has no consequences on current maps, and the fix is trivial (change the default value in scaleByMapArea to 512).

In D5220#223226, @phosit wrote:

@marder Should TERRAIN_TILE_SIZE and MAP_BORDER_WIDTH also be passed as an argument to the generator?

As option C we can just stick to individual functions that return an object of class PlayerPlacement, instead of methods.

In D5246#223211, @phosit wrote:

I don't like this interface:
If one wants a PlayerPlacement one would have to call two functions.
That's a two step initialization. (Which is bad IMO)

unrelated to the class / prototype discussion, just a quick update to make it somewhat functional.
At least mainland generates now.

at least from a simple test (just object creation and setting a value) the performance looks equal. Not sure what happens in complex scenarios tho.

The only thing I could find on phab was this:
https://code.wildfiregames.com/D4021#173216

I did some experiments with a class based approach here: D5246

if you want me to test this you need to send me the pmp file.

no changes - just re-trigger the CI

@sera 's inline

In D5214#222986, @Stan wrote:

In D5214#222984, @marder wrote:

This doesn't catch _all_ the cases where var (or let) could be replaced, but at least I'm reasonably sure that it doesn't break anything as is.

So if no one disagrees, I would push this during the next weeks.

Have you tried to do it with eslint? :) It has something to do it automagically.

This doesn't catch _all_ the cases where var (or let) could be replaced, but at least I'm reasonably sure that it doesn't break anything as is.

some more changes

In D5078#222665, @real_tabasco_sauce wrote:

@marder when do you plan to finish this?

ping/ just fyi @vladislavbelov since we briefly talked about it today
https://irclogs.wildfiregames.com/%230ad-dev/2023-12-03-QuakeNet-%230ad-dev.log

In D5210#221409, @wowgetoffyourcellphone wrote:

Nope, this looks good. I didn't realize the Ishtar Gate has this. It's not a buildable building is it? Regardless, I didn't intend to remove it from the gate in any case. Thanks for this @marder

rP27964

@vladislavbelov my bad, will include it in the next patch.

In D5198#221373, @phosit wrote:

Sorry for not reading the summary carefully.

no problem

In D5198#221359, @marder wrote:

In D5198#221356, @phosit wrote:

We could also make all functions take an object as parameter and return an object. (thats a nondescriptive interface, but IMO the best we can do)

That would be a non descriptive interface indeed. I will need to think about that more to decide if that would be better or not.

Well the returned object would always have the same properties. So that's a bit more descriptive.
Actually I don't think
playerPlacementCircle(distance, angle, center) is more descriptive than
playerPlacementCircle({distance, angle, center})

The first one gives nicer on hover argument/ parameter hints, at least in my editor.
I'm generally a fan of objects as arguments, just because you can use named arguments, but on the other hand you have to dig through all the functions to find out what parameter are actually necessary. See e.g. all the placePlayerBase[....] functions. It took me a while to figure whats going on there with all the different arguments.

In D5210#221376, @phosit wrote:

Maybe @wowgetoffyourcellphone wanted ishtar_game also to use eternal_fire.

In D5198#221356, @phosit wrote:

Do we have to validate the return value every time. Isn't a unit test enough?

Yeah, true. Although it arguably shouldn't matter computationally & having it explicitly in the library makes it clearer to mappers what they can expect from the function. I doubt that anyone looks at unit tests for that.

In D5198#221351, @marder wrote:

Do we have general guidelines for that?

Good question. You might take it to the forum.

Tbh not sure if its helpful. The people that are active on the forum and make maps will likely be able to change their maps if they are notified. My concern is more people that don't check the forum regularly. They would just get a broken map on the new release (Question is how many of these people are there).

It seems like playerPlacementByPattern is only there to make the different functions work with the same interface.
I don't know if there is much value in converging only the return type:
I think it would be good to also converge the names. Every placement function shoud be of the format playerPlacement* or something. We could put them in an object, then they would be callable like this playerPlacement[patternName](...args).

see description :) -> "Still TODO: rename all the functions & the user facing descriptions to be uniform (will be done in a separate patch)"
I just tried to keep my patches more minimal, so that in case bugs are introduced, they can be traced back more easily.

Another thing to think about/ open question:
This will possibly break some player made maps. - Especially when also changing from returning an array to returning an object.
So how stable should the api be ?
Should we provide deprecation warnings / or some kind of backward compatibility?
Do we have general guidelines for that?

This is broken.
See: #6891

fix some things I overlooked

needs to be update.
Note to self: don't forget about
const pattern = g_MapSettings.TeamPlacement;

include D5199 as the rmgen2 maps have to change either way and splitting the patch would basically just duplicate the manual work of testing that all maps still work correctly.

In D5082#221124, @Freagarach wrote:

^is this fair or unfair?

Yes.

I guess we want to print a warning if players are too close, such that all the players are notified and can choose to restart (on a bigger map). This also helps in debugging why some player on some map doesn't get walls.

In D5198#221126, @Freagarach wrote:

Approval for the added error. :)

a bigger refactor

empire has two calls, not only one

update & @Freagarach 's comments

actually do only what the title says

do less in one diff

In D4384#220630, @wowgetoffyourcellphone wrote:

Forced Capture hotkey now makes it possible to both capture or hunt the horses. @real_tabasco_sauce @marder @chrstgtr Does this address your concerns?

closed with: rP27937

forgot to close it

Differential Revision: D5084

In D5084#220717, @Freagarach wrote:

@marder can you take care of this? (Else let me know.)

In D4948#218015, @real_tabasco_sauce wrote:

Hi @marder I just made a mod so I can test all these on the most recent RC. Everything seems to work great so far, except groupedCircle and alternatingCircle seem to be reversed. They are reversed every map I tried.
What I mean by reversed in this case is I select groupedCircle and the placement is alternating, and I select alternatingCircle and the placement is grouped. No other placements seem to have this issue.

In D4992#217773, @wowgetoffyourcellphone wrote:

You could pick this back up since it's no longer feature freeze

In D4948#217375, @real_tabasco_sauce wrote:

Any word on this?
...
I think the wording @phosit suggested sounds good.

In D5084#216358, @lairkers wrote:

In D5084#216351, @marder wrote:

noted. I'll look into it once I have time.

@marder Is your plan to take this fix over? Otherwise I'd drive it forward once I have time according to elexis' suggestions. Didn't check the Danubius code yet.

In D5084#216329, @phosit wrote:

<elexis> a separate jebelBarkal_buildingTurret array would be cleaner to avoid double garrisoning if kushites receive a building with both turret and garrison points
<elexis> seems it was broken by rP25123. Outpost also has a Turret point, so danubius seems to be affected too. Tower does not seem to have a Turret point, therefore elephantine is not affected

thanks for the patch. lgtm & works when testing. If no one else finds a problem in the next time I'll be committing it.

In D4948#215986, @phosit wrote:

I don't know how "Random Group" is done programaticly. If it's true then it could be like that: "The starting positions are randomly placed across the map. Allied players are assigned to starting possitions close to each other."

Sounds good.

While we discuss the descriptions:

Two shorter sentence are easier to understand: "All players are placed on a circle that spans the map. Allied players are adjacent to each other."

And for alternating circle it would be: "All players are placed on a circle that spans the map. Allied and enemy players are placed alternating." ?