One of the features of the Firefly render engine, introduced in Poser 5, is that you can do math with images. For each point in UV-space, the brightness of the texturemap can be treated as a number, and modified. Or you can use numbers to create a texturemap. And the system treats black as sero, white as one. Except when you feed data into the transparency node. A numeric setting of 1 in the actual transparency node is completely transparent. But a texturemap fed into that input is handled as if black has a value of 1 -- the inverse of the normal behaviour. Obviously, this is necessary to maintain compatibility with Poser 4 and earlier. Most of the time, it doesn't matter. It's even helpful, since you can use the unmodified transparency map on the specular value input to kill the reflections where you want a hole, but that's also an example of what can catch you out. What you're doing with that specular value is multiplying the numeric value by the equivalent value of the texturemap. Black is zero, so the black gives you zero reflection. I suppose we could call it an opacity map, but there's no point in changing now. But if you're working with transparency, and something odd seems to be happening, just check that you haven't forgotten that hidden inversion.

Quote - you can use the unmodified transparency map on the specular value input to kill the reflections where you want a hole, but that's also an example of what can catch you out. What you're doing with that specular value is multiplying the numeric value by the equivalent value of the texturemap. Black is zero, so the black gives you zero reflection. I suppose we could call it an opacity map, but there's no point in changing now.

I didn't know that. Thanks for the tip :)

Thanks for that tip.  I've been caught by the problem several times;
ended up fiddling around blindly until it looked right; knew something
was backwards, but didn't understand the basic inconsistency.  

Now I can at least fiddle around half-blindly!