Maybe you can also try a daily build… It could give to you some indications early, and you can support developers reporting issues…
are the snapshots supported by the p3d runtime? The problem is that i need the p3d files for distribution so a not released version may be useless for me…
From the p3dcore.log: codepad.org/CbUKXuey
Is there a way to get the path there the p3d_basename?
Do you have an idea why it cannot find the boost dll? Well in fact I only see panda3d,audio,morepy and openal in the PATH set by packp3d if I got this log correctly: codepad.org/CbUKXuey . There should the files be unpacked? You said something about a Temp folder. Should the dll be placed there too?
As you guess, the snapshots are for development only, and are not supported by the runtime, which is strictly 1.7.0. We are working on adding a development runtime option for the future.
Hmm, it doesn’t look like the AppRunner currently saves this path. It could do so, I guess, but is there any reason to have the p3d file itself? What could you do with the raw p3d file that you can’t do with the mounted filesystem?
Hmm, you’re right, it seems like something’s missing here. Let me investigate more closely.
David
I dont need the file itself. I just need path there the p3d was placed. Then I can tell the user to copy the p3d in the folder there his game is installed to get it running. Currently the user have to place the game at C:/SF .
The p3d file is likely to be a temporary filename in the browser cache directory. Better to have the user right-click on a link and install it from the web directly.
David
Well i want an “exe-like” solution, which is simply dropped into the game directory and started from there. No webstuff at all. Currently I use packpanda as a temporary workaround but i dislike the fact, that it install itself.
I thought p3d should be the way to distribute panda-based apps in future. But then I need the path from there the p3d is opened to get the path there the original gamedata are placed or do you have a better idea? Asking the user at every startup there the original game is located? Using fixed+absolute game paths? Both not really userfriendly solutions 
Is acceptable to you to put external files in the runtime’s ‘start’ folder (on my machine is C:\Users\yaio\AppData\Local\Panda3D\start)? In this way you can access external files (without knowing the exact path e.g. to open the file C:\Users\yaio\AppData\Local\Panda3D\start\test.txt from Python you can submit fileHandle = open ( ‘test.txt’ ) if you are executing it under runtime).
And this solution is not tied to the runtime. If you pack your p3d file with pdeploy, when you launch it the ‘start’ folder is created in the installation directory (or the current directory, if you built a standalone executable).
So, for example you can put with your installer your DES files into the ‘start’ folder, and then you can access them without knowing the path of AppRunner.
But I don’t know if this solution is satisfactory to you. 
A closer solution. If you want to obtain an executable, and work with some other files in the same directory, you can build the executable with pdeploy and then open the files that are in ‘…’ (the folder above ‘start’ i.e. the current directory).
And if you want to maintain the same code for the executable and your developing copy, you can do something like this:
fileHandle = open ( ( '../' if base.appRunner else '' ) + 'test.txt' )Note also that if you pack your p3d file with the parameter “-c keep_user_env=1”, then when you run the p3d file, it will run with the user’s current directory as the start directory, instead of running out of the Panda3D/start folder. It will also preserve more of the user’s existing environment variables. This is intended primarily for command-line tools and such, things that have to take into account the user’s existing environment, as opposed to a p3d file that is intended to run entirely self-contained. It rather seems like you want something more like this.
Since you’re constructing the C:/SF folder by hand, why can’t you put the p3d file in that same folder and run it from there?
David
-c keep_user_env=1 works perfectly 
. So I just have to wait for the corrected panda3d version with the corrected file.py and the working openAL 
. The boost dll can I distribute as a seperate part which has to placed in the same dir as the p3d, so due to the “changed” path it will be found correctly