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?
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.
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).
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.
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.
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?
Thanks
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.
Iâm new to this thread (and itâs old, wow!) but I did want to share my philosophy:
My current workforce of 700 Pioneers consumes some decimalized commodities (COF, OVE, PWO), and I would suggest that the concept of âsatisfactionâ be altered from âX% satisfiedâ to a flat âYes / Noâ binary system where the amount of consumed material (with an attempt to be rounded up to the next whole unit) refreshes the cooldown timer for that specific good. You can have POPR consumption run a quick calculation on âHow much do I consume to get to 100% of 24 hours?â and then apply the same rounding principle to âoverfundâ the countdown.
Adding workforce to the pool would recalculate the timer and items would only be consumed when they reach 0, or POPR hits.
