|
On September 16 2013 15:33 GreYMisT wrote:Show nested quote +On September 16 2013 14:38 gonzaw wrote:On September 16 2013 12:34 GreYMisT wrote:
The Banlist was talking about it, so here is my typical night action resolution chart taken from parallel worlds mafia
Night Action resolution
Night actions will typically resolve in the following manner.
1. Anything with “ First Priority” specifiers
2. Roleblocks (2 roleblockers actioning on each other will both be roleblocked and notified)
3. Any Redirection abilities
4. Everything else
5. Anything with "Last Priority" specifiers It's not so easy. Some redirection actions affect other redirection actions, which in turn affect other stuff, etc. I think the best way to envision it would be creating a "graph" of dependent actions. I.e every night action is a node in the graph. If that action modifies another action in any way, you link that action to the other one. So if (1)="Player A RBs Player B" and (2)="Player B Checks Player A", then the dependency graph would be (1)->(2). This means you first execute (1), and THEN execute (2). Basically you follow the graph. But shit like bus drivers and redirection make this shit hard, because it changes the graph as you execute it. For instance, if (1)="Player A busses Player B and Player C", and (2)="Player D RBs Player B" and (3)="Player C Checks Player A", then at first, you construct the graph like this: (1)->(2) ; (3) (3 is independent) So you execute (1), but oh! It turns out that now B and C are bussed, so D actually RBs C. This means the graph changes to (2)->(3), since Player D is RBing Player C. This means C never gets his check. However if you had followed the initial graph C would have gotten his check. You can say "But by making all RBs happen first, this doesn't happen!". Well I think this shouldn't be the case. Why? Because the above case is legit. If I buss 2 players and a 3rd player RBs one of them, he should instead RB the one that was bussed. This is the core of redirection, and it shouldn't apply to every other action, yet stop with roleblocks just because. One way to mitigate this is to "simulate" graph executions. You first take all dependencies, then "simulate" executing the 1st one in the chain (if the chain is (1)->(2), you simulate (1) first). After this, you see if any dependencies changed. With lots of actions with lots of dependencies which change lots of stuff this may pose a problem. There's also the problem that the chains must be acyclic. So if you encounter a cycle (for instance 2 players RBing each other) you do have to break the cycle. However it goes beyond that. You can have ANY cycle. What if Player A RBs Player B, Player B RBs Player C, and Player C RBs Player A? This is different than the "2 RBs RB each other" case, yet it is another cyclic problem. You can say "Just RB all 3", but there can be other cycles that not only have to do with RBers. For instance bus drivers bussing each other, and of course other "insane" mechanics with mind controllers and stuff. But again just making one role have priority over "everything else in the universe" defeats the purpose of some of these roles, and makes certain scenarios (which would have been possible and valid previously) invalid (like the bus->RB one I mentioned first). Meh. Surely we could convince some mathematician and/or computer scientist to give us a nice perfect computing model for this shit. Trust me, I have experience with resolving consistantly busdrivers affecting busdrivers who also affect 2 people listswaping other people in a parallel universe.
Can vouch for this. When you make ludicrous setups frequently, you tend to be able to resolve things pretty well. Think about the Shadowsinger role - GreY and I have a lot of extremely complicated interactions to think though. For example, if the Shadowsinger sings Lord Kanti, and Kanti targets God, does God die the following night? What if God tries to suicide, is he protected because Kanti's delayed kill was sung? In a different scenario, if the Inventor gets sung for whatever reason, what the hell happens there?
I suppose that these are not the most on-topic examples as they are more role-related than priority related. But we have had, in game, a future bus to a dead player you was redirecting shit from himself (I think I'm remembering that correctly). This may sound a bit conceited, but until you've cohosted in one of those games, and even maybe after, its hard to get the instinctive nature behind priority resolution. I do believe that is is instinctive because GreY and I almost never disagree on how things should play out - 99% of our disagreement comes in the setup phase, where (for example) I want to kill everyone and GreY just wants them confused but alive  .
Now, it helps that we rarely run setups with multiple copies of powers. But lets take the two bus drivers issue, and let me show you how I solve it. Graphically!
![[image loading]](http://i.imgur.com/j0VpZR9l.png)
The method is simple. Odd numbers swap, evens cancel out! Observe.
In 1, A is swapping BC, and B is swapping CD. C is being swapped two times (an even number). It does not move, and the resulting swap is BD.
In 2, A is swapping BC again, but this time B is swapping AC. C again has two swaps, and the resulting swap is AB.
In 3, D has decided to join the party as another busdriver! The swaps are AC, BC, and BC. B is swapped twice,
C is swapped three times. Since three is odd, the result is AC.
In 4, D has decided to be sneaky an swap himself! AD, AC, BC. 2 As, 2 Cs give us the result BD.
"Aha, iGrok!", you exclaim, "I have broken your logic, using example 5! Observe, by adding a fourth busdriver, I have made 4 odd swapcounts! How will you solve this now?!" Well, the answer is quite simple once you list the swaps. You have managed to copy the AC swap. Obviously, when two people are swapped twice, the swaps cancel out. Therefore, you are left with two unhindered swaps - AD and BC.
Furthermore, if you are planning a game with 4 or more busdrivers, you are probably me.
|
Somebody still following the champion game?
I am not really reading the game but town lynched a townie after 3 succesful scum lynches. Or maybe 2 scumlynches and then a night vigi scum shot. I forgot.
Kinda insane how the scummers are still hiding it seems. Unless the scummers just showed face saving a scummer in that last lynch.
|
On September 16 2013 19:08 Koshi wrote:
Somebody still following the champion game?
I am not really reading the game but town lynched a townie after 3 succesful scum lynches. Or maybe 2 scumlynches and then a night vigi scum shot. I forgot.
Kinda insane how the scummers are still hiding it seems. Unless the scummers just showed face saving a scummer in that last lynch.
I stopped following it but since this is a public forum I wouldn't talk about it much, until it's finished.
I'm kind of a dick.
|
I broke your brains didn't I
|
On September 16 2013 21:12 iGrok wrote:
I broke your brains didn't I
I did it algebraically but I like the pictures.
The Bus driving operator appears, from examples, to be commutative and hence unambiguous in its nested effects.
Where BD { } is an operator that rewrites the actions inside { }
DC { BC{ } } = BD{ }
BC { DC{ } } = DB{ } = BD{ }
AC { BC {BC{ } } } = BA {BC { } } = AC { }
BC { AC {BC{ } } } = AB {BC { } } = AC { }
BC { BC {AC{ } } } = 0 {AC { } } = AC { }
0 is the no bus drive identity operation that as a special case results from a pair of sequentially nested identical busdrives BC { BC{} }
There is probably a bunch of proofs and theorems..
I am strangely reminded of special card from the Illuminati card game "Secrets man was not meant to know", also reminded of that when I think of software that should not be written. Not everything that can be done is good idea. For me that is running games with N busdriver madness, so yes if you are resolving an N busdriver game then you are probably Igrok and thus the problem of what happens is reduced to the previously solved problem "What happend?" => "Igrok knows what happened and posts it in the day post".
|
But what if someone in an iGrok game busses iGrok with LSB while the other N Busses buss each other and/or themselves?
|
On September 16 2013 23:54 phagga wrote:
But what if someone in an iGrok game busses iGrok with LSB while the other N Busses buss each other and/or themselves?
How did you think GreYMisT was born?
|
So what happens if the first busdriver gets a flat tire?
|
On September 16 2013 18:50 iGrok wrote:Show nested quote +On September 16 2013 15:33 GreYMisT wrote:On September 16 2013 14:38 gonzaw wrote:On September 16 2013 12:34 GreYMisT wrote:
The Banlist was talking about it, so here is my typical night action resolution chart taken from parallel worlds mafia
Night Action resolution
Night actions will typically resolve in the following manner.
1. Anything with “ First Priority” specifiers
2. Roleblocks (2 roleblockers actioning on each other will both be roleblocked and notified)
3. Any Redirection abilities
4. Everything else
5. Anything with "Last Priority" specifiers It's not so easy. Some redirection actions affect other redirection actions, which in turn affect other stuff, etc. I think the best way to envision it would be creating a "graph" of dependent actions. I.e every night action is a node in the graph. If that action modifies another action in any way, you link that action to the other one. So if (1)="Player A RBs Player B" and (2)="Player B Checks Player A", then the dependency graph would be (1)->(2). This means you first execute (1), and THEN execute (2). Basically you follow the graph. But shit like bus drivers and redirection make this shit hard, because it changes the graph as you execute it. For instance, if (1)="Player A busses Player B and Player C", and (2)="Player D RBs Player B" and (3)="Player C Checks Player A", then at first, you construct the graph like this: (1)->(2) ; (3) (3 is independent) So you execute (1), but oh! It turns out that now B and C are bussed, so D actually RBs C. This means the graph changes to (2)->(3), since Player D is RBing Player C. This means C never gets his check. However if you had followed the initial graph C would have gotten his check. You can say "But by making all RBs happen first, this doesn't happen!". Well I think this shouldn't be the case. Why? Because the above case is legit. If I buss 2 players and a 3rd player RBs one of them, he should instead RB the one that was bussed. This is the core of redirection, and it shouldn't apply to every other action, yet stop with roleblocks just because. One way to mitigate this is to "simulate" graph executions. You first take all dependencies, then "simulate" executing the 1st one in the chain (if the chain is (1)->(2), you simulate (1) first). After this, you see if any dependencies changed. With lots of actions with lots of dependencies which change lots of stuff this may pose a problem. There's also the problem that the chains must be acyclic. So if you encounter a cycle (for instance 2 players RBing each other) you do have to break the cycle. However it goes beyond that. You can have ANY cycle. What if Player A RBs Player B, Player B RBs Player C, and Player C RBs Player A? This is different than the "2 RBs RB each other" case, yet it is another cyclic problem. You can say "Just RB all 3", but there can be other cycles that not only have to do with RBers. For instance bus drivers bussing each other, and of course other "insane" mechanics with mind controllers and stuff. But again just making one role have priority over "everything else in the universe" defeats the purpose of some of these roles, and makes certain scenarios (which would have been possible and valid previously) invalid (like the bus->RB one I mentioned first). Meh. Surely we could convince some mathematician and/or computer scientist to give us a nice perfect computing model for this shit. Trust me, I have experience with resolving consistantly busdrivers affecting busdrivers who also affect 2 people listswaping other people in a parallel universe. Can vouch for this. When you make ludicrous setups frequently, you tend to be able to resolve things pretty well. Think about the Shadowsinger role - GreY and I have a lot of extremely complicated interactions to think though. For example, if the Shadowsinger sings Lord Kanti, and Kanti targets God, does God die the following night? What if God tries to suicide, is he protected because Kanti's delayed kill was sung? In a different scenario, if the Inventor gets sung for whatever reason, what the hell happens there? I suppose that these are not the most on-topic examples as they are more role-related than priority related. But we have had, in game, a future bus to a dead player you was redirecting shit from himself (I think I'm remembering that correctly). This may sound a bit conceited, but until you've cohosted in one of those games, and even maybe after, its hard to get the instinctive nature behind priority resolution. I do believe that is is instinctive because GreY and I almost never disagree on how things should play out - 99% of our disagreement comes in the setup phase, where (for example) I want to kill everyone and GreY just wants them confused but alive .
Now, it helps that we rarely run setups with multiple copies of powers. But lets take the two bus drivers issue, and let me show you how I solve it. Graphically! The method is simple. Odd numbers swap, evens cancel out! Observe. In 1, A is swapping BC, and B is swapping CD. C is being swapped two times (an even number). It does not move, and the resulting swap is BD. In 2, A is swapping BC again, but this time B is swapping AC. C again has two swaps, and the resulting swap is AB. In 3, D has decided to join the party as another busdriver! The swaps are AC, BC, and BC. B is swapped twice, C is swapped three times. Since three is odd, the result is AC. In 4, D has decided to be sneaky an swap himself! AD, AC, BC. 2 As, 2 Cs give us the result BD. "Aha, iGrok!", you exclaim, "I have broken your logic, using example 5! Observe, by adding a fourth busdriver, I have made 4 odd swapcounts! How will you solve this now?!" Well, the answer is quite simple once you list the swaps. You have managed to copy the AC swap. Obviously, when two people are swapped twice, the swaps cancel out. Therefore, you are left with two unhindered swaps - AD and BC. Furthermore, if you are planning a game with 4 or more busdrivers, you are probably me.
So bus driving is just "swapping"?
I thought it was just busdriving. I.e opening a channel between people that target both players (i.e "bussing" each player that targets one of them to the other player's house). If you open a bussing channel it is still open if someone opens the same one.
So someone bussing A and C, and someone ELSE bussing A and C, means A and C are still bussed, not that the bus cancels out. At least that's how I think about it.
There is also another way to think of bus drives: If you bus A with B, then every time someone does something on A, it will happen on B, and viceversa. Nothing more, nothing less.
So, if someone does X on A, it will be done on B. If someone does X on B, it will be done on A. How's this any different?
Well, if you have someone bus AC, then CB, if someone does X on C, it will instead be done on BOTH A and B. Because bus AC implies that anything that happens to C instead happens to A, and bus CB implies that anything that happens to C happens to B. So if anything happens to C, it happens to both A and B.
But if something happens to A, it only happens to C, not B. IN this case the bus is not a "channel", but just what the definition states: an action done one someone is instead done on someone else.
This 2nd definition is the easiest to manage. Stacked busses only means that, stacked "something happens to someone else" stuff. You can always logically determine what happens to someone by doing this:
-I target player X
-I look at all busses that night between X and some other player Y. I don't take into account repeated ones.
-For every XY bus, I instead use my action on Y
Granted, this duplicates actions, so if you have 1 vig shot target A, and busses AB, AC, AD and AE, then B C D and E will all die, even when you only had 1 bullet.
That image thing you posted works, yes; but for what I know it only works between busses. What happens if you enter a RBer into the mix? What if you enter other more complex redirection roles into it? Does it hold?
Also, entertain this example and tell me what happens iGrok:
There are 4 players, A, B, C and D.
Busses are AB, AC, AD
What happens? There are 4 odd "endpoints", yet no repeated busses.
|
On September 16 2013 18:49 Clarity_nl wrote:Show nested quote +On September 16 2013 14:38 gonzaw wrote:
Meh. Surely we could convince some mathematician and/or computer scientist to give us a nice perfect computing model for this shit. Votecount bot first. Priorities.
There's already one of those I think. That "ZBot" thing.
The thing is that unless you can model this shit you will never be able to have a "bot" that can do it for you for example. You will ALWAYS have to do it by hand.
Even without that, a model allows you to know the strict rules, so every host and co-hosts knows exactly how to proceed when resolving night actions and you don't get a mess.
It basically makes life easier for everyone.
I was thinking there could be a model like that, where each new "role" just defines the possible actions, which should abide to a specific set of rules (for instance they should be able to determine those dependency rules I talked about).
If you do that, you could theoretically add any new role you want (God, Mind Reader, etc), and as long as it follows those rules, you are guaranteed that you can resolve any action that role uses, or that is used on that role, and it will resolve correctly.
But yeah....in a perfect world....
...wait, maybe that can be my uni thesis!
Also yeah the whole "bot" thing I was talking about earlier (like in January or something) is on hold. It's too "big" to start willy nilly like I was planning to. Plus I'm busy with uni and work don't have a single free time left (notice how I haven't joined a mafia game in like 3 months).
I was thinking about maybe doing it open source. Instead of a super-awesome server with everything, it could be an OS installation that installs the server for your specific forum. But leading an open source project is too much work as well so meh. Next year we'll see.
Meanwhile you have walking-super-computers Greymist and iGrok here so you have nothing to worry about.
|
On September 17 2013 02:55 gonzaw wrote:Show nested quote +On September 16 2013 18:50 iGrok wrote:On September 16 2013 15:33 GreYMisT wrote:On September 16 2013 14:38 gonzaw wrote:On September 16 2013 12:34 GreYMisT wrote:
The Banlist was talking about it, so here is my typical night action resolution chart taken from parallel worlds mafia
Night Action resolution
Night actions will typically resolve in the following manner.
1. Anything with “ First Priority” specifiers
2. Roleblocks (2 roleblockers actioning on each other will both be roleblocked and notified)
3. Any Redirection abilities
4. Everything else
5. Anything with "Last Priority" specifiers It's not so easy. Some redirection actions affect other redirection actions, which in turn affect other stuff, etc. I think the best way to envision it would be creating a "graph" of dependent actions. I.e every night action is a node in the graph. If that action modifies another action in any way, you link that action to the other one. So if (1)="Player A RBs Player B" and (2)="Player B Checks Player A", then the dependency graph would be (1)->(2). This means you first execute (1), and THEN execute (2). Basically you follow the graph. But shit like bus drivers and redirection make this shit hard, because it changes the graph as you execute it. For instance, if (1)="Player A busses Player B and Player C", and (2)="Player D RBs Player B" and (3)="Player C Checks Player A", then at first, you construct the graph like this: (1)->(2) ; (3) (3 is independent) So you execute (1), but oh! It turns out that now B and C are bussed, so D actually RBs C. This means the graph changes to (2)->(3), since Player D is RBing Player C. This means C never gets his check. However if you had followed the initial graph C would have gotten his check. You can say "But by making all RBs happen first, this doesn't happen!". Well I think this shouldn't be the case. Why? Because the above case is legit. If I buss 2 players and a 3rd player RBs one of them, he should instead RB the one that was bussed. This is the core of redirection, and it shouldn't apply to every other action, yet stop with roleblocks just because. One way to mitigate this is to "simulate" graph executions. You first take all dependencies, then "simulate" executing the 1st one in the chain (if the chain is (1)->(2), you simulate (1) first). After this, you see if any dependencies changed. With lots of actions with lots of dependencies which change lots of stuff this may pose a problem. There's also the problem that the chains must be acyclic. So if you encounter a cycle (for instance 2 players RBing each other) you do have to break the cycle. However it goes beyond that. You can have ANY cycle. What if Player A RBs Player B, Player B RBs Player C, and Player C RBs Player A? This is different than the "2 RBs RB each other" case, yet it is another cyclic problem. You can say "Just RB all 3", but there can be other cycles that not only have to do with RBers. For instance bus drivers bussing each other, and of course other "insane" mechanics with mind controllers and stuff. But again just making one role have priority over "everything else in the universe" defeats the purpose of some of these roles, and makes certain scenarios (which would have been possible and valid previously) invalid (like the bus->RB one I mentioned first). Meh. Surely we could convince some mathematician and/or computer scientist to give us a nice perfect computing model for this shit. Trust me, I have experience with resolving consistantly busdrivers affecting busdrivers who also affect 2 people listswaping other people in a parallel universe. Can vouch for this. When you make ludicrous setups frequently, you tend to be able to resolve things pretty well. Think about the Shadowsinger role - GreY and I have a lot of extremely complicated interactions to think though. For example, if the Shadowsinger sings Lord Kanti, and Kanti targets God, does God die the following night? What if God tries to suicide, is he protected because Kanti's delayed kill was sung? In a different scenario, if the Inventor gets sung for whatever reason, what the hell happens there? I suppose that these are not the most on-topic examples as they are more role-related than priority related. But we have had, in game, a future bus to a dead player you was redirecting shit from himself (I think I'm remembering that correctly). This may sound a bit conceited, but until you've cohosted in one of those games, and even maybe after, its hard to get the instinctive nature behind priority resolution. I do believe that is is instinctive because GreY and I almost never disagree on how things should play out - 99% of our disagreement comes in the setup phase, where (for example) I want to kill everyone and GreY just wants them confused but alive .
Now, it helps that we rarely run setups with multiple copies of powers. But lets take the two bus drivers issue, and let me show you how I solve it. Graphically! The method is simple. Odd numbers swap, evens cancel out! Observe. In 1, A is swapping BC, and B is swapping CD. C is being swapped two times (an even number). It does not move, and the resulting swap is BD. In 2, A is swapping BC again, but this time B is swapping AC. C again has two swaps, and the resulting swap is AB. In 3, D has decided to join the party as another busdriver! The swaps are AC, BC, and BC. B is swapped twice, C is swapped three times. Since three is odd, the result is AC. In 4, D has decided to be sneaky an swap himself! AD, AC, BC. 2 As, 2 Cs give us the result BD. "Aha, iGrok!", you exclaim, "I have broken your logic, using example 5! Observe, by adding a fourth busdriver, I have made 4 odd swapcounts! How will you solve this now?!" Well, the answer is quite simple once you list the swaps. You have managed to copy the AC swap. Obviously, when two people are swapped twice, the swaps cancel out. Therefore, you are left with two unhindered swaps - AD and BC. Furthermore, if you are planning a game with 4 or more busdrivers, you are probably me. So bus driving is just "swapping"? I thought it was just busdriving. I.e opening a channel between people that target both players (i.e "bussing" each player that targets one of them to the other player's house). If you open a bussing channel it is still open if someone opens the same one. So someone bussing A and C, and someone ELSE bussing A and C, means A and C are still bussed, not that the bus cancels out. At least that's how I think about it. There is also another way to think of bus drives: If you bus A with B, then every time someone does something on A, it will happen on B, and viceversa. Nothing more, nothing less. So, if someone does X on A, it will be done on B. If someone does X on B, it will be done on A. How's this any different? Well, if you have someone bus AC, then CB, if someone does X on C, it will instead be done on BOTH A and B. Because bus AC implies that anything that happens to C instead happens to A, and bus CB implies that anything that happens to C happens to B. So if anything happens to C, it happens to both A and B. But if something happens to A, it only happens to C, not B. IN this case the bus is not a "channel", but just what the definition states: an action done one someone is instead done on someone else. This 2nd definition is the easiest to manage. Stacked busses only means that, stacked "something happens to someone else" stuff. You can always logically determine what happens to someone by doing this: -I target player X -I look at all busses that night between X and some other player Y. I don't take into account repeated ones. -For every XY bus, I instead use my action on Y Granted, this duplicates actions, so if you have 1 vig shot target A, and busses AB, AC, AD and AE, then B C D and E will all die, even when you only had 1 bullet. That image thing you posted works, yes; but for what I know it only works between busses. What happens if you enter a RBer into the mix? What if you enter other more complex redirection roles into it? Does it hold? Also, entertain this example and tell me what happens iGrok:There are 4 players, A, B, C and D. Busses are AB, AC, AD What happens? There are 4 odd "endpoints", yet no repeated busses.
So lets take things one at a time.
1) What is bussing?
The most important thing here is to know the busdriver ability:
You may bus two players, causing any actions that would affect one to affect the other instead.
2) Multiple Busses
When multiple Busdrivers are involved, there are three choices. Either all busses are non-interactive with each other, physics fail, or you simplify. non-interactive busses lead to daisy chains pretty quickly, especially in games where we have future busdrivers and shit like that - you have 1 mafia kill hitting 3 people and making the game swing way out of balance. Physics fail, while amusing that one time, is a horrid explanation. My method of simplifying the swaps is the happy medium - we still get busses, there are no daisy chains, and nobody's ability is cancelled because it made things too confusing.
3) Priority
No two roles which could possibly interfere with each other share the same priority level. Bus Drivers are pretty high on the list, for the most part only below roles which change the target (as opposed to moving the target player). Redirecters, Mind control, etc fall into this category. Roleblockers are a special case in many regards, but mostly because Roleblockers have two priority levels. Roleblockers are both First priority and Post-Movement. Any roleblock which would prevent a Control or Movement role occurs first. Then the Control/Movement roles happen, following their priority. Then all other roleblocks (Anti-Action RBs) occur, followed by all other actions (in whatever priority they have).
By the way, the difference between Control and Movement roles are whether target is used as an adjective or a noun. Mind Control changes the target(adj.), while Bussing changes the target(n.)
4) That is a complex problem, but not one without a solution. Here is my answer.
![[image loading]](http://imgur.com/dgA62Wl.png) . Note, it is up to you how you decide which players are B, C, and D. Also remember that the worst thing you can do is allow a kp to explode and kill multiple people in a weird, unsatisfying way.
I've now been up for ~ 30 hours so I might not be the most coherent but i'm doing my best.
|
I wouldn't of allowed a bus driver to bus themselves. If I remember, I think that's what I was most annoyed about. That's the reason there was a problem. I think tnkted had just been PMing/talking with LSB asked him if he could and he said yes without thinking and then couldn't go back.
|
What we need is a game with an afterlife. Everyone in their first life thinks that when you're dead you leave the game as normal. However, dead players don't actually die but go to a secret dead-player-thread where they can perform night actions which affect the normal game.
"why didn't I successfully mind control the busdriver"
"because the busdriver was zombie-bussed by dead ninjas"
|
I once played mafia in a game where town had an unlimited-shot vig that added the townies he killed to a shared QT on shooting them.
Then we sniped him night1 and the only thing town had left was a shitty version of a joat or something like that and the host of the game got really mad cuz we b stylin' on his special snowflake role.
Yes that's the extent of my input
|
On September 17 2013 06:11 Dandel Ion wrote:
I once played mafia in a game where town had an unlimited-shot vig that added the townies he killed to a shared QT on shooting them.
Then we sniped him night1 and the only thing town had left was a shitty version of a joat or something like that and the host of the game got really mad cuz we b stylin' on his special snowflake role.
Yes that's the extent of my input
That's my one problem with my upcoming PYP
So many awesome roles that will never see the light of day
QQ
Dandel less do numbers tonight :D
|
|
|
Cool beanos. I'm also really excited for you to write all those role PMs like you said. 
|
On September 17 2013 02:57 gonzaw wrote:
Also yeah the whole "bot" thing I was talking about earlier (like in January or something) is on hold. It's too "big" to start willy nilly like I was planning to. Plus I'm busy with uni and work don't have a single free time left (notice how I haven't joined a mafia game in like 3 months).
I was thinking about maybe doing it open source. Instead of a super-awesome server with everything, it could be an OS installation that installs the server for your specific forum. But leading an open source project is too much work as well so meh. Next year we'll see.
Meanwhile you have walking-super-computers Greymist and iGrok here so you have nothing to worry about.
I am definitely out of my depth in this topic and will probably sound like an idiot for even talking about it but let me give it a try.
I understand that having an account that just posts votecounts every 3 hours is likely not even possible on TL, but a program that just spits out a formatted votecount with the press of a button doesn't seem too farfetched?
I've noticed that small threads have an "all" button next to the page buttons, to display it all. All this does is add "&view=all" to the link, and when I do this for bigger threads it tells me I need TL+ for that function. So perhaps it would be possible to enable that for all users just in the mafia subforum (like filters).
Given that that option is available (or simply using a voting thread, they dont tend to go big), surely a program that's not too complex could filter out voting formatting and turn that into a votecount post that can be copy pasted by a host or cohost?
Again, I'm probably being the guy that says "if I can balance my checkbook why can't the US balance their budget" when obviously I'm simplifying everything, but I'm curious.
|
Blazinghand
United States25551 Posts
It wouldn't be that hard to take like a normal forum crawling bot and hook it up to some regex stuff that looks for literally ##vote:
it can parse that and put it in a list, then print it in a formatted way pretty easily
you'd want to use a voting thread link like this http://www.teamliquid.net/forum/viewmessage.php?topic_id=420228&view=all and then probably the hardest part would be making sure that it grabs stuff from within the text boxes and not a thread titled ##vote
but yeah I mean if someone can make a program that's capable of downloading a webpage and handing something over to a python script I could probably just use regular expressions and sikuli to parse the info and print it into some kind of human-readable format, then paste it into the textbox and hit post
i'm so lazy though
so lazyyyy
|
kitaman27
United States9245 Posts
On September 17 2013 07:40 Clarity_nl wrote:Show nested quote +On September 17 2013 02:57 gonzaw wrote:
Also yeah the whole "bot" thing I was talking about earlier (like in January or something) is on hold. It's too "big" to start willy nilly like I was planning to. Plus I'm busy with uni and work don't have a single free time left (notice how I haven't joined a mafia game in like 3 months).
I was thinking about maybe doing it open source. Instead of a super-awesome server with everything, it could be an OS installation that installs the server for your specific forum. But leading an open source project is too much work as well so meh. Next year we'll see.
Meanwhile you have walking-super-computers Greymist and iGrok here so you have nothing to worry about. I am definitely out of my depth in this topic and will probably sound like an idiot for even talking about it but let me give it a try. I understand that having an account that just posts votecounts every 3 hours is likely not even possible on TL, but a program that just spits out a formatted votecount with the press of a button doesn't seem too farfetched?
Zona's bot was helpful to have for normal games without vote mechanics since it provided near instant updates after every vote by editing the OP of the voting thread. You could configure it at the beginning of each day to only count votes between a certain set of dates so there wasn't overlap, you could choose the lynch type, and have it display a message.
|
|
|
|
|
|
EPT
