@MustangMike: are you referring to the EZMat addon itself, or to the EZMat plugins which do the various jobs? The first is more or less required in the Program Files environment, the latter are advised to be stored outside it.

As was stated deliberately in the User Guide, EZSkin and most EZMat routines rely heavily on node-constructions, usually plugged into the Alternate_Diffuse and/or _Specular slots, and are accessible only through the Advanced Interface route.

When you want to build shaders that have a decent change making it to external renderers and file formats (Octane, Reality/Lux, OBJ/MTL export, ...) limit yourself to the options from the Simple Interface only. The Poser material definitions are Firefly only, and are rarely supported by unbiased renderers at all.
One can craft shaders that work in both worlds though. And the good news from EZMat is, that you can make your own EZMat plugins that do the job for you (and others, eventually).

@Snarly : I really dislike the random behavior of things. But I did find a note in a D3D paper on Python plugins, stating that scripts which launch with the Poser program itself might need some delay(...) upfront. Otherwise they run the risk that Poser hasn't stabilised fully when scene references are called. Addon scripts (EZMat init) might be sensitive to this, while regular scripts (EZSkin) will not be. And timing details of exe stabilisation after launch depends on so many things, that it might explain the random appearance.
Just guessing anyway.

- - - - - 

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though