Feature Request: Improve interaction between recurring credits and temporary credits

[Quarg]

There has been a longstanding issue where if the runner has bad-publicity credits, and recurring credits, if the runner attempts to spend their recurring credits, it will use the bad-publicity credits first.

There has been plenty of previous discussion of this issue, but since it's been left undiscussed for so long, I thought it might be appropriate to create a new thread for it; but here are the previous threads I could find, for reference:
#1457
#2056
#2200

I would like to propose a fairly simple solution to this problem:

If recurring credits (or things like Net Mercur / Ghost Runner) are taken during a run, they are added to the same temporary credit pool that is used for Stimhack and Bad Publicity; this way, if spending recurring credits rather than bad-publicity for something, the extra credits are still lost at the end of the run.

The only real downside I can see with this is that it means that taking the recurring credits after spending them can lead to incorrect behaviour.

Adding an additional line of logging, to state the number of unspent credits lost for that run should mean that players should be able to fairly easily fix any issues that do occur, so long as players spot that this has happened.

[nealterrell]

Would it work to put recurring credits into the temporary pile only up to the amount you started the run with? Can we break this?

Suppose I have SMC and Multithreader installed, and 1 BP and 10 real credits, and want to pop SMC into Inti using Multithreader to pay for the search.

• Use SMC (9 credits, 0 temp) -> Multithreader (1 credit goes to temp, the second is real -- 10 credits, 1 temp) -- correct behavior.
• Multithreader (12 credits, 1 temp) -> use SMC (11 credits, 1 temp) -- damn.

If I start the same run with 0 BP:

• Multithreader (12 credits) -> use SMC (10 credits) -- correct.
• Use SMC (8 credits) -> Multithreader (10 credits) -- correct.

It's close... hmm

[Quarg]

Having mulled it over, I think I've found a method that will correctly handle taking recurring credits both before, and after they have been spent; In order to do so, it requires tracking the number of credits spent from the runner's actual credit pool.

If the player has spent at least one credit from their credit pool, then it adds to their actual credit pool and reduces the counter of real credits spent by one, otherwise it adds to the temporary pool.

This way, it cannot increase the number of credits in the runner's credit pool, as if it would add more credits than have been spent, they will be added to the temporary pool.

For Example:

• 5 real, 1 temp, 0 spent
• Spend 2
• 4 real, 0 temp, 1 spent
• Take 2 recurring
• 5 real, 1 temp, 0 spent

The other cases; where the number of credits in the temp pool is greater than the spend, or the credits are taken first work fairly trivially.

[Saintis]

One issue with keeping track of how many real credits you had at the start of the run is that it fails to account for credits gained during the run.

I think best approach is to just always add recurring credits to temporary pool at all times, and let people use the +/- buttons to sort out any confusion. That way you should never end up with more real credits than you should.

[Quarg]

I agree that working it out based on the number of credits you have at the start of the run would fail for these reasons, but if we track the number of real credits spent seperately, then (unless I've made a major mistake), it should work regardless of credit gain etc.

The only real cases I can see this failing to work with is where spending of credits is tracked incorrectly, (eg: manual credit adjustment, either counting as spending, or not spending when it's expected to behave in one way or another.)

I would also like to emphasise that adding logging to specify the number of unspent credits lost at the end of the run would help catch any player errors that might occur with any changes to temporary credits etc.

[NoahTheDuke]

Implemented with #4262