- Choose one: OpenOffice T3_paint_reaction_values.sxc or MS Office T3_paint_reaction_values.xls
- optional Reaction Values for placing in your userwiki page for example
Easy Guide
- install colorcop
- extract Practicalpaint.zip to a nice location
using a spreadsheet is recommended
using this guide is gives very accurate values if used well
- startup colorcop
- start windows calculator, or use a reallife calculator
- on the calculator do 51/52 then place it into memmory you'll need it alot !
- open your filling form of choice (spreadsheat, reaction values template)
- start ATITD (if you haven't already)
- throw in the ingredients of on your list (spreadsheet, reaction values template)
- alt tab to colorcop or click on it in your taskbar
- pickup the dripper in colorcop and hold it on a pixel just before the start of the coloredbar (all bars start at the same point)
- release it and look at colorcop for the coords (Eyedropping xxx,yyy)
- try to move it to a simple to calculate starting point like 500
Aligning the paint ingredients window to the leftmost edge of the screen places the starting point at 10 pixels; easy math - djKap0w
- pick the last pixel of the R bar
- if you alligned your pixel just before the colorbar at 500 then 631 is 131 pixels long
- on your calculator do 131 * stored value (51/52)
- round the value and fill it in on your list (spreadsheet, reaction values template)
repeat for the other color bars
template only
- calculate your changes the expected values are your base
you will notice all uneffected colors will not be changed in any when when done correctly
if your other colors are also affected and it's not a White reaction, make sure you alligned your color bars correctly !
spreadsheet + template
For Sulfur + potash / potash + sulfur reactions see Subzero guide
- look at he colorbars in your atitd screen, if one shows completely empty your test has subzero-ed
- Except when the result should be white then just exclude the bar that has subzero-ed (may be multiple)
- this means the reaction came lower then 0 and you can't measure it the normal way
- look here for advise Subzero
after you've done this all rinse and repeat and do your next reaction, good luck
with rinse i mean fillup with a cheap ingredient like clay, clean the lab and take paint
Mac Methods (by Zuvun) (this is a work in progress) First off, Preview has all the functionality you need tp pick the RGB values -- no shareware tools needed! If you want to "Eye-dropper" to pick the actual screen RGB value, in Preview, under tools, select Show Colors. Click on the magnifying glass and you have the eye dropper to pick a color. In the "Colors" floating window, select sliders -- the 2nd icon in the tool bar -- and RGB values from the pop-up memnu.
If you want to measure the bar lengths -- the more accurate way of doing this, due to the alpha blending problems -- Preview also has the tools.
First off, pin the Pigment Lab dialog and move it to the upper left corner of your window. When you have the color you want to measure being displayed, take a screen shot (opt-C). I then hide the ATITD client and double click on the screen shot file you just made (its in the Documents/eGeneis folder in your home folder, which I keep in list mode sorted by Date Modified). It should open up in Preview.
The tool we're going to use is the Grab/Selection in the file menu. To make this easier and more accurate, we're going to start by increasing our resolution. (You'll want to double check the values following; they may differ on different screen configurations. I am using a 1440x900 resolution for my main monitor.) Under View select Actual Size (you can make this the default in preferences). Hit cmd-+ 4 times, which makes the image 4x larger, roughly. Then maximize the Preview window (hit the + in the upper left). This moves the window to a specific location -- as far left and up on your main monitor as possible, and scroll the window horizontally as far left as possible and vertically so that the 3 RGB bars are visible (and a bit below the screen center to avoid a pesky "help" message interfering with us). On my screen this results in the left most edge of RGB bars being at 42 and the right at 1082, yielding a bar length of 1040. So instead of the 51/52 (255/260) factor discussed above we will use a 255/1040 value to resolve our readings.
Now you can read out the values from the RGB bars. Select Grab/Selection in the File menu and determine X coordinate of the right most edge of each of the 3 color bars. Subtract 42 from each of those values, divide the result by 255/1040 and round.
Since you are working with a 4 times larger image, its much easier to not make a mistake reading the X coordinate (you can be off by a pixel or so and be much less likely to get a wrong value as a result), and having the bars in a known location at a known size makes the arithmetic simpler. (One of my biggest pet peeves -- its arithmetic, not mathematics. The math is the same in either case.)
I've managed to get Kempaint working, but with difficulties.
- The makefile doesn't work in the MacOX shell; Copying the code to an XCode project and building (a 3 minute job, total) worked fine. I can make the G4/G5 variant of that avialble -- contact me in game please. An Intel version I'll be able to do in a week or so.
- The data files supplied with Kempaint are out of date (the T3 colors have to be added; the bases file has alpha adjusted values which should be replaced with the actual base values; you'll probably want to adjust the costs file)
- The Kempaint export table from the spreadsheet is wrong in a couple respects
- Iron is ouput as ir; Kempaint expects io
- The additional reverse reactions (the bottom half of the spreadsheet) need to have their base codes reversed to reflect that they are giving the value for the reaction reversed) and the list may be incomplete.
After a bunch of handwork to fix the above, Kempaint produces mostly good results and is fairly quick about doing it. However, it still makes mistakes; I suggest that if the distance of the "best" result Kempaint shows is > 15 you rerun it setting a lower distance target to get a recipe which is more likely to succeed.
I'm playing around with a brute force program to figure paint recipes, rather than the limited search methods in Kempaint (and eliminating what appear to be some errors in Kempaint regarding the maximun unique item rule and reactions). Although, at first glance, a brute force program (evaluate all possible recipes) seems an interminable task (Something like 15^^15 possbile recipes) I think a couple simple hueristics and a learning mode can reduce the space tremendously (without ignoring any possible recipes). Of course, the fact that I'm working it in pure C without re-entrant coding means it will be immensely more efficient than these C++ programs using actual procedure re-entrancy; at least an order of magnitude and maybe more.
