Wow, I can sure remember that feeling of despair when it seemed lady luck had abondoned me. But rather than just take it, I worked long and hard to gain an edge by maniuplating the card program.
Now before someone responds with a lecture about this being cheating, let me just say that many threads have already debated the difference between cheating and exploiting a weakness in the program. This is no more cheating than a double turn in a freestyle game, or partnering with someone with an ultra low score, noob hunting triples games, etc, etc. By the way, for the record I don't do ANY of those other things. So again, this is NOT cheating, and if lack really wanted to prevent all these little game exploitations he could change the game parameters to prevent it.
Anyway, for those who haven't seen it yet, I'm reposting the basic method to hack into the card program, just know that it is a bit complicated to explain without a whiteboard.
First off, it doesn't work with flat rate, and it doesn't work with team games. Here 's why... it is all about the Cyclomatic Code Complexity within this site. The simple part to explain is that on this site the 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 scores 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 games. 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! I get an extra card. Ok so thats pretty much all there is to it.
A while back I started to modifiy this to work with flat rate, but I don't think it would really be worth all the effort. So if you really want this for flat rate, let me explain how far I got and you could work on finishing it. You would have to revisit the treeview with ONLY valid namespaces and ONLY valid classes created. We would also have to find the NameSpaces object which contains the list of strings (for namspaces) and for each string of ucClass objects (for the classes). The list of ucClass objects are created by this and are then ready and waiting to be placed on a suitable code. But as yet we dont know what classes the user needs, it could be all of them, or it could be 1 of them or even none of them. It depends on what the user selects from the treeview on the mainform (frmMain.cs). And that's where I got stuck. So I looked and I looked for an answer. The only thing simliar at all, was GDI+ and in order to do something like this, a destination target needs to be created at the full string size, and then the viewable (onscreen) fragments are printed to individual page framements and saved into the destination image at the correct x/y co-ordinates. In order to do this the application has to programatically perform scrolling to get the next page fragment code to merge with the destination code. I managed to get this to work, but it was a complete nightmare, and there were definetly bugs everywhere, which resulted in losing more cards that I gained! So if there is anyone reading this that is totally rad and knarly at GDI+, and knows how to save the entire contents of a scrollable control to an existing code, please feel free to let me know. As for the above code, it is code that I am kind of 1/2 proud of, but would rather wasn't there. Do you know what I mean? After all, sometimes you just get completely stuck with trying to patch all these code fragments together, to form the final destination code.
So for these reasons, it only works properly with 6 player std escalating games, so that is the only type of game that I play.
