Thank you for the patch.
And sorry, that it took so much time :/

In D932#71723, @Polakrity wrote:

In D932#71681, @elexis wrote:

Wondering whether these two options shouldn't be located in the Gamesetup UI and Lobby UI part of default.cfg and options.json.

I think it's more instinctive to go to the "Sound" tab.

I tend to the same opinion.

But maybe u want duplicate these options in each tab?

Definitely not a good idea ;)

In D1472#71402, @Nescio wrote:

How I understand things:

• civbonuses are free and automatically researched and are available to one or more factions, but not all
• special technologies cost resources and are available to one or more factions, but not all
• general technologies cost resources and are available to all factions
• advanced_unit_bonus.json, elite_unit_bonus.json, and phase_village.json are free and automatically researched and are available to all factions

What to do with the special technologies can be decided later; they could be grouped together under special/ (see (D888 (outdated)) or mixed with the general technologies (see siege_bolt_accuracy.json).
This patch only groups the civbonuses.

Well, I'm not a programmer, my understanding of code is rather limited, nor do I have any idea how superimposing icons might affect performance. Feel free to propose a separate patch for it, if you think that'll be an improvement.
Two things, though:

• currently icon paths are hard-coded in aura .json files, e.g. "overlayIcon": "art/textures/ui/session/auras/buildgather_bonus.png",
• most sprites are 128×128 pixels, but the resource icons are 64×64

In D1778#72067, @Nescio wrote:

Basically that's what I did manually. To create _bonus and _penalty versions, I simply made two copies of the icon, pasting the bonus sprite on top of one and the penalty sprite on top of the other; costs about a minute, not much effort. And the icons are only a few kb each, so space is not really an issue.

Basically that's what I did manually. To create _bonus and _penalty versions, I simply made two copies of the icon, pasting the bonus sprite on top of one and the penalty sprite on top of the other; costs about a minute, not much effort. And the icons are only a few kb each, so space is not really an issue.

Maybe instead of having a new icon for each bonus and penalty could be sprite combination of icon + bonus or icon + penalty combined? (would also make it easier to add new ones with less effort on the art side)

Successful build - Chance fights ever on the side of the prudent.

@elexis I think is pretty much done now. Care to confirm? Thanks.

Any updates?

For 5, I would rather find a unique and appealing name allowing to discriminate the maps easily. Small/Large breaks immersion quite a bit.

Well, I'm open for suggestions, of course. *_large and *_small are probably less problematic placeholders than * (2) and * (4). Also, this patch is about renaming the file names. The map names as displayed in game can be different and don't have to be changed.

Why not make MaxAmount independent from Amount and rename it to Limit? E.g. a berry bush that starts at 100% but can only regrow up to 80%.

Spaced lines and fixed my name in the programmers credits file.

I think 2) should be kept: it's nice, for skirmishes, to be able to choose depending on the number of players, instead of saying that Azure Coast is only for two players.

The problem with that is that this
(a) it means it needs a copy of the terrain file for each instance (we have the file three times). For Azure Coast this case it's only 1.5mb, but other maps use 10mb
(b) if we already have the copy, why not add so much art to it, that the maps become an actually unique experience. For Azure Coast, one can say that the map terrain is so amazing and unique that one wants to play it in multiple scenarios. Notice that the entities are really unique (players start at the shore with a dock and a tower).
(c) if the argument is true in general, then it would apply to the other maps as well. So then we would be inviting to copy around many maps and just differ the playercount. But we don't want so many copied files, and we don't want to get the same map multiple times when we browse through the mapselection list (but rather get a map variant choice after having selected a map, if it's essentially the same map). Also there are random maps that can load *pmp files since a23, so I would encourage future devs to implement such map variants using that.
I'd be ok with it being a exemption though.

You need to add more classes. And you can't mix stuff. Dunno if it's good

Where can those be found?

It also sucks because you can't differentiate Growth from Fattening from spawning.

One can use , "affects": [Class] for that.

I guess that's somehow meaning that we should check design documents before deleting stuff.

(refs "treasure" and "design documents" / "design document repository")

?

I noticed from the screenshot that you use different button styles. They should be the same theme on the entire page. I favored the Stone buttons too (replay menu), but they are considered deprecated and should be superseded by the Red ones, and we should aim at making the GUI theme globally consistent. The Stone buttons on the other pages except for the menu buttons will probably be replaced. At least that was the plan few years ago.

@elexis changed code to reflect your comments and will refractor GameMap function if you think the rest of the code looks ok.

So first of all it's currently

(refs "treasure" and "design documents" / "design document repository")

About the naming dilemma:
The idea of the auras refering to custom, userspecified names of effects is unsettling me a bit.
With the approach in this version, all techs and auras would refer to ResourceSupply/CivRelatedName/Rate or ResourceSupply/CustomName/Rate.
With Nescios approach, all techs and auras would refer to ResourceSupply/Alive/Rate or ResourceSupply/Dead/Rate, which seems much more clear when comparing many templates/auras/techs.
So the question is how realistic are mods/vanilla specifying a ResourceSupply effect that applies to the entity in both alive or dead state.
(Perhaps in a fantasy mod, a rock that is alive and moves around and provides a replenishing mineral resource supply regardless, even after the point in the storyline where the rock dies. https://en.wikipedia.org/wiki/List_of_The_Neverending_Story_characters#Pyornkrachzark)
Such a mod would not only have to duplicate the "change" item, but also all effects of auras and techs refering to that resource supply would have to be duplicated (effect ResourceSupply/Alive/Rate or ResourceSupply/Dead/Rate).
But if that's the worst that's the worst that can happen from Nescios approach, I think that's still better than auras and techs refering to an <anyName/> rather than a fixed property name.
After all, having a separate ResourceSupply effects template per health state would likely end up in the mod creator actuallly picking different numbers for the two states and making the entity more interesting.
Also, one could provide the three way choice <Alive>,<Dead>,<Always> that was already hinted at in the code if one really wants to use the same value for both helathstates.

How about this?

Successful build - Chance fights ever on the side of the prudent.

• Update description
• Add infinite check
• rename functions
• Simplify timer call to only pass the key.

Add option to change the interval and restart the timers

If you want to implement it, why not, but notice that this can yield unintended consequences:
For example if flesh decays and a hero has a local aura that doubles the decay interval (smart man to use salt) but the decay of flesh starts only 5 seconds after the death,
woudln't the hero moving in and out of the range of the carcass (patrol command) entirely prevent the decay, because the timer is stopped and the delay never runs out until the timer is started again?

@elexis Anything preventing you to commit this ?

Successful build - Chance fights ever on the side of the prudent.

• Fix Vulkan warning
• @returns -> @return

Successful build - Chance fights ever on the side of the prudent.

For future reference.

In D1042#71075, @Nescio wrote:

Still to be decided:
1 what to do with the scenarios/Height Map *.png files
2 what to do with the three Azure Coast scenarios (identical maps, different player numbers)
3 what to do with the two Flight_demo scenarios (different maps, similar function)
4 what to do with the two Sandbox - Ptolemies scenarios (different maps, similar function; all other factions have only one sandbox)
5 how to differentiate similary named skirmishes, e.g. Corinthian Isthmus (different maps, similar names)

How about the following?

• 2, 3, 4: keep only one version, delete the others
• 5: rename them to _small and _large

Successful build - Chance fights ever on the side of the prudent.

Thank you, Polakrity. Two more.

One ticket about this. #3800

What do you mean by the sprite's attribute?

Successful build - Chance fights ever on the side of the prudent.

@nani Feel free to suggest values.

I can also feel the clouds move too fast relative to the city+river+desert+near mountain (looks like if the clouds are very close).

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

• Make the message filter a bit smarter

Successful build - Chance fights ever on the side of the prudent.

Fix lint

Perhaps Constraint -> HealthConstraint or HealthCondition.

Successful build - Chance fights ever on the side of the prudent.

• Add option to change the interval and restart the timers
• Fix the incorrect description
• Remove parameter from AddRegenTimer function.

(The naming is still a dilemma until we have a new idea)

I guess we keep the timer interval and delay unmodifiable by auras/techs (otherwise the timer would have to be restarted, which in the case of local auras might be considerable to problematic performance-wise)

Successful build - Chance fights ever on the side of the prudent.

• Remove whitespace.

Successful build - Chance fights ever on the side of the prudent.

@elexis Okay no problem remove the files.

Please don't add all the template changes in this diff, as they really change the gameplay idea and balancing.
This patch should only be about the code, and maybe one trivial example everybody agrees on of how the code can be used.
The gameplay changes should go to a separate patch where we don't have to discuss technicalities of implementation but can solely discuss the gameplay changes.

Thanks for the update

In D1718#71776, @Nescio wrote:

How is ResourceSupply/Fattening/Value different ?

Fattening is wrapped inside Change, right, so shouldn't it be ResourceSupply/Change/Fattening/Value then?

Sure could add a change

MaxAmount is the max amount of resource an entity can carry.

So MaxAmount is always larger than Amount? And what happens if MaxAmount is not specified?

Should be. In that case Max Amount is set to current amount.

Rate is not changeable by tech/aura. Any reason to change it over the Value ?

Actually I think both ought to be possible. E.g. heal_rate.json technology decreases Heal/Rate, not Heal/HP; for growth having smaller steps could make sense.

Okay but that will need way more code. Because you have to cancel timers for the rate to change I believe.

Now can modify text color, object sprite color type and size.

Made coder more clear added some checks, functionality.

Added search function, made code cleaner and made fixes mentioned by @elexis . Still not sure if we should show biomes previews.

How is ResourceSupply/Fattening/Value different ?

Fattening is wrapped inside Change, right, so shouldn't it be ResourceSupply/Change/Fattening/Value then?

How is ResourceSupply/Fattening/Value different ?