Why wont it work on Linux?
And Im not sure what you mean by changing the directory structure.
And am i right that the runtime will be smaller than when using packpanda for the same purpose?
It’ll be significantly smaller and faster than when using packpanda.
By changing the directory structure, I mean altering files or directories inside the installation directory.
It won’t work on Linux because the path to /usr/lib/yourgame/ is hardcoded into the game executable (which is /usr/bin/yourgame), there.
Im not sure if i understand this.
I could make another executable which will call main.py on its place. will that work?
No, I wasn’t looking for a solution to piracy (this is an utopia), I was looking for a method to reduce the damages on the developer side. If you distribute your game by an installer packed without -s, users and pirates will download the packages from your site, and your bandwidth will be wasted to provide packages to pirates.
No, I was thinking about a simpler scenario. I was wondering if it was possible to provide an installer with all packages inside, and make them upgradable. In this case, pirates have the first version of the packages inside the installer, so they don’t use your bandwidth. When you’ll update the packages, since the assets packages won’t probably change and the code packages are small, you’ll give only little updates. So, the bandwidth wasted for pirates is reduced.
I think a complete deployment tool should consider the entire lifecycle of an application, and (for games) this lifecycle goes beyond the installation and should consider the updates (I can’t remember a game which didn’t provide patches). Now, the situation of the deployment tools of Panda is almost perfect:
-
if you distribute via the web, you can trivially update the game on your site
-
if you use packages, you can use the automatic updating of packages and the patches system
2a) but, in this case, you’ll waste bandwidth for pirated copies
- if you use the -s switch, you won’t waste bandwidth, but in this case the deployment tools don’t cover the entire lifecycle of the application (because they don’t provide an updating method)
3a) and we must consider that (digital delivery) publishers (or payment processors) couldn’t be so happy if you host packages on your site, they could want to host themselves complete installers and patches, in order to manage the entire application (at the end, they are the ones who are selling the game to players).
So, I think the case 2 could be used for application which doesn’t face piracy issues (and applications which aren’t distributed by digital delivery publishers), while the case 3 should be used for downloadable games. But, in this case, the deployment tool supports you for the first part of the lifecycle of your game (installation), but not for the following ones (patches).
That would be a perfect solution! In that case, pdeploy would cover every scenario.
What do you mean? There is no main.py (or pyo or pyc) with pdeploy. Everything is ‘compiled’ into an executable file.
You’re preaching to the choir, my friend. It has always been my intent to add this functionality to pdeploy - it has just not been my first priority. I haven’t gotten to it yet. Maybe for a future release of Panda3D.
Sorry, I didn’t know it was in your roadmap. 
I’m very happy for this news. 
Adding RPM support is still keeping me more than busy at the moment. 
It’s a darn complicated format.
I dont understand. Are you saying both standalone and installer modes create a SINGLE executable file? So all my assets and code will be in one huge file? thats not what I wanted, well I wanted that for another project which i wanted to use -standalone for, but this project I want to allow access to all the asset files, so having them merged into 1 is not an option. Seems like there is no way currently to do that and I should go back to 1.7.0 and Packpanda
All of the contents of the .p3d file will be embedded in the executable file. People who don’t want this, can make custom packages containing the assets (or code), and let their .p3d packages depend on them with the -r flag. Pdeploy will then distribute these in the program directory instead of in the executable itself.
Sounds like that will allow to have another p3d file for the assets, but I want to have the files in a folder.
No, I meant a package, not a .p3d file. Packages like the ones you see in runtime.panda3d.org/ . The data will be in a multifile in the directory (except for any libraries or binaries, which will be extracted).
Like I said, the files MUST be accessible from the folder, multifile is not an option. Maybe the p3d system is just not for me.
They will be accessible from the directory from the program, because Panda3D mounts them to a virtual file system. So from within the application, you can simply open those files as if they were in the directory.
In case that’s not sufficient - if you can give me a good reason why you can’t use multifiles, I can consider adding something like an ‘extract’ option to pdeploy which extracts the multifiles.
I simply need users to be able to directly access the game assets and add new ones.
I also use the PIL library, so im not sure if i can load an image with it from multifile, but its mostly the first reason.
But users don’t necessarily have write access to the game directory anyway…
Um, what?
Which part of my reply don’t you understand?
Well the “users don’t necessarily have write access to the game directory” part, hehe.
I dont think I understand what you mean, because in XP/Vista/7 you have access, though on Vista/7 you are asked for admin password (if you are not logged as admin user) and though Im not very good with Linux, I remember accessing such directories with Ubuntu’s file manager after entering my password. So I dont think I understand. Alot of games have their files in few big resource files, but I know as much which do not, so I dont understand why you want to only allow files in a multyfile, its not like theres any harm and it makes modding very tedious.
And like I said I want to put the game’s folder in an archive and distribute it like that. So users will extract it anywhere they like. I have been doing that with Packpanda. I also had limited success with Panda3d and py2exe, but didnt work very well and its an even more hacky approach. Now that Packpanda is being deprecated, i dont know how long I can continue to use 1.7.0, there are already some bugfixes with never versions which used to crash my game, so Im trying to find an alterative way to do that. Dont get me wrong, the new p3d system isnt bad or anything, but in my opinion it makes things easier only if you make a web application. Otherwise you have to go few extra steps and I think the cases when users want to make non web apps vs web apps is significantly higher.
OK, I guess I can try to add an “extract” option that extracts the multifiles, and allow people to edit files. But the only files they would really be able modify is the textures, as the models are stored as .bam and the Python files as .pyo.
Would this work for you?
Note that because packpanda is a Python script, you can always take it from the source code and use it with whatever version of Panda3D, adapting it to your needs.
Thanks, but not really 
I’d want to distribute py and egg like I do now
Thats good to know