Apparently not.

No it's not the same.

Max Amount 5000
Amount 4000
Limit 4500

Bar displays x/5000
Regen goes up to 4500/5000

Max Amount 5000
Amount 4000

Bar displays x/5000
Regen goes up to 5000/5000

Amount 4000

Bar displays x/4000
Regen goes up to 4000/4000

And why is it useful to implement something like your first example,
i.e. what is the use case for a MaxAmount that is greater than every Limit of a positive change,
i.e. what is the use case for displaying a bar that indicates that a resource can have up to 5000 res while it actually can't?
If that's useful to display something other than the ground truth upper limit, why is it not implemented for the lower limit as well?
I'm unconvinced by this field for the proposed feature implementation, but I'm not telling you what to do.

It's not actually. You're right with the limit thing.

Nope actually thanks.

Ah yeah indeed, didn't think of it :D

It does.

Delay decimal, interval integer; yet they use the same value range (milliseconds used by timers)

Fair enough. :)

Not it cannot because setAmount won't let it.

(change -> Change in the description, name capitalization indicates to the reader that the sentence relates to the the branded version of change that we defined above, not to be confused with whatever connotation the reader thinks about when reading the colloquial change)

Right.

See the cleanup patch for resource supply. If it's committed first no need to add todos.

Because in the gui the bar would get out of range. To check this, just set the value to NaN.

That sound more like a bug in the status bars code rather than a design constraint of ResourceSupply.
I recall there were also such problems when one uses the fast-actions cheat with packing/unpacking.

One could probably fix the status bar code. But I believe it's rational to assume that the max amount is always superior to the amount. If we really want to set a max regen level which I don't think we do even for units health, I could add a targetAmount tag in the regen blocks, that would prevent decay above and below that variable.

The maxAmount could be defined as the threshold where the effect becomes active or inactive.
The currentAmount can be defined as the initial amount in the template, independent of the effect threshold.

At least I think it could be used as freedom for modders to specify a template that could start with 600HP but only regenerates to 300HP?
(In which case one could also consider moving this to the effect item)

Then the name would be incorrect.

Also I'm pretty sure there is some other code doing some checks on that getter...

But why not if that's really a wanted feature.

If someone says current resourcesupply=500 and maxAmount=300, he did not say maxAmount=500, but he said maxAmount=300.
So I'd rather cap the currentAmount by the maxAmount than the other way around, or more simple: keep them independent, maxAmount only stating the maxAmount until the effect becomes inactive.

What about renaming it maxRegenAmount and making them independent. I will need maxAmount to make the random thing @Nescio is taking about.

On that topic, can we do random in JS, or is it OOS material ?

Okay here is how it should work.

By default maxAmount = templateAmount
If maxAmount > templateAmount, entity starts with amount then, regens(or not to the max amount if the changes permit it)
This would allow for unit with a 0 regen rate to be only boosted when near a corral, and not grow anywhere else.

Reason for maxAmount presence in the root. The goal is then to use it as the max bound when I will make the random patch
Entity will then start with amount between amount and max amount, and then either grow or nothing. I didn't want to include in this patch because it's big enough like this
and I don't know how we do safe random in javascript.

The template should then specify the starting resources amount as either:
<StartAmount>
or
<StartAmountMin>, <StartAmountMax>.

The starting amount interval could be considered independent from the decay/growth effect thresholds as mentioned.
Unless one adds a design decision that they only make sense if they are equal.

I think sheep starting with random health is a bit weird and I'm not convinced that we want it for vanilla (which is why it's good to split it from the rest that we all can more quickly agree on).
However, if we take this sheep with random starting supply amounts as a real use case, it would provide a realistic use case where the starting interval is different from the timer threshold interval: A sheep would start with a starting resource supply amount between 50 and 75 but can fatten up to 100 for instance.

Also there's the case for min/max symmetry:
It shouldn't be considered godgiven that decay effects may only stop at 0. For example one could consider flora that will never die if left unattended, but it would decay to less productive state when not watered frequently. That could be implemented with a decay timer minAmount of 20 instead of 0 for example.

Regardless of the examples, it's still true that the template are supposed to define the values of the entity component, so it would be contradict the given definition of the entity component if the entity component would chose a different value than the user specified; unless the definition is changed to reflect that (case for KISS).

I did not invent units disappearing where there amount goes to 0 if you want me to do that I can add another value that sets the negative amount which Imho is bad. You could also not clear set amount which would make it only decay if touch by an entity.

If you hate so much that max amount value I can replace it by a threshold that makes the unit not regenerate over or under if decaying. You lose the ability to have them grow which is nice IMHO.

Random was for mines not units.

I thought that would error out without !!

if (this.template.Growth.GrowsWhenAliveOnly) is good enough?

Ah true, I was looking for another way to do it without adding two lines... But everything I tried save this didn't work so :

if (this.template.Growth.GrowsWhenAliveOnly)
    this.growsWhenAliveOnly = true;

Same about the y = +x lines. That stuff is serialized, but do we want that?
We actually might, if that stuff shall be changeable from technologies and auras.
But we shouldn't serialize the variables without an actual conscious decision.
Which means either the serialization is useful because the it applies the valuechange functions that apply aura/tech effects, or the serialization is useless and should be removed.

I was wondering about this, techs didn't make sense, but auras definitively do. I will add applymodifications like it's done in the health.js component.

Not sure about the serialization, but it should certainly be taken into account.

(One can also create a *.txt dump of the simstate and see what is stored visually.)

How would one do that ?

Engine.DumpSimState() in the console would do.

See comment below.

"We all float down here" ~ scary clown

That fixes "A trailing decimal point can be confused with a dot: '1.'." could also remove the .0 if you think that's better.

Right.

let

I don't understand. It's capped so it doesn't break the UI and it's destroyed when it reaches 0. Every code setting the amount should go through set amount. Also we pass the old amount not the new one.

Is it the variable name that's wrong ? Could be renamed to amount for all I care.

Something else is whatever is calling it so IIRC Petra and UnitAI which means that in any case once the number has reached 0 the resource is exhausted.

So:

if (this.regenerateTimer)
{
	Engine.QueryInterface(SYSTEM_ENTITY, IID_Timer).CancelTimer(this.regenerateTimer);
	this.regenerateTimer = null;
}

or undefined (null has a use case if we need to distinguish it from undefined)

The best thing I can do is a map, because I need to keep track of the name of the timers, in order to not add them twice.

Sounds like a use case for Sets.

Not sure you can use sets for objects. Actually I was more thinking of a dictionnary http://pietschsoft.com/post/2015/09/05/JavaScript-Basics-How-to-create-a-Dictionary-with-KeyValue-pairs

The Set object lets you store unique values of any type, whether primitive values or object references.

Actually using a set wouldn't work because I'm checking if object properties exist, not if two objects are equal.

A regular JS object { "key1": value1, ... } works well as a dictionary. Set and Map are nice, but they can also have downsides, because they can't be serialized using JSON (which is not relevant here but in some cases) for example, and array functions don't work for Sets without conversion. Sets only have the advantage that one doesn't have to check if an item is already in the array when wanting to add one I think.

Anyhow, if you're going with hardcoded TimerA TimerB, then you can use this.TimerA, this.TimerB, otherwise an array should work well as a dictionary where the keys are numbers. (Or a Map if there is any real reason to.)

Also the properties can only be set if template.RegenBonuses node exists. A property which is never set (and not set to undefined) won't be serialized.

Except you can't check that a given instance of a time was set without a dictionary. If I had ten times the same timer there will be 10 cells in my array and I won't be able to see the difference. If it's a dictionary though it will be easy.

You can check whether the timer was set regardless whether you use an array, object or Map as the 'dictionary', i.e. timers[i] would always refer to the i'th item in the template.

If you use the current aproach (anyName), then identifying by the custom name would be easier than to identify by the numeric index, i.e. a regular JS object this.timers = {} (that is not set when there are no items) seems the easiest solution.

I'd advise to use a container that is an item of this, rather than using this as the container, so that it is impossible to have name collisions (for example if the prototype has an AddTimer function and the template uses the Add name, then this[key + "Timer"] overwrites/returns the function instead of the timer.

See comment below

See the name of this ticket. The idea is that when gathering the object stops decaying.

Doesn't seem realistic to me, food is rotting even faster if one smears ones hands bacteria on it, and the lost resources for gatherers seems not measurable but not significant enough to justify doing such unrealistic things?

Otherwise if this feature proposal is the right choice, one can also consider starting a timer until the decay should start.

That's fair.

Yes it refers to the entity.

It does refer to the entity

I think unit refers to the gatherer in this particular case.

No, because it could be possible that all timers were stopped and deleted.

Ah damnit that's a bad copy paste, the above should be growth timer, and the below decaytimer.

Well since I added the interval modification it's not always true now.

No more duplication.

For some reason, it doesn't work if I do anything else, just returns false.

AFAIK I can only pass one object.

Well don't get fat when you run do you ? :)
UnitAI set this to variants. But it could only check for !== "death".

if (
=== only when the type distinction actually matters

Noted

For some reason that return false :(

this.template.Growth.GrowsWhenAliveOnly will be falsy always since it's an empty element.

!== undefined

I'm spending do much time in visual Studio I sometimes forget not everything is automatic

Fair enough.

If you have a better way, let me know. CmpHealth returns the amount of resources instead of the life.

cmpResourceSupply: am I a joke to you?

On a more serious note, that is probably as bad as it sounds.

Attempt at a more productive comment.
I guess the real problem here is the fact that the entity is dead and destroyed when this comes into play.

Sucks to mix tabs and spaces, but okay.
I'm not a fan of adding a ternary there.