packp3d_dev and pdeploy_dev

First of all, thank you for finding the time–I appreciate it. :slight_smile:

You’ve said that you’re busy, and you’ve just been sick: please don’t spend time on this to the detriment of either your work or your well-being. If I’ve seemed pushy then I apologise–this is just a frustrating position for me, and other factors might be exacerbating that frustration.

Ah, that would explain the web-version not working, then, yes. ^^;

Hmm… Possibly. The program runs well through the IDE, and I think that before I switched to the dev. version of packp3d and pdeploy, and was thus using 1.8, I got as far as my main menu (which doesn’t use Bullet, and thus doesn’t attempt to use the new Bullet functionality). However, it’s quite possible that either there’s some issue that I’ve missed, or that it’s somehow interacting poorly with the newer runtime…

On the other hand, the business with the “win_i386” directory, and the runtime’s subsequent failure to find that .xml file that it wanted, does look like a potential issue, given that the log immediately afterwards reports that the program has failed and is being shut down.

Sure–I’ll send a PM with DropBox links shortly after posting this message, I intend.

I have no problem running your .p3d file with the panda3d runtime standalone. I am greeted by a flashing text on a black screen with a quit button - I presume this is what I am supposed to see?

(I also tried opening it in FireFox, but this seems to lock up my browser, requiring me to kill the plugin-container process. But let’s tackle one problem at a time.)

So, let’s compare our environments. I’m on 64-bit Linux. I’m not quite sure which version of the runtime I have, but that could be a factor - I’ll have to try with both 1.0.4 and the latest devel. Should I try other platforms?

Oh, er, oops! I actually created a minimal experimental program in order to attempt my own minimal test (it didn’t work), and apparently forgot to re-upload the .p3d for the actual game! Sorry about that! If you re-download the .p3d (via the same URL that I included in my PM) you should now get the game. (I checked via Multify that the p3d was the correct one this time, I believe.) ^^;

My main testing environment is as follows:

Toshiba Satellite L755
Windows 7 Home Premium, Service Pack 1, 64-bit
Intel Core i5-2450M 2.5GHz
NVidia GeForce GT 525M, 2GB

I don’t have access to Ubuntu on the testing machine at the moment, I’m afraid; I’m attempting an installer-based version on my development machine (the one that turns up the driver errors–it seemed worth a shot), but the runtime downloads are proceeding very slowly (likely in part because there’s a Windows update being downloaded through the same connection); I’ll hopefully post again once that’s done and tested.

Using the 1.8 runtime you should be able to run the game as far as the main menu (and possibly the options menu–I don’t think that that I tried that), but it should crash when attempting to actually start a game, as 1.8 lacks certain features in its Bullet integration that my game uses. I think that for our purposes here such a run can still be considered “successful”, however, as the problem there lies with Bullet features rather than the runtime or program themselves.

As to the dev. runtime, to the best of my knowledge I’ve been using the latest dev. runtime as of each build (or whichever pdeploy has been downloading), although I haven’t changed my version of packp3d_dev or pdeploy_dev since the first post in this thread, I believe.

Hmm, let’s get terminology straight first, as your answer confuses me: the runtime is the tiny little thing that you download from the “Runtime” download page, and its latest version is 1.0.4. All it does is, given a .p3d file to run (whether via the web plug-in or with panda3d.exe, both part of the runtime) download the version of the Panda3D distribution that it references from the appropriate host URL ( or

The runtime distribution (abbr. “rtdist”) is what the runtime downloads from the host URL and it is versioned like 1.8, 1.9. Whichever version is used depends on which version of packp3d you use (being itself a .p3d file, and thus linked against a particular rtdist version and host URL).

(The role that pdeploy plays in this is that it simply bundles up a tiny stub version of panda3d.exe and stuffs your .p3d file into the rear end of this executable, and builds an installer around it that optionally contains a local copy of the runtime distribution. Basically, it’s like running the runtime with your .p3d but with the host URL pointed to a local directory.)

The third component is the SDK, which is completely irrelevant in the deployment process.

For what it’s worth, I’m getting the ImportError that a module named “Common” cannot be found when running your .p3d file. I’m guessing you would get that error as well if it weren’t for the fact that it doesn’t even get to that point for you.

So, I guess I should be trying this on Windows - it might be a Windows-specific issue, such as with the platform name ambiguity.

Ah, yes–I was confused, then (I was thinking of the runtime as the thing that actually runs the program–what you’re referring to as the “runtime-distribution”). My apologies for that, and thanks for the clarification!

So if I understand correctly, while I do want to use the dev. versons of packp3d and pdeploy, the standard runtime (whether installed independently and used to run a .p3d or bundled into an installer) should be fine–there’s no reason to install the dev. version of the runtime, yes?

That’s odd–Common should be present–but yes, I don’t seem to be getting even that far on my end.

Having just checked on my end (using the SDK via my IDE, at least), I do get an ImportError for the module “Test” (which I did erroneously remove, I believe)–but that’s being thrown from within Common, which indicates that Common has indeed been imported.

Indeed, that would seem to be the next thing to do.

However, I just managed to finish and install that Linux-64 build (the download was going very slowly, and I cancelled it once) under Ubuntu 13.10–and seem to have the same result, down to it attempting to load an xml file from a fictitous folder (in this case “panda3d.cmu_1.9.linux_amd64.xml” from the folder “/usr/lib/levelprototype/panda3d/cmu_1.9/linux_amd64/”, which exists as far as the “cmu_1.9” folder, with the xml file being present in that rather than the expected sub-folder.

It is very strange indeed that you’re not getting these errors… o_0

I’ll PM you a DropBox link to this Ubuntu version once I’ve uploaded it, I intend.

[edit] Forgive my ignorance in this, but I see that pdeploy produced both a deb file and a .pkg.tar.gz file–am I correct in thinking that only one of those is required (that they’re simply two different distribution methods)? If so, which would you prefer? (A zip containing both comes up to nearly 80MB, so I’d prefer to upload just one.)

It won’t matter for pdeploy, since there’s no way to influence which version of the runtime it packs. However, it might matter for running the .p3d directly. I couldn’t say.

Doesn’t matter for me. .deb is for Debian/Ubuntu, .pkg.tar.gz is for Arch Linux. I use neither, so I’ll end up unpacking it manually anyway - use whichever is most convenient for you.

Both are already compressed with DEFLATE, I’d be surprised if using .zip (which also uses DEFLATE) on that actually made it smaller and not bigger.

Ah, fair enough, and thanks.

Fair enough–I’m currently uploading the .pkg.tar.gz; they’re both about the same size (around 40MB), so there’s little to choose between them, it seems.

Heh, true, come to that! Zipping them was an ill-considered idea, I think. ^^;

Okay, it fails instantly with “Failed to execute”. Examining the log file shows the following error:

_per_platform for panda3d = 1
Couldn't read /usr/lib/levelprototype/panda3d/cmu_1.9/linux_amd64/panda3d.cmu_1.9.linux_amd64.xml

This confirms that it is indeed an issue with per_platform, which should be 0.

Opening up /usr/lib/levelprototype/contents.xml and changing per_platform=“1” to “0” suddenly makes it work. Hooray. So, at least the solution for that is clear now - pdeploy should write per_platform=“0” when creating this contents.xml file.

In fact, I see the following statement in the pdeploy source code, at the point where it writes out the contents.xml file:

xpackage.SetAttribute('per_platform', '1')

This was something that David added in a different commit, and it was probably a mistake (as the PackageTree constructor clearly sets perPlatform to False).

Now, could you try the same trick on your Windows machine - ie. does the installed game run after you change the contents.xml in the installation directory to have per_platform=“0” for all packages? If not, then there may be a separate issue going on, perhaps with the windows platform string, and I’d like to see a log file of it with that change applied.

Ah, progress it seems! :slight_smile:

I’m building a Windows version now (I’m afraid that I’d deleted the previouis versions)–I’ll post again once I have a result to report, I intend!

All right, my report:

Changing the value of “per_platform” wherever it appears in that xml file does indeed get me past the relevant error, but the program still doesn’t run (and I did restore that “Test” module, so it shouldn’t be hitting that issue). The log file looks very like that which I had previously when building without “-s”, including the odd white-space at the start of the file.

Here’s the new log, white-space omitted:

Setting working directory: C:\Users\user\AppData\Local\Panda3D\start
Command line: "C:\Program Files (x86)\LevelPrototype\panda3d\cmu_1.9\p3dpythonw.exe" "C:\Program Files (x86)\LevelPrototype/panda3d/cmu_1.9/" "000000D0" "000000DC" "0"
notify: onpluginload 
notify: onauth 
notify: ondownloadbegin 
notify: ondownloadcomplete 
notify: onready 
Created splash window 00060912
Loaded image: C:\Program Files (x86)\LevelPrototype/images/download.png
notify: onpythonstop 
finish_instance: 00CF1D08
Assigning 00CF1D08->log_pathname = C:\Users\user\AppData\Local/Panda3D/log/LevelPrototype.log

So, while the per-platform issue does seem to be a stumbling block, it looks as though it’s not the only one… :confused:

Again, it looks as though it’s starting correctly, and then somehow deciding that it’s done.

Yes, that looks like it’s exiting normally. This is the runtime log file; there should be either another log file or, if you ran it from the command line, command-line output from the application itself. Could you post that as well?

One frequent cause of this type of issue is that the run() call is hidden under a name == “main” check, which does not hold in the runtime environment. Please make doubly sure that you have no such check.

I take it that you mean “p3dcore.log”? If so, the relevant log from a recent Linux build (one in which I had set all instances of “per_platform” in the xml file to 0, as suggested, I believe) follows; I don’t recall noticing the file on Windows, but may have just missed it–I can get that version for your tomorrow I believe, if you want it.

Interestingly, I just realised that neither the runtime log nor this one seems to include that driver error that we were seeing previously–I don’t know whether that’s because it’s not getting that far, or because the runtime-distributable being used here has some change that fixes the issue.

One line towards the end strikes me: “application shares main object”–is that a potential issue?

_root_dir = /home/ian/.panda3d, _temp_directory = /tmp/, platform = linux_amd64, host_url =, verify_contents = 0
api_version = 16
read contents.xml, max_age = 5, expires in 0 s
Supported platforms: linux_amd64
Plugin version: 1.0.4
Plugin distributor: cmu
Core API host URL:
Core API version: 1.9.0
Core API date: Wed Jun 12 15:43:42 2013

Creating P3DInstance 0x833b10:  console_output="1" auto_start="1"
setting background to download, splash_window = 0
_per_platform for images = 0
Warning! per_platform disagreement for images!
All 8 extracts of images seem good.
report_package_info_ready: images
Done installing images: success = 1
p3d_basename = pdeploy_dev.p3d
p3d trusted
_matches_run_origin = 1
_matches_script_origin = 0
_auto_install = 1, _auto_start = 1, _stop_on_ready = 0
Migrating panda3d from platform "" to platform "linux_amd64"
_per_platform for panda3d = 0
Warning! per_platform disagreement for panda3d!
All 75 extracts of panda3d seem good.
report_package_info_ready: panda3d
panda3d: asked for seq 1, we have seq 2
morepy: asked for seq 1, we have seq 2
_per_platform for morepy = 0
Warning! per_platform disagreement for morepy!
All 32 extracts of morepy seem good.
report_package_info_ready: morepy
panda3d: asked for seq 1, we have seq 2
Beginning install of 0 packages, total 0 bytes required (32818087 previously downloaded).
set_wparams: 1 640 480
setting background to launch, splash_window = 0
Search path is /home/ian/.panda3d/hosts/runtime-dev.panda3d.org_6c875ad6f852d272/morepy/cmu_1.9:/home/ian/.panda3d/hosts/runtime-dev.panda3d.org_6c875ad6f852d272/panda3d/cmu_1.9
_p3dpython_exe: /home/ian/.panda3d/hosts/runtime-dev.panda3d.org_6c875ad6f852d272/panda3d/cmu_1.9/p3dpython
Setting environment:
  PWD=/home/ian/Documents/My Game Projects/P3D
  LESSOPEN=| /usr/bin/lesspipe %s
  LESSCLOSE=/usr/bin/lesspipe %s %s
Attempting to start python from /home/ian/.panda3d/hosts/runtime-dev.panda3d.org_6c875ad6f852d272/panda3d/cmu_1.9/p3dpython
Not changing working directory.
child still alive after 101 ms
notify: onpluginload 
notify: onauth 
notify: ondownloadbegin 
notify: ondownloadcomplete 
notify: onready 
application shares main object
notify: onpythonload 
notify: onpythonstop 
finish_instance: 0x833b10
Assigning 0x833b10->log_pathname = 
Python process has successfully stopped.
  exited normally, status = 0
Successfully joined thread: 0
P3D_finalize called
counts: 4 1 1 1

I don’t use such checks–it’s something that I never learned (I honestly don’t even know what it’s intended purpose is). Here’s a rough outline of how my “main” file (“”, to which I linked you in PM) is structured, including the “run” command:

from pandac.PandaModules import loadPrcFile, loadPrcFileData

# - Panda-related importations, including DirectObject and DirectStart

import os, sys, math, random, types

# - My own importations: external modules like KeyMapper, followed by game-specific modules.

# This is used by GameSaver
def isSubclass(name, classToCheck):
    if name == "NoneType" or name == "function" or name == "instancemethod":
        return False
    return issubclass(eval(name), classToCheck)

# This class controls the flow of the game, as well as handling events
class GameFramework(DirectObject):
    # - Class code here...

# Let the game begin!
gameFramework = GameFramework()

(I realise that rdb is likely not around as of the time of my posting this, but I’d rather leave it here early than risk forgetting later.)

I have a bit more information, perhaps.

I decided to have a shot at using the latest (as of earlier today, my time) SDK version of Panda from GitHub–which, as has been pointed out, shouldn’t have an effect, but seemed worth trying, and I mention it here just in case it’s relevant–and as a result attempted another build.

This time I noticed something in the output of packp3d_dev. It occurs early, and flashes by very quickly indeed, so I may well have missed it previously; I ended up catching it by redirecting the console output to a text file. Here is the text in question:

There are some missing modules: ['Adventuring.footsteps', 'BinsAndTags', 'Combat', 'Common', 'CommonValues', 'Conversation', 'Cutscene', 'GameObject', 'Inventory', 'Level', 'Menus', 'NPC', 'Navigation', 'OptionsMenu', 'Player', 'Town', 'Translation', 'panda3d.bullet', 'panda3d.core']

“Adventuring.footsteps” is understandable–that’s the result of something being accidentally left in, I believe–but all of the others (presumably including “panda3d.core”) are important–it seems somewhat odd that it’s not finding them.

More oddly, I would expect all of my own modules there to start with “Adventuring.”, as in the case of “footsteps”; a quick search of my code using “BinsAndTags” as an example found only importations with the “Adventuring.” prefix, like so: “from Adventuring.BinsAndTags import *”.

I have seen posts mentioning that the inclusion of “panda3d.core” in such messages is the result of a bug–but I believe that I’ve also seen at least one such indicate that said bug was fixed and would be corrected in the next release–since I’m using a dev. version, would I not perhaps have that fix?

As to my own modules, all of those mentioned should be within the directory given to packp3d–or rather, a subdirectory of that directory. To be specific, I build from a directory (simply named “P3D”) outside of my game’s directory, and point packp3d to the appropriate directory via the “-d” parameter. The hierarchy looks something like this:

  My Game Projects
    |----- P3D (from which I build)
    |----- LevelPrototype (the game directory)
    |              |
    |              |----- Adventuring (in which the above-mentioned modules should be found)

I note that it isn’t complaining about modules placed within the “LevelPrototype” directory, but within their own folders instead of the “Adventuring” folder, such as GameSaver or KeyMapper.

Possibly arguing in part against this is that I attempted a minimal test–albeit asking it for the same dependencies: Bullet, MorePy, and OpenAL–it too crashed shortly after opening a black window–but then I’ve had problems with the runtime on this computer (albeit not properly tested), I think, and the fact that it managed a black window (even if it didn’t show anything else) does seem to indicate that Panda is being found, despite there being a similar message in the output of packp3d_dev during building, albeit only including “panda3d.core” this time, I believe.

So, I think that it’s time to bump this thread, especially given that ninth has reported a similar-seeming issue here.

Has this been looked-into any further?

This is actually the first time I’ve noticed the crash ninth reported - and I’ve been using the Windows 7 x64 build for quite a while. I’ll look into that first.

I’d like to re-open this, as I’m still not managing to produce an installable build. :confused:

I’m still using the versions of packp3d_dev and pdeploy_dev that I was using when I first opened this thread, I believe. I do thus still have the “per-platform” issue, but that’s easily corrected while testing, and I gather that this should be fixed in the versions of packp3d and pdeploy released for 1.9.

I’ve performed a few more experiments using a very simple test-program (all under Ubuntu 13.10), summarised below:

What I’ve been doing:

  • The commands used to build were as follows:
panda3d packp3d_dev.p3d -o CompilationTest.p3d -d ../CompilationTest/ -r morepy -e dat -n ogg


panda3d pdeploy_dev.p3d -P linux_amd64 -a ian.eborn -A "Ian Eborn" -s -N "CompilationTest" -v 2 CompilationTest.p3d installer
  • I’ve run packp3d_dev both with and without the “-m” flag; when building without it, I naturally renamed my main (and only) Python file “”.
  • Within the main Python file, I’ve tried placing the code that instantiates and runs the main class both outside of any methods or classes, so that it’s run automatically, and within a function named “main”.

My results thus far:

  • The p3d file itself can be run via the runtime, both from the command-line and by simply double-clicking.
  • The installed version, however, seems to shut down almost immediately, with no apparent errors in the log file.

Finally, I have a question:

Looking at the directory created on installation of my test-program, I don’t see any files that seem to be specific to that program–no “CompilationTest” -.p3d,, or, for example–which prompts me to wonder whether the problem might not be that my program simply isn’t being included in the installation, and the execution thus having nothing to do after loading Panda and just exiting.

However, I could simply be missing the relevant files. So where should I be looking, and what should I be looking for?

A bit more information, perhaps: I created two builds of the same simple test-program, one using Panda 1.8 and the other using 1.9. Both were Linux-64 builds, and built under Ubuntu 13.10. I then ran both (after fixing the per-platform issue in the 1.9 version’s “contents.xml”) and compared their log files.

To start with, the version built using 1.8 ran successfully, while the version built using 1.9 didn’t.

The log files differ somewhat, naturally–it looks as though 1.9 might produce a bit more output than 1.8, for one thing.

Otherwise, two differences stand out to me:

[/b]Towards the beginning, there’s a section that appears to be concerned with checking the status of the various packages (morepy and Panda itself, in this case). The 1.9 version appears to have quite a bit more output here than the 1.8 version (including the warnings about “per_platform disagreement” that I believe have already been mentioned in this thread). However, I’m finding it difficult to tease apart the differences, and don’t know which, if any, are important.

Here’s the relevant section of the log file from the 1.9 version, with a bit of context before and after:

No longer current: panda3d
read contents.xml, max_age = 5, expires in 0 s
Migrating panda3d from platform "" to platform "linux_amd64"
_per_platform for panda3d = 0
Warning! per_platform disagreement for panda3d!
report_package_info_ready: panda3d
panda3d: asked for seq 2, we have seq 
expiring contents.xml for
morepy: asked for seq 2, we have seq 
expiring contents.xml for
_per_platform for morepy = 0
Warning! per_platform disagreement for morepy!
report_package_info_ready: morepy
panda3d: asked for seq 4, we have seq 
expiring contents.xml for
_per_platform for panda3d = 0
Warning! per_platform disagreement for panda3d!
report_package_info_ready: panda3d
panda3d: asked for seq 2, we have seq 
expiring contents.xml for
morepy: asked for seq 2, we have seq 
expiring contents.xml for
Beginning install of 0 packages, total 0 bytes required (43494343 previously downloaded).

b [/b]
Towards the end of the logs, when–if I read this correctly–the application is being started:

notify: ondownloadcomplete 
notify: onready 
application shares main object
notify: onpythonload 
notify: onwindowopen 
notify: onpythonstop 


notify: ondownloadcomplete 
notify: onready 
Reading splash file image: /usr/lib/compilationtest/images/download.png
notify: onpythonstop 

where do I get packp3d dev and pdeploy dev?

I believe that I got them from–however, I don’t see them listed there at the moment; perhaps they’ve been removed.

… Has anyone looked into this recently?

I don’t mean to be a pest by bumping this as I have been, but this issue is somewhat stalling the development of my project, and seems to me like a matter of concern in general–after all, if it’s happening on my machine, it’s possible that there will be other machines on something similar occurs.

Development is stalling because, while I can continue to work, I’m at a stage at which I very much want feedback on my game, which means distributing it to others. (Indeed, I have a test-scenario pretty much ready, I believe.) Specifically, I feel that I’m close to moving on to developing content–actual puzzles, levels, story and so on–but want to test my gameplay and deal with any serious issues before I do so. More generally, having next to no access to external feedback feels like a handicap to me.

I could distribute the .p3d file, I suppose, but outside of the Panda3D community that means asking people to separately download and install the run-time, which I fear may result in fewer people trying the prototype, and thus less feedback. (I’ll confess that I don’t think that I’ve tried the web-player option; it’s not an approach that I tend to favour, personally.) On the other hand, if the installers work for others then I could just build, upload, and hope–but I’m not at all comfortable with distributing builds that I haven’t tested, especially as I have a history of missing small things between development version and distributable build.

Perhaps more worryingly, if this isn’t addressed then this problem might remain until the game’s completion, potentially leaving me with not only the problem of testing my builds, but also that of having an issue present in my game that could cause it to simply fail for some users, with no apparent means of fixing it.

(In case anyone is wondering why I don’t simply develop for Panda 1.8, my project doesn’t work under that version, as it lacks features in its integration of Bullet that my project employs (including the use of bitmasks in filtering at least certain types of collision), if I recall correctly.)

Since I don’t know what’s relevant and what’s not, I’m currently resorting to dumping what results I’m managing to come up with here in the hopes that somewhere amongst them is a clue as to what’s going on.

Speaking of which, another experiment:

This time I compared the log files produced by the .p3d- and installed- versions of the 1.9 build. From what I see, the .p3d version outputs its log to “p3dcore.log”, while the installed version outputs to “.log”, where “” is the name of the game. They do seem to be comparable, but if I’m missing any logging please let me know.

As before, the .p3d version runs, but the installed version does not.

Oddly, while the log files do seem to be comparable, they also differ to a surprising degree, both in content (which is somewhat expected, given that one represents a successful run and the other an unsuccessful run) and in formatting (which seems a little more odd).

Some points that stood out to me:

  • The .p3d version reports a “host_url” of “”, while the installed version reports “
    [*]The .p3d version does in other places mention “”, and reports a “Core API version” of “1.9.0”, so I doubt that I’m unwittingly running the .p3d through a 1.8 runtime.
  • Neither version should be downloading anything, as far as I’m aware, so this may not be important.
    ]The .p3d version gives a “p3d_basename” of “CompilationTest.p3d”–the name of the .p3d file, naturally. On the other hand, the installed version uses the value “compilationtest” (note that the name is entirely in lower-case, and that there is no “.p3d” extension).[/:m]
    ]The .p3d version mentions at various places that “All extracts of seem good”, where “” is a number and “” appears to be a package; I don’t seem to be finding this at all in the installed version.[/:m]
    ]The .p3d version seems to set the window-size to 640x480, while the installed version sets it to 800x600–I presume that there’s a config.prc from which these settings are being taken, but how are they ending up with different values?[/:m]
    ]The installed version prints a line that begins wuth “Reading splash file image:”, while the .p3d version seems to print no such line.[/*:m][/list:u]