I’m trying to build an installer that still alows anyone to use the samples and run the eggcacher part of the installer. The problem is whenever I build the installer via makepanda the eggcacher doesn’t run during the install…and the error is only displayed for half a second so I can’t see what it is. Anyone have any suggestions on this one? I need to be able to build the modelcache or else none of the sample programs run. I have the samples folder sitting in the root of my panda source in case that’s the problem
The model cache is only an optional step; the samples should just fine without it, though they will take a little bit longer to start up.
So, if the samples are failing, perhaps the reason they are failing is the same reason that the model cache is failing. What is the error message from the failed samples?
Weird, they’re not failing anymore after I just built the source again.
The only changes I made were deleting a lot of secondary python/Panda interpreters from my system path that I use to test some of builds just in case they were conflicting. But the error I was getting was that the models weren’t being found on the model path essentially. I only got concerned about the cache because I know the samples get cached during the install and it was obviously coming up in the search path. I’ll see if I can dig around and reproduce the error again, because I’m afraid it may come up later on a different machine. Thanks for the help as always
also when I go to run the eggcacher executable from the Panda directory I get an error that it can’t find the os module…this may be the cause for the failure during install.
C:\Panda3D-1.7.0\samples\Bump-Mapping>python Tut-Bump-Mapping.py
DirectStart: Starting the game.
Known pipe types:
wglGraphicsPipe
(all display modules loaded.)
:loader(error): Couldn't load file models/abstractroom.egg: not found on model p
ath (currently: "/c/Panda3D-1.7.0/python;/c/Panda3D-1.7.0/etc/..;/c/Panda3D-1.7.
0/etc/../models")
Traceback (most recent call last):
File "Tut-Bump-Mapping.py", line 174, in <module>
t = BumpMapDemo()
File "Tut-Bump-Mapping.py", line 60, in __init__
self.room = loader.loadModel("models/abstractroom")
File "C:\Panda3D-1.7.0\direct\showbase\Loader.py", line 169, in loadModel
raise IOError, message
IOError: Could not load model file(s): ['models/abstractroom']
That’s the error, I did not build the model cache this time around upon installing.
The only models in that path are the ones from dmodels and such, no sample models. However, the more troubling thing is that the sample’s egg that’s being loaded via
is actually pointing to the correct place. Shouldn’t this find the right egg and load it without having to go to the search path? It almost seems like the interpreter is resetting the current working directory or something of that nature.
Only if the search path includes “.”, the current directory.
Like Unix $PATH, and unlike Windows $PATH, a model-load operation always traverses the model-path; it doesn’t look in the current directory implicitly.
The model-path doesn’t include “.” by default. It does include $MAIN_DIR by default. I wonder if there’s a bug in $MAIN_DIR. Can you put this somewhere in the code:
from pandac.PandaModules import ExecutionEnvironment
print ExecutionEnvironment.getEnvironmentVariable("MAIN_DIR")
Here’s what I got after printing out $MAIN_DIR using your code
C:\Panda3D-1.7.0\python
Could I just include “.” by default in my config.prc and fix the problem that way?
I will say this. The only reason I’m using my own build of Panda is for a modified execution environment that allows the maya egger to run by catching an exception in pystub (not the greatest fix I know, but I’m still fighting to build the egger with static linking). However, my source is up to date, I just added the try/catch myself.
EDIT: One thing I did notice about executionEnvironment.cxx is that i had to change the #include to #include <stdio.h> to get it to find it correctly.
That’s weird. The MAIN_DIR is supposed to point to the directory where your python file is, which is supposed to contain the correct value if Python is linked in correctly.
You can put “model-path .” in the Config.prc, but it’s not an ideal solution because it requires you to run your program from the directory in which it resides - if you run it from a different working directory, it won’t work. That’s the whole point of $MAIN_DIR, it is supposed to point to the directory that contains the Python file - but in this case it seems to point to the directory containing python.exe.
(When you’re running Python interactively, $MAIN_DIR points to the current working directory, however.)
Maybe something went wrong during the compilation? Something that made HAVE_PYTHON not be defined while dtoolutil was being compiled? Or the Python library was linked in incorrectly? Or maybe pystub got accidentally linked?
Can you try putting this in a python file in some directory, and running it? (not from the interpreter)
import sys, os
print os.path.abspath(sys.argv[0])
It’s supposed to report the path to your Python file, rather than the path to python.exe.
Wait, you had to change to <stdio.h>? You must be using an ancient version of executionEnvironment.cxx. That would explain why you are having the issue - old versions of ExecutionEnvironment may not include the proper code to set $MAIN_DIR correctly.
Just recompiled and I got the same results as before even with a new checkout of executionEnvironment. Gonna try wiping out the core python install I have that may be getting in the way (although it’s not the first interpreter in my system path when running panda stuff). If anyone gets a brainwave on this one send it my way.
Why put a try/except block around it? Why is that necessary in the first place?
Because in the case of pystub, Py_IsInitialized is a simple function that just returns 0.
Anyway, now I see the error, and it’s quite simple. You forgot to store the result of PySys_GetObject in obj, so it will fall back to the case where it returns the CWD.
Try this:
The only reason I did so was for the maya egger and it’s lovely conflicts with Autodesk’s python interpreter/libs. I used it in place of getting a build of maya2egg that linked to static libraries.
I didn’t originally write the fix (or hack) myself, and i know it works when running the egger. (although apparently I lost that little bit of code somewhere along the way). I would obviously rather not have to use it, but the 2010 egger freaks out under a lot of circumstances where it shouldn’t because of something on Autodesk’s end. So until I get a statically linked egger built, or Autodesk fixes something miraculously, I’m stuck with it for now.