User Details
- User Since
- Apr 14 2021, 11:46 AM (157 w, 6 d)
Feb 28 2024
Feb 26 2024
Feb 25 2024
Feb 20 2024
Feb 19 2024
As option C we can just stick to individual functions that return an object of class PlayerPlacement, instead of methods.
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
Feb 18 2024
I did some experiments with a class based approach here: D5246
Feb 17 2024
if you want me to test this you need to send me the pmp file.
no changes - just re-trigger the CI
Feb 11 2024
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.
Jan 18 2024
Dec 7 2023
Dec 3 2023
ping/ just fyi @vladislavbelov since we briefly talked about it today
https://irclogs.wildfiregames.com/%230ad-dev/2023-12-03-QuakeNet-%230ad-dev.log
@vladislavbelov my bad, will include it in the next patch.
Dec 2 2023
no problem
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.
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.
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.
Dec 1 2023
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?
Nov 29 2023
This is broken.
See: #6891
fix some things I overlooked
Nov 25 2023
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.
a bigger refactor
Nov 21 2023
Nov 20 2023
Nov 19 2023
empire has two calls, not only one
update & @Freagarach 's comments
actually do only what the title says
do less in one diff
Nov 18 2023
forgot to close it
Differential Revision: D5084
Nov 16 2023
Oct 28 2023
Sep 13 2023
Sep 10 2023
Jul 27 2023
Jul 23 2023
thanks for the patch. lgtm & works when testing. If no one else finds a problem in the next time I'll be committing it.
Jul 21 2023
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." ?