add favours system for outrepped runs

[scoutyoshimoto]

from issue #799:

• add a toggle to enable this
• turning on the toggle allows you to ask johnsons about doing them a favor (or favour)
• favours are just their regular runs, but the reputation check is bypassed
• you can still do regular jobs (even from the same jonhson) the normal ways
• there's no convenience commands for favours like jobs, only say favor/favour/favors/favours will trigger it, there could be, but I left that out on purpose initially and forget to do anything about it later when I couldn't remember why
• favours are cached differently to regular jobs, as they generate a different pool of jobs and the johnsons get confused if both pool share the same cached job
• you only get item rewards as written, there is a setting to dial in the % of the normal nuyen/karma rewards which is currently set at 0
• there's a little bit of informative stuff to indicate you can do it if you have the toggle on, but only if you've outrepped every run a johnson has (wasn't sure of an efficient way to check if you have only outrepped eg 2/5 or something)

aka high rep characters can do runs they are hopelessly outclassed for, but pretty much only to experience (or re-experience) the content, story etc, as there's no real material reward

[luciensadi]

What's the interplay between the "favor" keyword and the PRF flag? I'm trying to think of what the behavior should be if someone says they want to do a favor but doesn't have the PRF set, and I'm having a hard time coming up with it.

If there's a special 'favor' keyword, do we need a PRF flag at all, or should we just tweak the J room-display logic to show the favors line if you've outrepped all their jobs?

[scoutyoshimoto]

tbh, the toggle probably only there at this point because someone suggested it in the issue?

the PRF flag... it mostly comes into play when doing the cached_new_q/cached_new_f check when you say "yes" or "no" that's independent of whether you said "job" or "favour" before, cause I got a fair amount of "what the hell are you talking about"s from broken johnsons trying to give me cached quests in a weird state before I got it working

but it seems to work the same if this bool is false by default, and set to true if you say "favours" though, so that would probably mean the toggle is vestigial (in an earlier version it was more important, but I think I took out enough of where it was being used that it might not actually be necessary any more) it seems like the johnsons need something that persists to decide which cache to use or they break, so I'll say the interplay is "making the cache work"?

the other logic in my head was just to not show it to newbies, but that could be a reputation/TKE check as well, or maybe not even something that needs to be a thing

[luciensadi]

If Js need a persistent thing on the PC to track that, I'd probably set it as a PLR or AFF flag that doesn't show up for the player, then clear that when they do anything else with the J (accept/decline/etc). A separate toggle feels like the kind of thing that will trip people up in practice.

[scoutyoshimoto]

i thought about it and i came up with some other possible ways to track it, I'll try that and those later on this evening though and see how it goes (and add like, help files etc :)

[scoutyoshimoto]

ty for pointing that option out, feels like it works a fair bit better :)

[scoutyoshimoto]

i had another look at the conversation that started the idea and realised it should probably track the two job histories entirely separately, so tried that out too :)

the main additions here would be:

• it uses a PLR flag instead of the toggle
• it shouldn't say anything about favours in the information line until you're out of newbie status
• the logs are a little easier to distinguish instead of having to infer from the 0/0 rewards
• adds a favours table to the db to make the favours history totally separate from the job history
• short circuits if you try to start a run you haven't outrepped as a favour

getting there!