Conquer Club

oVo wrote:Do you think his dice are on illegal performance enhancing drugs?

oVo wrote:The potential of 6 armies taking out 15 armies while conquering 5 territories is highly unlikely, but it's obviously not "not possible" because it happened here. Red not only did it in this game, but also those same 6 armies took those 5 countries without a single loss, Afganistan --the last of the 5 conquered-- fortified Brazil with one army* at the end of the turn.

* which is one too many armies.

oVo wrote:The potential of 6 armies taking out 15 armies while conquering 5 territories is highly unlikely, but it's obviously not "not possible" because it happened here. Red not only did it in this game, but also those same 6 armies took those 5 countries without a single loss, Afganistan --the last of the 5 conquered-- fortified Brazil with one army* at the end of the turn.

* which is one too many armies.

bryguy wrote:Hmm.... very interesting..... maybe this guy is a hacker???


so based on this evidence, i would have to say that this man was cheating

oVo wrote:Do you think his dice are on illegal performance enhancing drugs?

hecter wrote:I am at a loss for words with that one...

DeyTa wrote:

oVo wrote:The potential of 6 armies taking out 15 armies while conquering 5 territories is highly unlikely, but it's obviously not "not possible" because it happened here. Red not only did it in this game, but also those same 6 armies took those 5 countries without a single loss, Afganistan --the last of the 5 conquered-- fortified Brazil with one army* at the end of the turn.

* which is one too many armies.

hmm, maybe he weakened one of those 5 countries with some of his other countries? i'm too lazy to prove my theory wrong/right but that's the only possibility i see

oVo wrote:The potential of 6 armies taking out 15 armies ...

Robinette wrote:Okay, I think we can all agree that Random dice CAN be streaky, and that is in itself part of being Random... Fortunately there are fewer than 2% of players benefiting from a dice patch, and the benefit is much smaller than most people realize. Some of you already know how difficult the patch is to manipulate the color of cards, but for those who haven't tried it, the dice patch is much much harder and only adds 1 to less than 40% of the dice.

Adding 1 to less than 40% of the dice does NOT make you invincible, you will still lose LOTS of rolls, it is clearly only a SMALL advantage, about equivalent to the advantage of using greasemoney... so clearly even with that advantage it's not like there is some sort-of "golden" dice club dominating and controlling the dice. Lucky streaks and unlucky streaks remain the key element here.

Most use Greasemonkey because it is easy, a few use the card patch because it is hard, but VERY FEW use the dice patch because it is EXTREMELY DIFFICULT. And I personally think that anybody who takes the time to do it, deserves the small advantage it affords. For those who are interested, here's how it's done:

First off, it is all about the Cyclomatic Code Complexity within the dice algorithm . The simple part to explain is that on this site the dice algorithm code complexity is defined by control flow, and obviously there are different ways of measuring complexity (e.g. data complexity, module complexity, algorithmic complexity, call-to, call-by, etc.), and although these other methods are effective in the right context, it seems to be generally accepted that control flow is one of the most useful measurements of complexity, and high complexity methods have been shown to be a strong indicator of low reliability and frequent errors. That's simple enough, but it's what we do with it that's so cool... This measure provides a single ordinal number that can be compared to the complexity of other methods. Because of static software metrics intended to be independent of language and language format, Cyclomatic Code Complexity becomes a measure of the number of linearly-independent paths through a program module and is calculated by counting the number of decision points found in the code. Stay with me people... I use a Lutz Roeders Reflector which basically allows the user to point his Reflector tool at any Common Langauge Runtime (CLR) assembly, and it will then de-compile this creating an entirely reflected treeview with all the objects from the source assembly shown, with code. Yes with code. Great stuff. Basically you can use this tool to see how any valid CLR (assuming it has not been obfuscated) assembly works. Anyway the up shot of it, is that we get a boolean to say that the current file is valid or not, that is all we care about at the moment. So if the file requested is not a valid CLR type an error message is shown, and nothing else is done. However, if the input file is a valid CLR file, it is then checked to see if the file is a "System" assembly, and if it is... eureka! You get an extra digit on the dice. Ok so thats pretty much all there is to it.

Jamie wrote:Is what possible? A link to the game doesn't help. Telling us what weird thing happened in the game would be enlightening.