The Wiki for Tale 4 is in read-only mode and is available for archival and reference purposes only. Please visit the current Tale 11 Wiki in the meantime.
If you have any issues with this Wiki, please post in #wiki-editing on Discord or contact Brad in-game.
Difference between revisions of "Talk:Paint"
Hephaestus (talk | contribs) |
Hephaestus (talk | contribs) |
||
Line 4: | Line 4: | ||
The original version of PracticalPaint has some relatively subtle bugs. It's accurate most of the time, but you occasionally get some goofy results, particularly in the large cluster of colors that are close to white (snow, white smoke, etc.). That being said, it's still mostly usable as long as you make sure the ingredients have accurate color values. I have a new version that I rewrote from scratch a few weeks ago, but it's not cleaned up to be worthy of public consumption yet. It's on my list to do so, but it depends how much free time I have. It should be available before large-scale paint requirements start showing up on buildings, at least. -Sigil | The original version of PracticalPaint has some relatively subtle bugs. It's accurate most of the time, but you occasionally get some goofy results, particularly in the large cluster of colors that are close to white (snow, white smoke, etc.). That being said, it's still mostly usable as long as you make sure the ingredients have accurate color values. I have a new version that I rewrote from scratch a few weeks ago, but it's not cleaned up to be worthy of public consumption yet. It's on my list to do so, but it depends how much free time I have. It should be available before large-scale paint requirements start showing up on buildings, at least. -Sigil | ||
* I suspect the errors when paint tolerances are close because I've noticed that teppy has actually coded in fractions of RGB values, which can cause rounding errors. I have made a spreadsheet that accurately predicts RGB outcomes based on whatever ingredients I throw at it, but you can almost always assume a +/- of about 3 on each value. The higher value colors tend to be closer together, so and small drift can have unforseen consequences. I really don't think there's a way around this as, to my knowledge, fractional values of R, G, and B are not easily detectable. --[[User:Hephaestus|Hephaestus]] 13:16, 23 March 2009 (EST) | * I suspect the errors when paint tolerances are close because I've noticed that teppy has actually coded in fractions of RGB values, which can cause rounding errors. I have made a spreadsheet that accurately predicts RGB outcomes based on whatever ingredients I throw at it, but you can almost always assume a +/- of about 3 on each value. The higher value colors tend to be closer together, so and small drift can have unforseen consequences. I really don't think there's a way around this as, to my knowledge, fractional values of R, G, and B are not easily detectable. --[[User:Hephaestus|Hephaestus]] 13:16, 23 March 2009 (EST) | ||
+ | ** I also have a theory that, contrary to what the old wiki pages say, reaction additions, subtractions ARE ordered when they are close to either extreme. For instance, in the mixing of Silver Powder then Lead for me, if I mix in a 9:1 ratio, the averages should come out to 27, 27, 41 (RGB) and a reactional adjustment of 0, -39, 0, leaving me with a resultant 27, -12, 41. Instead of green going to zero as you might think, sometimes it seems to halve the distance from the 27 to the 0. I have not proven this beyond the shadow of a doubt though. Even if I'm wrong about halving the distance, the lab doesn't seem to carry negative values from any reacion to the next. So, instead of losing 39 green in the above example, I simply lose 27 before the next reaction/ingredient is added. This causes some wonkiness at any extreme that's difficult, but not impossible to account for. --[[User:Hephaestus|Hephaestus]] 13:23, 23 March 2009 (EST) |
Latest revision as of 18:23, 23 March 2009
Please someone fix sigil's practical paint for this telling and put in the deadtongue and its values. I still have a great excel sheet that you just fill in the blanks once you figure out your values from color cop. but cant paste from the excel to PP without the correct dead tongue values. Tawret
- Here's a link for sigil's practical paint program. I have done nothing to modify it, but I was unable to locate a link that still worked for it. If some setting needs changing for t4, then please, someone that knows what they're doing with it, make the change. Media:Practicalpaint.zip -- AmisiBastet
The original version of PracticalPaint has some relatively subtle bugs. It's accurate most of the time, but you occasionally get some goofy results, particularly in the large cluster of colors that are close to white (snow, white smoke, etc.). That being said, it's still mostly usable as long as you make sure the ingredients have accurate color values. I have a new version that I rewrote from scratch a few weeks ago, but it's not cleaned up to be worthy of public consumption yet. It's on my list to do so, but it depends how much free time I have. It should be available before large-scale paint requirements start showing up on buildings, at least. -Sigil
- I suspect the errors when paint tolerances are close because I've noticed that teppy has actually coded in fractions of RGB values, which can cause rounding errors. I have made a spreadsheet that accurately predicts RGB outcomes based on whatever ingredients I throw at it, but you can almost always assume a +/- of about 3 on each value. The higher value colors tend to be closer together, so and small drift can have unforseen consequences. I really don't think there's a way around this as, to my knowledge, fractional values of R, G, and B are not easily detectable. --Hephaestus 13:16, 23 March 2009 (EST)
- I also have a theory that, contrary to what the old wiki pages say, reaction additions, subtractions ARE ordered when they are close to either extreme. For instance, in the mixing of Silver Powder then Lead for me, if I mix in a 9:1 ratio, the averages should come out to 27, 27, 41 (RGB) and a reactional adjustment of 0, -39, 0, leaving me with a resultant 27, -12, 41. Instead of green going to zero as you might think, sometimes it seems to halve the distance from the 27 to the 0. I have not proven this beyond the shadow of a doubt though. Even if I'm wrong about halving the distance, the lab doesn't seem to carry negative values from any reacion to the next. So, instead of losing 39 green in the above example, I simply lose 27 before the next reaction/ingredient is added. This causes some wonkiness at any extreme that's difficult, but not impossible to account for. --Hephaestus 13:23, 23 March 2009 (EST)