Bad Publicity credits and Stealth credits interact poorly

[anathomical]

The current implementation of Bad Publicity adds credits to your pool at the beginning of a run, and removes any that are left at the end of the run, which is correct. However, it assumes that any credit spent from the pool is a Bad Publicity credit until they have all been spent.

This is an actively bad assumption in a number of semi-common use-cases. One major example is if the runner is using Stealth breakers, and needs to take credits off of a card like Cloak in order to pay for their stealth breakers. The way that this will work in the current implementation is that the recurring credit from Cloak will go into the runner's pool, and when it is spent, the Bad Publicity tracking code assumes that the credit is a Bad Publicity credit, even though it was not.

The end result of this is that the Bad Publicity doesn't actually know how many credits have been spent that were provided by Bad Publicity at the beginning of the run, and is too generous. In the above example, the runner will end up gaining one credit permanently from the Bad Publicity since they gained that credit at the beginning of the run, and then it isn't removed because spending the credit from Cloak "counts" as spending the Bad Publicity credit.

Ultimately, I don't think that automatically dumping Bad Publicity credits into the runner's pool is a workable solution because of the way other sources of credits are handled (in that they add to the runner's pool). Bad Publicity should probably be implemented as a recurring credit source that the runner can click on to add credits to their pool when they use those credits in order to allow the runner fine-grained control over their credit sources.

[JoelCFC25]

I am not 100% sure--@laganojunior can chime in--but this may have been taken care of by #417, which has been merged but not yet deployed.

[nealterrell]

Hmm, good points here. I don't think #417 will address this...

1. Runner has 0 credits and uses Stimhack -> 0 credits, 9 runcredits.
2. Runner clicks Cloak -> 1 credit, 9 runcredits.
3. Runner pumps Refractor -> 1 credit, 8 runcredits.
4. Runner breaks with Refractor -> 1 credit, 7 runcredits.
5. Run ends. Runner has 1 credit.

#417 at least will let you manually adjust the runcredits separately from credits, but doesn't fix the above scenario (as outlined by @anathomical).

The issue is that pay and lose automatically pull from the runcredit pool, but the Refractor credit needed to be the Cloak stealth credit which was dumped into the normal credit pool.

I'm leaning towards @anathomical here; I don't see this being something we can automate.

[justinliew]

This is also related to #362 which is about recurring credits. I'm just starting work on this as I was on vacation for a week, and we discussed this at length in that issue and decided that manual recurring credits is the best way to go.

[laganojunior]

I'm fine with not automating pulling credits from the run credit pool. It just makes everything easier to program, and players can just exchange run credits for credits. So I'll revert the auto-spending of run credits, and try to highlight the temporary run credit resource in the UI to highlight that it's available to exchange?

[anathomical]

I vaguely remember someone once suggesting trying to make the run-indicating arrow into a clickable object that acts like installed credit sources that gets filled with run credits when the run begins. Might be more complicated than it's worth, but just having "run credits" on some sort of interface object where you can click said object to move credits into your real credit pool would bring it in line with other UI that players already have to understand.

[mtgred]

Several people complained about the current implementation of run credit and I have to agree with them. The first implementation was great, now it is super confusing and not clear at all how the manual run credit adjustment works.

It's going to reverted to the initial implementation. To fix the stealth credits issue, a solution would be to add 1 run credit instead of normal credit. Same for cards like Ghost Runner or Net Celebrity.

[anathomical]

Is the idea here that triggering an on-board credit source will add those credits to your normal pool if you aren't in the middle of a run, and to the run credits pool if you are in a run? Because some cards, such as Cyberfeeder, can do either.

While I think that this is a fine solution, I'm just generally not that excited by the run credits interface as it currently exists. I mentioned this before, but I'll bring it up again because I'm especially taken with it, but I'd much prefer that the run indicator arrow just become a credit source seeded with whatever sources are appropriate during a run. Then players can click on the arrow to pull credits from the run pool into their main pool during a run, just like they click on other credit sources to "use" those credits.

There are probably some disadvantages to this approach that I haven't thought of, but it feels much more "unified", for lack of a better word, with the rest of the expected user behaviors than the current implementation.

[laganojunior]

As long as recurring credits work by manually taking credits off as a conscious UI decision, I think that run credits can't be as automated as I initially wrote. I agree that the best idea is to make the run credits similar to recurring credits, e.g. on the game board ideally somewhere obviously connected to the run. The run indicator arrow does seem like the best place to do this.

I can take a stab at trying to make such a credit counter to the arrow.

[justinliew]

@laganojunior - I'm going to start working on the recurring credit stuff this week, so we can hopefully combine forces and the run credits can be taken off the arrow, or some other appropriate UI.

[laganojunior]

What is your plan with recurring credits again?

On Wed, Aug 5, 2015 at 8:42 AM, Justin Liew [email protected]
wrote:

@laganojunior https://github.com/laganojunior - I'm going to start
working on the recurring credit stuff this week, so we can hopefully
combine forces and the run credits can be taken off the arrow, or some
other appropriate UI.

—
Reply to this email directly or view it on GitHub
#454 (comment).

[justinliew]

#362

[anathomical]

Just wanted to pop this back up on people's radars. With the growing use of Multithreader, I'm seeing more and more players with sources of recurring credits, and for the most part they don't realize that the system is giving them "free" credits when they run and use those sources with bad publicity. Trying to explain what's going on so that they can correct their pools is really difficult.

I don't know if this is REALLY super-high-priority, but the edge cases that it impacts are growing more common.

[justinliew]

I'm still working on this. I'll give it a more in depth push so that once D&D is more widely played we can try to have something better in place.

[NoahTheDuke]

Implemented with #4262