Robinette wrote:Well it is possible that he's figured out an improvement to the dice patch i shared awhile back... i only worked on trying to improve my own dice, but perhaps he came up with a way to worsen his opponents dice at the same time.... and if he figured that out, he deserves every point, cause that's a insane boat load of work to do to prepare for a single turn...
For those who are interested, i am reposting the details from 4/1/07 that explains the basics...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.
I was right with you up untill well
we will be looking into it 
