Zugbot currently does use Linear Action Resolution, but I intend to implement NAR eventually, so I’ve been designing around trying to make things compatible with automating it
1 Like
Aye. One is active redirection (the one we all know) and the other is passive redirection (e.g., bus driver). To be fair, not many people look into the nitty-gritty details and classifications. I only started paying attention to these stuff after I saw the notes from… IIRC FAM4 (maybe FAM3) and discussed it with Gray.
Well… You either enforce that there is at most one Redirector, whose redirection action then becomes unstoppable, and put that as a step before the resolution phase / step,
or you design another implementation / algorithm to accomodate multiple redirectors. (I am saying this as if it is nothing, but I myself am struggling on imagining how this would look like.)
(By the way, the algorithm you have is basically describing this role.)
1 Like
This would go against the major design goal of accommodating the widest selection of roles possible so not this option
mmmmmmmmm
Perhaps (referring to what I previously called Redirection as Transportation):
- Players can have any number of Transportation effects on them at once (rather than either 0 or 1)
- Transportation effects have an additional field to specify which players they effect (eg I can write a Transportation effect that only effects, say, Ash), or all players
- When player A tries to target player B, use the Transportation effect with the highest strength out of all the ones that apply to the target player
- To resolve ties in strength… not sure. There are a lot of options though (for example, using the most/least recently created effect, using the effect that applies to the fewest players, etc)
This allows implementing Redirectors, since:
“Redirect Player A to Player B” is equivalent to “Create a Transportation effect on every player, directed at Player B, which can only apply to Player A”.
Thoughts?
2 Likes
If you are going to make it NAR… Oof, that will be kinda tough, no? Supposing we only work with basic actions (e.g., invest, kill, protect, etc.) then you have to make some sort of “manipulation step” before the final action resolution step, where Blocks and Redirections are taken to account.
Common problems would be red loops and multiple reds on the same target? (Mutual block negate each other, unless you do some complex Combination modifier, which is a can in worms you shouldn’t open for a basic bot.)
Multiple reds would be solved by assigning the strength stats (which would then have to be unique to prevent same priority).
As for red loops… During this “manipulation step”, you have to make some sort of list for each reds, and detect if the same red is about to be inserted into the list. If such were the case, then the entire red action fails, and the list would be removed. (Now, I wonder if this can be done in parallel, as to prevent a case of “one red fails, but another red succeeds”…)
1 Like
Oh. If you can make it so that a Transportation effect can be applied to one player, then yeah. That would be no different than a Redirection.
As for how to resolve ties: Just ensure that all distributed strength values are unique and spare yourself the headache.
*processing time*
Oh wait. I tried to say this before, but then I removed that message since I don’t know how this would affect red loops.
If R1: R2 → R3,
R2: R3 → R1,
and R3: R1 → R2,
then how would this be resolved?
Do all Reds only redirect the first target?
If so, then what if:
R1: Vig → R2
R2: R1 → R3
R3: R2 → Vig
Essentially, “players may be redirected, but what if redirectors are getting redirected”? I feel like this is not something that can be done in one step.
1 Like
My current (somewhat vague) idea on how to do NAR is:
- Mark sufficiently simple roles as NAR compatible
- This allows me to have certain guarantees about their behavior. For example, one role that would not be NAR compatible is:
This would not be NAR compatible in my planned algorithm because it means that killing roles manipulate the action of this role, and I need the guarantee that manipulative roles are the only ones actually doing manipulation.
I’m not sure exactly what all the guarantees I need to have about well-behaved roles are yet.
By the way, this is why I might end up splitting action types further - doing so would give Zugbot more information when attempting to do NAR.
- Resolve actions with NAR by creating a directed graph of all the actions and their effects, in a way that makes it so that, if the graph has no cycles, I can resolve actions with it using topological sort. If that doesn’t make sense, basically it’s supposed to be a programmatic way to implement “Resolve actions that effect other actions before the actions they effect.”
- If there IS a cycle in the NAR graph… not sure what I want to do about that. Maybe revert to a linear priority?
2 Likes
3 Likes
holy shit. the polymarket odds for “first foler to call self a malewife in cookie thread during 2026” just completely skyrocketed for litten. it was at 79% chomps, and 18% arctic. Litten barely had any movement before this post. It’s being reviewed currently but it looks like he just won it
8 Likes
kalshi was dialed in had him at 21%
1 Like
If the actions are resolved in this order, and all focuses are low enough to be vulnerable to all redirects:
- R1 forces R2 to target R3.
- R2 has both of their targets set to R3, and therefore forces R3 to self-target.
- R3 has both of their targets set to R3, and puts an additional (redundant if of equal or lower strength to the effect set by R2) forcing of R3 to self-target.
If I tried to use NAR, I would obtain a cycle (since R1’s action effects R2’s action which effects R3’s action which effects R1’s action) and have to resort to something like linear priorities.
1 Like
Ah… I realize the problem. I cannot know who the redirectors will manipulate ahead of time, because they may themselves be manipulated by other redirectors. This likely breaks the planned method of NAR by working out who is manipulating who before resolving any actions. That is… awkward.
1 Like
See, my issue with graphs is: When it comes to Redirections in particular, they have two outgoing arrows, which is where the root of the confusion starts.
–also, I don’t know exactly how this NAR graph works, but I can only hope that “Vig shoots Doctor while Doctor heals Vig” won’t be seen as a “cycle”.
. . .
*re-reads*
- “For every “red”, all players gain T-effect.”
- “Each effect can apply to different or same players.”
- “Each effect can direct to the same target.”
[1] is the implementation, which is okay. (It is one way of turning Transportation to Redirection, alright.) [3] is fine. [2] is where the issue lies.
The template is…
“T-effect (x) from R1: A → B, STR n”
As said before, the strength stat resolves multiple reds attempting to red the same target.
The issue lies in the possibility of making loops.
1 Like
insane missed arbitrage opportunity
This, at least, should be avoided, since Vig and Doctor are not manipulative roles.
…Notably, I’m pretty sure there are possible implementations of Vig, Doctor, and many types of investigative (including watchers/trackers) that can handle all of these roles together without any regard for priority. Any resolution order should give the same result.
As for the issue of redirection loops… I do not have a solution, nor do I expect to come up with one soon. In practice if I want NAR I will likely have to settle for setups with restrictions (such as making all redirectors/transporters have high enough focus so that they can never be redirected themselves).
1 Like
Out of topic, FWIW since the final resolution is one where the Reds do not affect any other players: If I were the host, then I would either block them all or have them all visit each other.
Hence the need for a “phase before the final resolution phase”. Because a game with multiple Reds needs to have their actions be sorted out if you’re going with NAR.
During the final resolution phase themselves, since the Reds can’t do anything anymore (besides visiting, I guess), they are effectively Vanilla (or Visitor with maybe multi-target).
. . .
WCS(1): perform manual work for this “prep phase” and then let the bot do its thing. (Downside: No actual automation at night. You might as well host manually.)
WCS(2): give up on NAR implementation.
BCS: brainstorm for a better solution. (Issue: I don’t have any more tricks up my sleeve.)
1 Like
“All Reds are red-immune.”
Hang on. Why does this sound familiar?
CRich talked about this once…
–is that what happens in Throne of Lies?
2 Likes
This is what I will likely attempt… whether I will find one is unclear. Regardless, I am grateful for the discussion, even if I fail to find an NAR system. At minimum, this has shown me that I’m missing Redirectors and how to fix that, and it’s probably also saved me time before I realized the shortcomings of my planned method of dealing with redirectors acting on eachother.
Anyway, good night! It is… past 2 AM for me now…
1 Like
Mine is like a light jacket over a random T-shirt and sweatpants.
Mine is now cargo pants and button-up shirt/sweater
1 Like
