Consumable Mechanics: Feedback on Ticks, Modelling, and Transparency

Based on the recent discussions:

Sharlindra: So say we consume 0.7 OVE/day:
theory a) (which I thought you had confirmed in the past, but I might misremember and there are people adamant that this is wrong) you consume 1 OVE every 34 hours
theory b) consumption is always 24 hours apart, once day you consume 1 OVE, another day 0 and it cycles so it adds up to 0.7 in the long [term], keeping track of invisible fractions in buffer or something

Molp: If I remember correctly, after all this is 4+ years old code written by martin, it works like you described in theory a)

Hevlikn: The reason [FIO users] question this, is due to gathering data that would suggest the 24h consumption ticks; this is more obvious in high-consumption mats, (eg. DW/RAT), where a discrete amount is consumed regularly, with the excess stacking up until it satisfies the fraction.

A further related, question, is whether or not consumption ‘ticks,’ are per-material, per-workforce, per-building or base-wide; perhaps the reason we think it is 24h is that the consumption is some Lowest-common multiple that happens to align daily close enough to daily to be confusing.

Additionally, your model doesn’t match expected behaviour; if indeed it is time-adjusted based on consumption, to satisfy whole units, you would expect high-volume consumables (eg. DW/RAT) to consume at sub-day intervals, ( 1 every 2 hours for a 12/day rate). This is quite obviously not the case, so is there a minimum time period? How does that work with improper fractions ( 11+(7/10) /day for example)?

Molp: There is is a minimum interval of 24 hours and consumption is calculated for each consumable separately

We have a ticket in the backlog for ages now where we want to improve the consumption of consumables and make it more transparent.

I know it is a pain to only being roughly able to estimate how much consumables are needed, especially for new players that don’t have the cash to buy larger stockpiles.

So, let’s discuss:

Is there a better way to communicate this to new users?

Is it preferable to have regular consumption or regular times?

NB: not a discussion on game balance.

My thoughts are that either are suitable, however the next consumption tick should be reflected in the UI, regardless of the decision.

There are two competing interests in my mind: the first is Data, and the second is that kinda minimalist aesthetic APEX has.

For example, if we were to add a new column in the “Workforces” Buffer, showing %consumption to the next tick, this could solve a lot of the confusion, without affecting the underlying mechanics.

1 Like

I agree that we should make it more obvious, but we haven’t found a simple solution yet.

The reason for that is that ticks can occur at any time! There is the regular tick that could be displayed, but consumption events also happen when:

  • a new habitation is built or one is removed
  • the workforce has been undersupplied and new consumables arrive
  • when the workforce redistribution happens during the population report
  • and possible one I did forget right now

When we show the countdown to the next consumption event then players will get confused if one of the events above interfere with the countdown :confused:

1 Like

I agree, there needs to be a better (in-game) way to determine when the next consumption tick occurs.
@Hevlikn has a great suggestion, which I think blends well into the current aesthetic.

@molp I would argue that having a countdown timer would actually reduce confusion regarding the other consumption events. It makes it clearer when a new batch has been consumed, rather than relying on the players memory of their previous inventory (plus the timer helps them to work out what triggered it).

1 Like

Imagine this scenario:

  • “Countdown timer says next consumption in 10 hours”
  • build a new Production building, consumables are consumed.

I already see people confused about this. “Why did it consume when the timer said the next time is in 10 hours!?”

I guess this is what molp is referring to?

1 Like

Yep, I agree that it is a point of confusion, but at least it would be noticed. In my view, this is actually a benefit.

It’s better than the player suddenly feeling that their consumable quantities seem different, and wondering whether they actually have changed (I know that paranoia too well). With a count-down timer, they can pinpoint the exact time of change, and hopefully find the correlation.

Aside: Is the 4th type to do with efficiency factors, such as building degradation expert application/removal and CoGC perhaps, as this causes a rate-change?

These are all fair points, but a list of “forced consumption events” would greatly improve transparency to the end user, provide an intuitive parallel to the handbook, and avoid significantly reworking of the underlying code, which there may be more/less appetite for, given it’s 4 years old. :wink:

Much of the current confusion, I would presume, is that there is no feedback to the user in-game as to when consumption is taken; providing the timer to next tick, would at least give the user the impetus to ask “Why did the tick reset early?” to which a definite answer can be given.

The other potential solution here may require a significant rework - implementing the ‘buffer’ system that some think exists (or, showing it, if it does!). The buffer would have capacity for ceiling(dailyRate) consumables. The progress bar would then show when the next unit would be consumed from the buffer, and the buffer would be refilled on one of these defined events, or every 24h; this could be done without resetting the ‘next consumption’ progress, only the rate.

For example, take my mock-up from above, and say, add another 200 pioneers; the 1 unit of PWO is partly consumed already, so the remainder would be consumed at the faster rate; while all the other progress bars would also follow this logic, being per-unit, not per-batch.

Hi @molp, I’ve come across an interesting behaviour that appears to contradict the handbook, and/or may be unintended behaviour.

The situation was as follows:
All DW and RAT were removed from base inventory
Consumption tick occurred, dropping consumable satisfaction down to (DW: 3.06505%, RAT: 2.37302%).
2u DW was added, which raised the consumable satisfaction to (DW: 17.3795%, RAT: 2.35573%).

As expected, DW satisfaction rose by 14.31445% (the base consumes 13.95u DW/day, which translates to 14.33692%, and the 0.022% difference would be due to the time from last consumption).
However the interesting part is that the RAT satisfaction also dropped by 0.01729%, which should not have occurred - as all consumables are supposed to be on individual timers. For some reason, adding DW seems to have caused the RAT tick to also be triggered.

Is the RAT supposed to also tick at this point, or is that unintended? The handbook strongly implies that it should not, as does your recent comment:

I would appreciate any clarification on this please. Thanks!

1 Like

I have now seen the same behaviour in another situation (EXO reducing when adding PT). I would guess that it may apply to all sets of consumables.

Another weird one, is that I have had a report of what seems to be a consumable tick being triggered by selling RAT on the LM, where 25 went missing after provisioning 24 (as well slight as drops in each of the other PIO consumables) - but this is hard to tell for certain, as we don’t know if/how the tick timer has updated.

With the way it seems now, it should be essentially impossible for consumables to be pulled at different times (with the exception of perhaps those shared across pop types?), yet clear examples are given in the handbook that they should - and so I am fairly sure that this is unintended behaviour.

Could we please have some clarification on how each consumable interacts, as official sources are contradictory?

One way to do it is to just multiple RAT, OVE and DW by 10, so that the FP makes 100 RAT at a time. By changing the base we can get a finer and more predictable degree of consumption.

Alternatively, if there is a separate storage space that we can move consumables to that ‘locks in’ their consumption (i.e. once placed inside it cannot be removed) then the game can calculate how much time I have left until the consumables are exhausted. If I consume 2.5 RAT a day, then when I put in 10 RAT into this ‘consumables tank’ it should tell me I have 4 days of consumption left.

That way, it’s intuitive whenever you build something and change the rate, it will just update the amount of time you have left which is expected since you changed the rate of consumption.