Anything else except the dots and pointed change?

Thanks for the patch

Can't the values be totally nuked if they will not be used at all?

We don't need enums, thats correct.
But they help when changing strings/values to make change only on one place.

Why do we need strict checking? == is totally sufficient here.

Also performance is not the question since number of messages for turreted is just subset of original number of messages from garrisoned.
Only additional cost are extra variables but amount of data is not affected.

Its not complete now.
If someone would want to use it, they would need to update proxy and other stuff in common api.

Why to give option to occupy turret then to api?

How no?
Ai gets information through proxy and messages.
If she doesn't get memo that unit is in turret state, she will act like it would not be.

See comments on diff

@Freagarach GarrisonManager and AIProxy?

messageObject fix

fix translate

rewrite to class, edit displayed message

thank you for working on this.
Good job so far.

Can you please elaborate why to draw it only with glsl?

Can't comment on patch itself but...

That is sus (playcode)

const ret = [];

@Freagarach can you also have a look if something is not overlooked just in case

Thank you for the patch

some comments

please do not replace undefined

Forgot explaination:
You had it inside enabled function, which was returning true or false depending if dialog is enabled, so you assigned it to variable each time, this function would be called.

irrelevant now

Hi,
thank you for picking this up.

trying to fix my stupidity

There are no tips for any other biomes

Not argument to remove existing ones, if something is missing, finish/make it.

Nice catch.
There are also more tooltips with "wrong" style if you are interested in fixing them, but thats for another patch.

Thank you for the patch 🐺

ping @wraitii

Check with code for promotion, if no rounding is done there, then ceil instead floor else you end up with 150/150 and not promoting what looks worse

Update message

All user chosen settings are persisted when changing the selected map or maptype, except where the selected map overwrites the setting value and except for Scenario maps which still use the default value where the map doesn't specify the setting value.

In D4305#183896, @Jammyjamjamman wrote:

In D4305#183890, @Angen wrote:

There is still issue.
If map does not define attribute and you switch maps, the attribute from previous map will carry over so you will end up with 2 and possibly more settings for the same scenario map depending from which one you switch.

As far as I can tell, this bug exists in A25, but I've fixed it in this patch :).

The original logic done by elexis was as follows as far as i remember:
If map defines some property, that property should be set.
If map does not define property, preciously set property by player or one from persistent match settings should be used.
Current issue with scenario maps is, even if property is missing from the map, value cannot be changed by player.
Notice we have this issue only with scenarios because they are locked by default.
Other maps should not get values reset.
This probably happens with other settings, will need to check that.

There is still issue.
If map does not define attribute and you switch maps, the attribute from previous map will carry over so you will end up with 2 and possibly more settings for the same scenario map depending from which one you switch.

Or generated placeholderText could get valign parameter and adjust position internally.
If someone would want to adjust such a position on another places.

@Freagarach do you plan to commit this as it is right now?

hmm, yes, but thats again /mod dependent on /public
probably would need to move it to /mod
also, need a way to get remaining time

Ok, i get it now

Wait, didn't you say they are promoted to next rank?