On Sun, Aug 9, 2009 at 10:31, comex<com...@gmail.com> wrote: > On Sun, Aug 9, 2009 at 1:16 AM, Roger Hicks<pidge...@gmail.com> wrote: >> Note that since developing it I've tried to make my program adaptable >> to this process. It hasn't been easy to come up with a workable >> solution, and it is still not complete, but my system now correctly >> models about 99% of the information it tracks. For those exceptions, >> I've designed it so I can go back and flag a past transaction as >> DISPUTED or FAILED. Upon doing so the gamestate is rolled back to that >> point, the corrected results of the action are processed and then the >> later actions are re-processed to generate the new correct gamestate. >> >> BobTHJ > > Ah, not bad at all! I was trying to do the same thing. How are you > dealing with intervening rules changes? > Each rule or contract defined action is a separate object class and file. Each of these has a startdate and an enddate property. When a rule or contract change occurs that alter's the function of an action it is a simple matter to copy/paste a new object class, modify the code to update its function, set the enddate of the old class to the date of the rule change, and set the startdate of the new class to the same. Then, when rolling back gamestate, for each action logged in the database the code compares the timestamp of that action to the startdate and enddate properties of the corresponding object classes and selects the one whose dates match.
BobTHJ
