@Freagarach this D3833: Map browser: input filter, also filter random map entry

Hi, this is very awesome. I will test this later, but meanwhile I have a suggestion.

Congrats on your patch!

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

Build was aborted.

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

modifier

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

Fix a number of issues. Should be green.

Nice addition, thanks for the patch!

In D1323#167473, @Freagarach wrote:

Positive trickles are handled by the ResourceTrickle component.
The main difference is that for Upkeep you can have an effect when the upkeep cannot be payed, handling that also for positive trickles either needlessly complicates those, or limits the extendability of the upkeep.

In D3866#167471, @vladislavbelov wrote:

But why if you can simply notify all singletons on restart?

That seems more complicated to me than what I'm doing here, to be honest.

Adding the word "on" for the chat description; added context to "FAQ"; adjusted the tooltip description.

Build went wrong https://jenkins.wildfiregames.com/job/vs2015-differential/5103/console

In D1323#167472, @smiley wrote:

Why not call this Trickle or something and handle positive trickles here as well?
I don't see any fundamental difference between negative and positive trickles.

Positive trickles are handled by the ResourceTrickle component.
The main difference is that for Upkeep you can have an effect when the upkeep cannot be payed, handling that also for positive trickles either needlessly complicates those, or limits the extendability of the upkeep.

Why not call this Trickle or something and handle positive trickles here as well?

In D3866#167460, @wraitii wrote:

While I agree that we ideally shouldn't have unpredictable lifetimes, this is simply not the case while we have the current 'restart' logic for mods, and so I would rather make things safe to use than unsafe as a default, so I'm keeping the validity token business

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

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

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

Use static methods.

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

Summary is wrong and meh

Build failure - The Moirai have given mortals hearts that can endure.

Fix upstreamed tests.

Build failure - The Moirai have given mortals hearts that can endure.

Build failure - The Moirai have given mortals hearts that can endure.

Build failure - The Moirai have given mortals hearts that can endure.

Update following Vlad's comments:

• Add a low priority & a regular priority queue.
• Continuation
• No 'real-time' thread spawning, I always have at least 3 threadpool threads.
• Haven't added the ability to request-long-lived threads yet.

PetraAI HQ needs an update.

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

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

Comment.

Since the overall opinion seems to be "Meh.", and I for one like this feature, I'll follow up on this.

Adding a FAQ button to the starting page

The max doesn't change. When it reaches the max eg 500 it stops regenerating. Then when you make it 1/500 or 250/500 it will grow back until it reaches 500 again.

In D3868#167382, @Stan wrote:

Regeneration doesn't respawn the bush after it's been depleted. I'm not sure you can build on top of berries though, so you'll need to deplete them to build.

One argument @wraitii had for the relative uselesness of regenerating berries is performance. It running all the time and not being used will mean that you'll waste some perf doing it;

Finally with regards to the function, I suppose it could be implemented with some arctan function, there are more options but I don't think computing expensive math functions is a good idea.

If the berries disappear when depleted, I don't think there's any point, as people are unlikely to notice it and it requires a lot of effort to handle correctly, since you have to stop your units from completely depleting the resource manually.
That being said, this is mostly a "strong don't care" on my end, if other people like it, whatever.

Regeneration doesn't respawn the bush after it's been depleted. I'm not sure you can build on top of berries though, so you'll need to deplete them to build.

In D3868#167378, @Nescio wrote:

In D3868#167306, @wraitii wrote:

I don't really agree with this for Fruit (at least for the early-game berries). These are meant to be consumable, and a slow regeneration just introduces micro.

With normal usage those will be exhausted and disappear. Apply the patch and try it yourself. It's just a nice extra for non-competitive players who want to explore the possibilities of the game.
Players who want an infinite supply of food can build farms and players who want to maximize their food income should go for the corral. This patch doesn't change that.

Regarding Fish, I don't really mind, but again to avoid micro we would need to make sure that the fish stay on map once fully collected, and ideally that units don't start collecting the 'regrown' fish right away.

As for fish, I quite liked the sigmoid growth proposed in the ticket, but I believe that hasn't been implemented.

In D3868#167306, @wraitii wrote:

I don't really agree with this for Fruit (at least for the early-game berries). These are meant to be consumable, and a slow regeneration just introduces micro.

With normal usage those will be exhausted and disappear. Apply the patch and try it yourself. It's just a nice extra for non-competitive players who want to explore the possibilities of the game.
Players who want an infinite supply of food can build farms and players who want to maximize their food income should go for the corral. This patch doesn't change that.

Regarding Fish, I don't really mind, but again to avoid micro we would need to make sure that the fish stay on map once fully collected, and ideally that units don't start collecting the 'regrown' fish right away.

As for fish, I quite liked the sigmoid growth proposed in the ticket, but I believe that hasn't been implemented.

if you would have different values for cc yes, from current code, no

Translate with context in Hotkey picker/Map viewer. Test successfull (translated).

translate for short words should be with context. There is (if it wasn't fixed yet) an issue in A24b that a dropdown text (like "Medium") in options is translated incorrectly.

In D3848#167242, @wraitii wrote:

Thanks for giving this a look :)

You're always welcome!

@Angen previously it checked for the presence of nearby dropsites (excluding CC) and if that was better it checked for a CC near. Now it only checks for dropsites (including a CC).
Do you think this will impact PetraAI's decisions? If so, I argue only in a good way ;)

I think it makes more sense for the structure to be able to autoproduce than the entity be able to be autoproduced. It is also more easily modified in the structure. One might want a structure that automatically produces a type of unit, while for some other structure human intervention is necessary.

This is indeed very similar to D3865: Auto-Queue feature.

I would like one change: add the items when production starts, so that there is always 2 items in the queue, the one being produced and the next one.
This is because otherwise Autoqueue is better than manual queuing, as it essentially performs "perfect" queuing, and doesn't incur a "working capital/in-flight" cost.

ok

Well, that is the point, they don't do the same thing :)
If a modder wants to have the fortress both garrisonable and turretable, it might want to do one of these things. Then it would be bad to hardcode the priority for one of those in this function. One could add a variable, but then it is clearer to have two seperate functions.

how troublesome it would be to have one trigger function for it?
so triggers just pass templates for units and where to garrison in one go instead of modder needed to distinguish between turretholder and garrisonholder since essentially they both do the same thing.

Well, the regen is so slow that you won't notice it :) So it won't incentive micro.

I don't really agree with this for Fruit (at least for the early-game berries). These are meant to be consumable, and a slow regeneration just introduces micro.

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

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

We have had 4MB buffers in Profiler2 for a while now, so this seems like a straightforward change. We would probably gain a bit of memory by using utf, but I'm not sure the low-level windows APIs support that (maybe once C++23 rolls around with std::stacktrace?)

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

Still early, failed to update half the function.

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