The default behavior–and this is what is meant by “etc”–is the following algorithm:

  1. Start in the directory in which libdtool.dll is found. Say it is /c/Panda3D-1.3.2/lib.

  2. Check for a prc file in /c/Panda3D-1.3.2/lib/etc/*.prc. If one is found, stop there.

  3. Assuming a prc file was not found yet, back up to the next parent directory. In this example, this means to check /c/Panda3D-1.3.2/etc/*.prc. If one is found, stop there. In this example, of course, normally one will be found here.

  4. If a prc file is still not found, continue walking up the tree in this manner until a prc file is found, or the top of the tree is reached.

Note that this algorithm really has nothing to do with your panda3d.pth setting. It’s based on the location of the first libdtool.dll that was found on your PATH variable.

So if it’s not able to find a prc file, is it possible you’ve made a copy of libdtool.dll and put it in a different place?


Ah, I see what has happened.

libdtool.dll is actually a fundamental DLL to Panda. You could not possibly run any Panda applications, including the Greeting Card without it. So it very much surprised me that you don’t have it on your system, until I remembered that Josh has recently put in some changes to the build script to rename this to libp3dtool.dll (and similar changes to the other Panda DLL’s).

But the rule is still looking for libdtool.dll, which is why it’s failing to locate your prc file. Oops! Without being able to find libdtool.dll, it will fall back to plan B, which will be to look for a prc file by walking up from the current working directory.

So that must be why the greeting card is working–because that script probably sets the current working directory to the greeting card’s directory, which is in the panda3d directory (so it can find the prc file).

That suggests a workaround: you could make your run.bat file change the current working directory to something under the panda3d directory before it starts your script.