Request for help or advice for cube skill experiment using Gnubg

[playbg-rgb]

Greetings,

Some of you who follow RGB may already know about my
decades long arguments that equity, cube decision, error
rate, ELO ranking, etc. calculations are all tainted by arbitrary
constants, unumpirical and inaccurate of unknown degrees
which are magnified by their being circular independently
each and/or in groups, effecting one another.

Cube skill being the most hyped but inaccurate would also
be the easiest to debunk by running a few simple experiments.

After my daring the mathematicians, programmers, etc. for
years, finally Axel ran some crude experiments that were very
revealing, even if somewhat botched and incomplete. You can
read about them in RGB if you want.

What I want to do is run better experiments using Gnubg. I
considered various ways like using gnubg.dll, CLI scripts or
modifying the eval code of Gnubg. After poking around in
the source code, I concluded that the easiest, most flexible
and reusable would be the latter. (If people find it useful,
it can even be left in as a permanently added feature).

The cube decision points will be in a text format config file
containing user decided arbitrary values for double/beaver,
/take/drop, etc. with negative numbers indicating purely
random decisions. (Again these may be read from existing
cinfig files for ease and/or if made a permanent feature).

The eval logic will be modified by adding a few lines, after
the winning chances are normally calculated, to check if
the player2's name is "mutant" and to substitute the cube
decisions for that player from the config file. Nothing else
will be modified.

How the results of long trials can debunk the so-called
"cube skill theory" can be discussed separately, before
and/or after running the experiments.

I realize that this is like walking into a church and asking
the flock for help to prove that there is no god. But one
never knows unless one asks. So, I am asking.. ;)

The best that I am hoping is that someone open-minded
and familiar with the code will volunteer to do this. If not,
maybe someone will offer me help to suggest/locate the
best section of code to modify and maybe offer alternative
ideas about doing it better, more efficiently, to be more
expandable later, etc.

Alternatively, I can create a separate process to make calls
to gnubg.dll but that would take much more work, unless
someone is willing to share his existing code using gnubg.dll
BTW: is there a gnubg.dll newer than Mike Rudman's?

I guees a Python script can accomplish the same thing but
I'm not familiar with it at all, and I don't know if anyone
would be willing to do it, considering it would take more
work than the first option above.

Any benevolent agnostics or even good samaritan believers??

MK